Upfront I want to thank Christoph for his work on X-symbol since he
seems to move onto other things soon.
radford(a)robby.caltech.edu (Jim Radford) writes:
Would you mind changing the definition of PERL in the Makefile to
PERL=perl -w.
I would even go so far as to suggest leaving out the "-w". The perl
"-w" switch is a great development aid, but is it really needed show
any warnings to potentially unsuspecting user.
Third, I really think that XEmacs should handle the font path issues
itself without asking the user (or administrator) to set it up. If
this means adding X(Set|Get)FontPath primitives to XEmacs then so be
it. I'm not sure if this is reasonable. I.e. does a "nice X citizen"
mess with the font path?
The problem is that the X server does not necessarily run on the same
host as the prorgam is running. The proper way to do it (at least that is what
programs like LyX etc that need their own fonts seem to do) seem to be to act
as a font server yourself.
Anyway I still think having the X(Set|Get)FontPath callable form
XEmacs would be nice. Wasn't there a patch for FSF Emacs that lets you
call arbitrary xlib functions from elisp?
+ while (ndirs_return--)
+ font_path = Fcons (build_string (directories[ndirs_return]), font_path);
Please read the 'Rules When Writing New C Code' section of the
"Internals" manual. Especially the "Coding for Mule" section.
You need to make sure the strings are property converted to the
internal MULE string format. I think in this case you need
build_ext_string with a FORMAT_FILENAME argument.
We have been busy stamping out bugs like this in the last month so it
would be unwise to introduce new ones.
+ EXTERNAL_LIST_LOOP (path_entry, font_path)
+ {
+ GET_C_STRING_CTEXT_DATA_ALLOCA (XCAR (path_entry), directories[i++]);
Conversely you probably want
GET_C_CHARPTR_EXT_FILENAME_DATA_ALLOCA
Jan