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

[Alan Mackenzie]

Hi, Eli!

On Thu, Nov 19, 2009 at 09:52:20PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 19 Nov 2009 18:08:48 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: address@hidden

> > No, you (all of you) are missing the point.  That point is that if an
> > Emacs Lisp hacker writes "?ñ", it should work, regardless of what
> > "codepoint" it has, what "bytes" represent it, whether those "bytes"
> > are coded with a different codepoint, or what have you.

> No can do, as long as we support both unibyte and multibyte buffers
> and strings.

This seems to be the big thing.  That ?ñ has no unique meaning.  The
current situation violates the description on the elisp page "Basic Char
Syntax", which describes the situation as I understood it up until half
an hour ago.

> > OK.  Surely displaying it as "\361" is a bug?

> If `a' can be represented as 97, then why cannot \361 be represented
> as 4194289?

ROFLMAO.  If this weren't true, you couldn't invent it.  ;-)

> > So, how did the character "ñ" get turned into the illegal byte #xf1?

> It did so because you used aset to put it into a unibyte string.

So, what should I have done to achieve the desired effect?  How should I
modify "(aset nl 0 ?ü)" so that it does the Right Thing?

> > Are you saying that Emacs is converting "?ñ" and "?ä" into the wrong
> > integers?

> Emacs can convert it into 2 distinct integer representations.  It
> decides which one by the context.  And you just happened to give it
> the wrong context.

OK, I understand that now, thanks.

> > > Because Emacs has no separate "character" data type.

> > For which I am thankful.

> Then please understand that there's no bug here.

Oh, I disagree with that.  But, whatever....

-- 
Alan Mackenzie (Nuremberg, Germany).