[PATCH] (Draft2) Make X11 server-side fonts and Mule suck less.
Aidan Kehoe
kehoea at parhasard.net
Thu Nov 2 06:41:49 EST 2006
Ar an chéad lá de mí na Samhain, scríobh stephen at xemacs.org:
> > Stop using the `registry' charset property; use `registries'
> > instead. The difference is that registries is an ordered vector of
> > X11 registries and encodings rather than a regexp; this means we
> > can leave the matching to the X11 server, avoiding transferring
> > huge amounts of data (perhaps across the network!) in order to do
> > a regexp search on it.
>
> Isn't this gratuitous difference with GNU?
No, GNU use fontsets and their Mule charsets have no registry property.
> There ought to be a way to get the best of both worlds.
My first inclination was to throw out the old way entirely, since it
involves much use of our under-performing regex engine at redisplay, the
unnecessary transfer of large amounts of data over what may be a network
connection, and a duplicated searching stage, firstly on the X server side,
then within XEmacs.
I like the warn-that-you’re-doing-something-wrong approach; it should give a
clear path to people who want to update their code to make it more
forward-compatibile.
> In the ChangeLog:
>
> > * mule/mule-charset.el (charset-registries): New.
> > * mule/mule-charset.el (set-charset-registry): New.
>
> Isn't `set-charset-registry' in the above a typo?
It’s new in Lisp; you’re right, it’s not a new function, though.
> > src/ChangeLog addition:
> >
> > 2006-10-31 Aidan Kehoe <kehoea at parhasard.net>
> >
> > * charset.h (XCHARSET_CCL_PROGRAM):
> > * charset.h (XCHARSET_NAME):
> > Make dummy versions of these available in non-Mule.
>
> Other things being equal, I doubt this is a good idea. Why do you want it?
It makes code in redisplay-x.c more readable (less #ifdef MULE happening)
without impacting its performance.
> > * console-impl.h:
> > * console-impl.h (struct console_methods):
> > Rename the last parameter to a couple of methods; reformat their
> > declarations.
>
> The above will cause some annoyance to CHISE, Carbon XEmacs, and
> possibly SXEmacs someday. Is it a good idea?
Yes; it moves the last parameter to being an enum with descriptive possible
values, rather than just an integer.
> Can the rest of these be split out? I want them!
I want the whole thing in! :-) .
--
Santa Maradona, priez pour moi!
More information about the XEmacs-Patches
mailing list