Re: [PATCH] Abstract out a display-table-specific API (2)
mike.kupfer(a)xemacs.org writes:
>>>>> "ST" == Stephen J Turnbull
<stephen(a)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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta