emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: Fwd: Re: Inadequate documentation of silly characters on screen.
Date: Thu, 19 Nov 2009 21:43:29 +0200

> Date: Thu, 19 Nov 2009 15:58:48 +0000
> From: Alan Mackenzie <address@hidden>
> Cc: address@hidden, Andreas Schwab <address@hidden>,
>       Jason Rumney <address@hidden>
> 
> > 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]