Re: [PATCH] (Draft2) Make X11 server-side fonts and Mule suck less.
Aidan Kehoe writes:
There’s less round-tripping in this implementation than in the
previous one.
Previously, matches would be tried against the XListFonts results with wildly
inappropriate (to this Mule charset) things in the X11 charset registry;
now, the registry is modified before calling XListFonts, so we never move
through a list of fallbacks that can never have a successful regex match
for the Mule charset in question.
No, there's less testing of the registry spec against actual fonts;
but as I understand the code, XListFonts should only be called once.
The idea of calling XListFonts at all was that (as slow as it is)
XEmacs regexps were faster than multiple round trips to the X server.
That may not be true any more (it may never have been true ;-), but I
suspect the real problem here is less that XEmacs regexps are slow and
more that the caching of XListFonts results that was supposed to be
done doesn't get done for some reason.
Since you're doing the work, in the end I'm not going to get too upset
if we use vectors of fixed strings instead of a regexp, but reducing X
protocol roundtrips should get top priority.
I also worry a little about the backward incompatibility for 3rd party
or package code that wants to use the vector-of-fixed-strings
approach, but needs to work with legacy XEmacsen.
> Well, yes, but is it such a good idea that we should make work
for
> others? That's one of my pet peeves with GNU.
IMO incorporating that change would make their code base more understandable
and would be a positive change, just as it would be in ours. I don’t think
providing a prompt to do useful work is specious or thoughtless.
Er, who says they'll think it's useful?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches