2:01 p.m.
Aidan Kehoe writes:
No, GNU use fontsets and their Mule charsets have no registry
property.
*X* Font Sets? eeeeeeeeewwwwwww! Tell me it ain't so!
My first inclination was to throw out the old way entirely, since it
involves much use of our under-performing regex engine at redisplay,
And you think much round-tripping to the server is a better idea in
the midst of redisplay? ;-) Neither is acceptable. If regex is
actually being called from redisplay, we should fix that.
[CCL #defines] makes code in redisplay-x.c more readable (less
#ifdef MULE happening) without impacting its performance.
Ah, right, this is all internal anyway.
> > * 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.
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.
> Can the rest of these be split out? I want them!
I want the whole thing in! :-) .
Yeah, well, you're likely to get more of it faster if it comes in
bite-size pieces most of which have no question-able (note the
hyphen!) hunks.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
2:39 p.m.
New subject: [PATCH] (Draft2) Make X11 server-side fonts and Mule suck less.
Ar an dara lá de mí na Samhain, scríobh stephen(a)xemacs.org:
> No, GNU use fontsets and their Mule charsets have no registry
> property.
*X* Font Sets? eeeeeeeeewwwwwww! Tell me it ain't so!
It’s more or less so--I don’t know enough about X Font Sets to be able to
say if their implementation is compatible. But the idea is similar, and more
depressingly, they use it on Windows, and on Mac OS.
> My first inclination was to throw out the old way entirely,
since it
> involves much use of our under-performing regex engine at redisplay,
And you think much round-tripping to the server is a better idea in
the midst of redisplay? ;-)
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.
Neither is acceptable. If regex is actually being called from
redisplay,
we should fix that.
I agree :-) .
> > > * 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.
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.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
4:03 p.m.
New subject: [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
4:27 p.m.
New subject: [PATCH] (Draft2) Make X11 server-side fonts and Mule suck less.
Ar an triú lá de mí na Samhain, scríobh stephen(a)xemacs.org:
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.
That’s not the case. If there isn’t a match--as will be the case if a
Japanese font is looked up and the X11 platform code has initialised the
default face’s specifier to -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*
--the specifier instantiation code tries the face’s fallback patterns,
calling XListFonts for each one. In the X11 code as it stands, for a charset
that isn’t available at all in the X server, this means 128 times, often
with patterns like:
"-*-courier-medium-r-*-*-*-*-*-*-*-*-iso10646-1",
"-*-fixed-medium-r-*-*-*-*-*-*-*-*-iso10646-1",
"-*-courier-*-r-*-*-*-*-*-*-*-*-iso10646-1",
"-*-fixed-*-r-*-*-*-*-*-*-*-*-iso10646-1",
"-*-*-medium-r-*--*-gb2312.1980-*",
"-*-fixed-medium-r-*--*-cns11643*-*",
"-*-fixed-medium-r-*--*-big5*-*,"
"-*-fixed-medium-r-*--*-sisheng_cwnn-0",
which are a _total_ waste of time for Ethiopic or the IPA, especially since
that no font will support those scripts is _entirely expected._
> > [...] 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?
Maybe my judgement is really bad; in which case I shouldn’t be committing to
XEmacs. But if my judgement is reasonable, and I think the work useful,
then that’s the closest I can come to predicting that they will too, in the
absence of unknown or undocumented philosophical differences with them.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
6576
days inactive
6576
days old
3 comments
2 participants
participants (2)
-
Aidan Kehoe -
Stephen J. Turnbull