Re: Mule Emacs 20.3 w/enable-multibyte-characters set to nil

[Michael Welsh Duggan <md5i@cs.cmu.edu>]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "MWD" == Michael Welsh Duggan <md5i@cs.cmu.edu> writes:
> 
>  MWD> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>  >> Bill White <billw@wolfram.com> writes:
>  >> 
>  >> >   lmi> (insert (prin1-to-string "høa"))
>  >> >   lmi> => "h\370a"
>  >> > 
>  >> > I get exactly that with "GNU Emacs 20.3.11.1 (i586-pc-linux-gnu, X
>  >> > toolkit)" in *scratch* after M-x toggle-enable-multibyte-characters.
>  >> 
>  >> Darn.  Then I guess it's supposed to be that way.  Er...  Are there no
>  >> Emacs-MULE people on this mailing list?
> 
>  MWD> However, the display-table is still set to display `\370'
>  MWD> instead of `ø'.
> 
> If so, it's irrelevant.  The string contains only ASCII:
> 
> (string-to-vector (prin1-to-string "høa"))
>   => [34 104 92 51 55 48 97 34]
> 
> I don't know what the complaint actually is or what larsi wants, but
> perhaps see the optional arg of `prin1-to-string'.

When, from multibyte code, I do an (insert (prin1-to-string "høa"))
into a unibyte buffer, I get what Lars does.  I.e., "h\370a".  This
is, of course, correct assuming you are dealing with iso-8859-1.
However, if will not display as `ø' when represented thus unless the
display table is set up properly.

I find the revelation that 
(string-to-vector (prin1-to-string "h\370a")) in a unibyte buffer
returns [34 104 92 51 55 48 97 34] surprising, but as an internal
encoding it doesn't really end up affecting the display of the buffer,
which is what I believe the problem Lars was having was about.

If I am incorrect in any of this, feel free to correct me, as I am
always a little crestfallen when advice or information I have offered
is, in actuality, wrong.

-- 
Michael Duggan
(md5i@cs.cmu.edu)