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

[Aidan Kehoe]

 Ar an tri? l? d?ag de m? na Samhain, scr?obh stephen at 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!