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

[Dave Love <d.love@dl.ac.uk>]

>>>>> "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> This is normal.

 MWD> Here is the situation:

I don't think so.

 MWD> "høa" has a internal multibyte representation of "\201\370".

Yes, but that's irrelevant in a unibyte buffer.  It's literal bytes.

 MWD> When inserting in the unibyte buffer, it correctly uses \370 instead
 MWD> of \201\370 to represent the character `ø'.

If it was a multibyte string:

(prin1-to-string (decode-coding-string "høa" 'latin-1))
  => "\"h\x8f8\ a\""

 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'.