[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