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

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

>>>>> "Michael" == Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

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

 Michael> When, from multibyte code, 

What does that mean?  Strings and buffers are the things which can be
multibyte.

 Michael> I do an (insert (prin1-to-string "høa")) into a unibyte
 Michael> buffer, I get what Lars does.  I.e., "h\370a".

Yes.  Maybe this would have been clearer than the above (all unibyte
and direct from Emacs):

(mapcar 'char-to-string (prin1-to-string "høa"))
  => ("\"" "h" "\\" "3" "7" "0" "a" "\"")

 Michael> This is, of course, correct assuming you are dealing with
 Michael> iso-8859-1.

Latin-1 is irrelevant.  Write it like this if you like:

(mapcar 'char-to-string (prin1-to-string "h\370a"))
  => ("\"" "h" "\\" "3" "7" "0" "a" "\"")

 Michael> However, if will not display as `ø' when represented thus
 Michael> unless the display table is set up properly.

The result won't display as `ø' because it isn't.

 Michael> I find the revelation that (string-to-vector
 Michael> (prin1-to-string "h\370a")) in a unibyte buffer returns [34
 Michael> 104 92 51 55 48 97 34] surprising, but as an internal
 Michael> encoding 

It isn't an internal encoding.  It's an external print form, which is
the point of `prin1' and friends.

 Michael> it doesn't really end up affecting the display of the
 Michael> buffer,

You're seeing four ASCII characters representing `ø', not the display
of one non-ASCII character.

I hope that now makes some sense.

 Michael> which is what I believe the problem Lars was having was
 Michael> about.

I think he'd better explain the complaint.