[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rebinding international characters

From: Stefan Monnier
Subject: Re: Rebinding international characters
Date: 18 Aug 2004 11:55:59 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

>> I think that the --unicode mode is a dead-end (it made sense when it was
>                    ^^^^^^^^^--> --unibyte

Oops, indeed, thank you for fixing the typo.

> I agree.  Temporary unibyte buffer/string is still useful
> for raw data, but, yes, --unibyte mode is just a headache.

Yes, of course I was only talking about the unibyte *mode*: unibyte buffers
and strings will always be at least very useful if not necessary (remember
how I think of unibyte objects as "sequences of bytes" as opposed to
"sequences of chars" for multibyte objects).

>> I agree that C-1 should be fixed, but that implies doing the translation at
>> a lower level than we currently do.  It gets us back to the previous
>> discussion of the relationship betwen function-key-map and
>> key-translation-map and that we should have a key-translation-map-like step
>> before function-key-map.

> What do you think about my previous suggesion; i.e. handling
> it between keyboard-translate-table and input method in
> read_char?

I'd be happy to simply use keyboard-translate-table for keyboards coded in
latin-1, and to extend keyboard-translate-table so that an entry in the
table can be mapped to another table (thus being able to handle sequences of
chars in input) for encodings that use multiple bytes per char.

But maybe adding a separate step that directly obeys keyboard-coding-system
would be simpler  (with the addition that it makes it much easier to
temporarily change the encoding).

In general I agree that the keyboard decoding should be changed so that it
is done "within read-char" (i.e. read-char should return decoded chars).

>> Also we should be careful that applications like xterm-mouse-mode which want
>> to read keyboard input events as binary (even if the rest of the events are
>> normally treated as latin-1 or utf-8) can still do that properly.
>> It shouldn't be a source of problems, but it's still worth remembering.

> Ah, yes.

Maybe a `read-byte' function is in order.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]