Re: Fwd: Re: Inadequate documentation of silly characters on screen.

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> I'm thinking from the lisp viewpoint.  The string is a data structure
>> I really don't want to have to think about
>> the difference between "chars" and "bytes" when I'm hacking lisp.  If I
>> do, then the abstraction "string" is broken.

> For some context on this, that’s how it works in XEmacs; we’ve never had
> problems with it, we seem to avoid an entire class of programming errors
> that GNU Emacs developers deal with on a regular basis.

Indeed XEmacs does not represent chars as integers, and that can
eliminate several sources of problems.  Note that this problem is new in
Emacs-23, since in Emacs-22 (and in XEmacs, IIUC), there was no
character whose integer value was between 127 and 256, so there was no
ambiguity.

AFAIK most of the programming errors we've had to deal with over the
years (i.e. in Emacs-20, 21, 22) had to do with incorrect (or missing)
encoding/decoding and most of those errors existed just as much on
XEmacs because there's no way to fix them right in the
infrastructure code (tho XEmacs may have managed to hide them better by
detecting the lack of encoding/decoding and guessing an appropriate
coding-system instead).

> Tangentally, for those that like the unibyte/multibyte distinction, to my
> knowledge the editor does not have any way of representing “an octet with
> numeric value < #x7f to be treated with byte semantics, not character
> semantics”, which seems arbitrary to me. For example: 

Indeed.  It hasn't bitten us hard yet, mostly because (luckily) there
are very few coding-system which use chars 0-127 in ways incompatible
with ascii.


        Stefan