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

[Stephen J. Turnbull]

Aidan Kehoe writes:

 >  > Aidan> disp-table.el, which provides the display table
 >  > Aidan> code--make-display-table, frob-display-table,
 >  > Aidan> describe-display-table, and in
 >  > Aidan> http://mid.gmane.org/18288.1954.87217.762309@parhasard.net ,
 >  > Aidan> put-display-table and get-display-table--is in core. Yeah,
 >  > Aidan> there's a decent argument that it might be better in packages,
 >  > Aidan> but it isn't there for the moment.

AFAICS the display table code has to stay in core until both XEmacs
21.4 and the mainline have a way to install at least a bootstrap set
of packages, and we've worked out a reasonable way for this to work
from CVS/hg checkouts, too.  The patch I suggested recently is not
close to good enough yet.

 > That introduces new package dependencies, something I'm not in a
 > hurry to do given how much Mike Sperber fucked up the package build
 > last time he did so. (And he still hasn't fixed it!)

He has fixed the package dependencies, and he did so quickly.  What
hasn't been fixed is the problem that packages now depend on features
not present in 21.4.  This is a problem that has simmered for decades,
as APEL shows.  (Note that the difference between APEL and
package-future.el is that the former is designed to be compiled, while
the latter is put where it will *not* get compiled.)  Furthermore, any
solution to the deep problems created by Mike's update of JDE will be
a solution to any problems created by the analogous update of these
packages.

So, on balance I think Mike K is right.  This code should be
introduced in two places.  First in the mainline, second either in
21.4 core (which will take longer, viz the fact that Vin hasn't
weighed in on changing `make-autoload' in 21.4), or in packages.  I
think package-future.el is safest.