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

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

[Lars Magne Ingebrigtsen]

Then I get the following:

(insert (prin1-to-string "høa"))
=> "h\370a"

Is this a bug, or, er, uhm.  Something else?  Could someone who's
using the latest Emacs 20.4 pretest try this and see what happens?
(In a buffer where enable-multibyte-characters is nil.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Didier Verna]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 626 bytes --]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Then I get the following:
> 
> (insert (prin1-to-string "høa"))
> => "h\370a"
> 
> Is this a bug, or, er, uhm.  Something else?

        I know what you mean :-) "Something else" probably. Weren't you there
when Handa-san made his demonstration of the \201 problem ?

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /     ENST, INFRES C201.1       mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   +33 (1) 45 81 73 46
                       75013 Paris, France      Fax.   +33 (1) 45 81 31 19

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

[Lars Magne Ingebrigtsen]

Didier Verna <verna@inf.enst.fr> writes:

>         I know what you mean :-) "Something else" probably. Weren't you there
> when Handa-san made his demonstration of the \201 problem ?

Yes, but this looks like something else.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Bill White]

In article <m3oghlkdw1.fsf@quimbies.gnus.org>, Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  lmi> Then I get the following:
  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.

  lmi> Is this a bug, or, er, uhm.  Something else?  

dunno.

  lmi> Could someone who's using the latest Emacs 20.4 pretest try
  lmi> this and see what happens? (In a buffer where
  lmi> enable-multibyte-characters is nil.)

bw
--
Bill White . billw@wolfram.com . http://members.wri.com/billw

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

[Lars Magne Ingebrigtsen]

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?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Michael Welsh Duggan]

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?

This is normal.

Here is the situation:

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

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

However, the display-table is still set to display `\370' instead of
`ø'.  In order to set up the display table properly, you will need to
do something similar to what `standard-display-european-internal'
does.  Depending on your situation, you may want to do it to the
buffer's display-table rather than the standard-display-table.

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

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

[Lars Magne Ingebrigtsen]

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

> However, the display-table is still set to display `\370' instead of
> `ø'.  In order to set up the display table properly, you will need to
> do something similar to what `standard-display-european-internal'
> does.

Aha; so the bug is in not setting the language environment if one sets 
to nil.  That's clear enough, and I won't pursue the matter further.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Dave Love]

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

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

[Michael Welsh Duggan]

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)

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

[Dave Love]

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

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

[Michael Welsh Duggan]

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

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

Yes it does, thank you.

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