Re: Inadequate documentation of silly characters on screen.

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Sorry, `toggle-enable-multibyte-characters' was what I had in mind.
> So, yes, they *were* *indeed* the same.  YHBT (it wasn't intentional).

Oh, yes, *that* one.  I haven't yet managed to run a useful Emacs
instance with an "assert (BEG == Z);" at the entrance to this nasty
function, but I keep hoping I'll get there.

> I dunno, de gustibus non est disputandum and all that, but this idea
> of having an in-band representation for raw bytes in a multibyte
> string sounds to me like more trouble than it's worth.  I think it
> would be much better to serve (eg) AUCTeX's needs with a special
> coding system that grabs some unlikely-to-be-used private code space
> and puts the bytes there.  That puts the responsibility for dealing
> with such perversity[1] on the people who have some idea what they're
> dealing with, not unsuspecting CC Mode maintainers who won't be using
> that coding system.

I don't know what you mean.  The eight-bit "chars" were introduced to
make sure that decoding+reencoding will always return the exact same
byte-sequence, no matter what coding-system was used (i.e. even if the
byte-sequence is invaldi for that coding-system).  Dunno how XEmacs
handles it.

> And it should be either an error to (aset string pos 241) (sorry
> Alan!) or 241 should be implicitly interpreted as Latin-1 (ie, ?ñ).  I
> favor the former, because what Alan is doing screws Spanish-speaking
> users AFAICS.  OTOH, the latter extends naturally if you have plans to
> add support for fixed-width Unicode buffers (UTF-16 and UTF-32).

I understand this even less.  I think XEmacs's fundamental tradeoffs are
subtly different but lead to very far-reaching consequences, and for
that reason it's difficult for us to take a step back and understand the
other point of view.


        Stefan