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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 19 Nov 2009 15:58:48 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org, Andreas Schwab <schwab@linux-m68k.org>,
> 	Jason Rumney <jasonr@gnu.org>
> 
> > No: the string does not contain any characters, only bytes, because it's
> > a unibyte string.
> 
> I'm thinking from the lisp viewpoint.  The string is a data structure
> which contains characters.  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.

No, it isn't.  Emacs supports unibyte strings and multibyte strings.
The latter hold characters, but the former hold raw bytes.  See
"(elisp) Text Representations".

> > The byte 241 can be inserted in multibyte strings and buffers because
> > it is also a char of code 4194289 (which gets displayed as \361).
> 
> Hang on a mo'!  How can the byte 241 "be" a char of code 4194289?  This
> is some strange usage of the word "be" that I wasn't previously aware
> of.  ;-)

That's how Emacs 23 represents raw bytes in multibyte buffers and
strings.

> At this point, would you please just agree with me that when I do
> 
>    (setq nl "\n")
>    (aset nl 0 ?ñ)
>    (insert nl)
> 
> , what should appear on the screen should be "ñ", NOT "\361"?

No, I don't agree.  If you want to get a human-readable text string,
don't use aset; use string operations instead.