Ar an triú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
[...] The point is that we are not thinking about a release at this
time.
The patches that you are proposing do fix real bugs, and arguably are
better than what we have. But they clearly change *correct* (ie, useful
to somebody and conforming to existing specs, including the trivial case
of no explicit spec) user-visible behavior and IMO complexify XEmacs's
APIs. Is that really appropriate at this stage in the development cycle?
What development cycle? “Cycle” involves some concept of “release,”
right? Release involves a release engineer, and a schedule, things we don’t
have.
Again IMO, XEmacs is in trouble more because of its archaic
complexity
which deters improvement than because of its bugs (and admittedly
those are many). We really need to simplify and regularize behavior,
especially of Mule, even at the expense of more buggy behavior in the
short run. We need to push fixes out to Lisp wherever possible;
changes at C-level should be in accord with some kind of design and
explicit specification, not ad hoc fixes of bugs.
You know, I hate that. I understand the reasoning, but it seems to me that
people push decisions out to Lisp _and then leave them unimplemented or
unfinished there_ too much. The locale sniffing is in Lisp, and it sucks.
The face menu is Lisp, and it’s kind of buggy, inconsistent, and slow (not
helped by my recent change--I’ll get to fixing it soon, promise!). More
generally, the menus are in Lisp, and they’re not that coherent or nice to
use--they is no overarching theme of what merits a menu entry and what
doesn’t. Deciding which mouse button to use when clicking on a link is in
Lisp, and it’s wrong, and has been ever since Mosaic was released.
For example, your change to the specifier tags may be a good one,
but
we should think about other revisions at the same time. For example,
I think it would be a good idea to have a mode specifier domain---the
buffer domain is mostly used only by mode-specific code, people hardly
ever apply specifications to just one buffer. Are there other
features that could use tag tests like the one you added for charsets?
Are we pretty sure there aren't? (If the answer to the last question
were "yes", I'd have much less objection to the specifier changes
you've made. If it's "no", the API you created is dubious.)
I’m not enchanted with specifiers generally--do a (setq debug-x-faces 1
debug-x-objects 1) and watch how often they call that code for one part of
why--so with regard to your example, IMO buffer-local variables are good
enough for that problem, and there are enough parts of XEmacs that aren’t
“good enough” that they come earlier in the queue.
I can’t think of any other features that could use tag tests like the one I
added for charsets, but maybe someone more enchanted by specifiers could.
In general, IMO we need to get rid of internal Mule encoding and CCL
so people with some familiarity with modern I18N can work on XEmacs,
not make them less painful for end users but require a PhD in software
archaeology of would-be hackers.
Well, I think implementing that would be workable and relatively painless,
there are none of the design questions I had trouble with when I first
proposed it--refactor the existing Mule encoding and the existing Unicode
support to make it possible to treat it as an implementation of ISO 2022 on
top of Unicode, instead of vice-versa, use some of that infrastructure for
X11 server-side redisplay, don’t use any of it for XFT or Win32, use the
UTF-8 escapes in generated escape-quoted .elc files instead of the ISO-2022
encoding for non-ASCII characters, but be equally prepared to read the
ISO-2022 representations of characters.
But I don’t like the idea of adding one more configure option for it at this
point in time; it’s already a lot of work, and too easy to forget one of
them, to test any changes on X11 with Mule, X11 without Mule, XFT with Mule,
XFT without Mule, Win32 with Mule, Win32 without Mule, the TTY. I’d be more
open to it if we removed non-Mule as an option, but I don’t see that
happening soon.
Now, if you think that we *need* to fix those bugs so that people
can
have a usable XEmacs in the meantime, I can live with that. But IMO
we need to make a separate branch (ie, an interim release) so that the
mainline doesn't get encrufted with ad hoc workarounds.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta