[PATCH] Prevent a crash if the ASCII charset registries match nothing

stephen at xemacs.org stephen
Mon Nov 13 01:26:19 EST 2006


I'm sorry for being short, I'm just back from a business trip and a
visit with a friend who's being bullied by his institution.  I
shouldn't project my bad mood on you.

Let me expand:

stephen at xemacs.org writes:

 > QUERY
 > 
 > What's the big hurry?

and

 > Making things a little bit better for people with misconfigured
 > systems at the expense of breaking Ilya's hacks is not a good tradeoff
 > IMO.

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?

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.

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.)

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.

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.



More information about the XEmacs-Beta mailing list