>> It works correctly, provided the characters in that string can be
>> expressed in the unibyte buffer.
> But which characters can be expressed is poorly specified. E.g. Tell me
> which chars can be expressed in a unibyte buffer in a BIG5 locale?
> Mentioning the locale is somewhat of a red herring, since what controls
> this conversion is (effectively) nonascii-insert-offset.
The nonascii-insert-offset and noonascii-translation-table is AFAIK
initialized differently depending on the locale (and/or language
environment) and users typically don't fidle with that table directly but
via their locale setting instead.
> Mentioning BIG5 is a second red herring. You can't represent Chinese
> in 8-bit characters, but that is not Emacs' fault.
Code which implicitly converts text from multibyte to unibyte (and vice
versa), using nonascii-*, will presumably be used in all kinds of locales,
including BIG5 ones. So knowing what happens in this case is
still relevant.
> Do you think that we need to document nonascii-insert-offset more
> prominently? If so, where else should we talk about it?
No, I think we should kill it instead and declare in error any code which
tries to use it. It made sense in Emacs-20 when the multibyte support was
weaker, but nowadays it just encourages sloppy code which breaks down in
different language environments.
>> If people generally agree it would be better to signal an error,
>> we could do that. However, that would cause trouble trying to use
>> M-y to move past multibyte entries in the kill ring to reach the
>> unibyte entry you really want.
> When the insertion is a user-level operation, the elisp code should make
> sure to manually do the encoding/decoding, using e.g. the default file
> coding-system.
> I don't understand -- could you be more specific?
C-y/M-y uses `insert' somewhere internally. My suggestion is to make
`insert' signal an error when faced with the need to insert a multibyte
string in a unibyte buffer. This doesn't mean that C-y/M-y should propagate
this error.
Stefan
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
