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

[Stephen J. Turnbull]

mike.kupfer at xemacs.org writes:

 > >>>>> "ST" == Stephen J Turnbull <stephen at xemacs.org> writes:
 > 
 > ST> Make them defsubsts.  ;-)
 > 
 > ST> I'm not really joking about this case: I think it's a reasonable
 > ST> answer even though a bit fragile.  However, I acknowledge it's not a
 > ST> good generic answer.
 > 
 > I think a good generic answer would be to have 2 "futures" files: one
 > for compile-time fixups and one that's available at run time, probably
 > as part of xemacs-base.
 > 
 > How does that sound?

The potential problem is that we don't have a good way to inform users
that they need Version X.Y of xemacs-base.  If putting
runtime-future.el into xemacs-base was a good solution, I don't see
why we'd need a separate compile-time version.

Also, if you put it into xemacs-base, it gets compiled.  The inability
to run uncompiled macros from bytecode means that in principle every
version of XEmacs needs a different compiled version of xemacs-base.
The history of the APEL package shows that this is a practical
problem, too.

The real solution is to have a standard-library package (or package
suite) which is shared between all reasonably recent XEmacs versions.
(This is the real long-term motivation for the "bundled-packages"
work.)  Versions of XEmacs without C support for certain features
would have to do without, or perhaps use inefficient Lisp versions.