[PATCH] Abstract out a display-table-specific API (2)

[Stephen J. Turnbull]

Aidan Kehoe writes:

 >  Ar an ceathrú lá is fiche de mí na Nollaig, scríobh mike.kupfer at xemacs.org: 

 >  > First, I'm nervous about XEmacs-specific patches that I would have to
 >  > apply every time I resync with upstream.  
 > 
 > Yeah; I need to ask the Gnus people to apply it too.

That's the best solution, but IIRC Gnus currently aims at supporting
Emacs 21, 22, and 23, as well as multiple XEmacsen---spanning about
four different redisplay mechanisms.  Expect difficulties in getting
it right. :-(

Mike, although CVS has a lot of problems, its merge capabilities are
not much worse than any other system (in principle, anyway, assuming
you don't interact with a CVS bug).  For this kind of thing, you
shouldn't have to actually worry about the merge very often---CVS will
take care of it.  The simplest thing to do is make a "vendor branch"
which does nothing but track upstream's releases, then merge that into
the XEmacs CVS mainline.

However, my advice would be to keep a private Mercurial (or other
modern system) repository.  I know from tracking emacs-devel
discussions that Emacs Gnus (not to be confused with larsi Gnus,
unfortunately) is moving a lot of libraries traditionally provided by
Gnus into other parts of Emacs.  We've done the same but I'm pretty
sure that the Emacs guys are making somewhat different decisions.  I
suspect that this may end up being reflected upstream in Gnus itself.

This means that a SCM that can explicitly track file renames may be of
great help.  I haven't run into that myself (I've done renames, but
never had any imposed on me) so I hesitate to make recommendations,
but I know that git, Mercurial, and Darcs all have explicit "rename"
commands, and I believe bzr does too.