Re: Rebinding international characters

[Kenichi Handa <handa@m17n.org>]

In article <m1wtzx5z8t.fsf-monnier+emacs@gnu.org>, Stefan <monnier@iro.umontreal.ca> writes:

>>  I think (C-1), (F-1), (F-2), (G-2), (H-1), (H-2) are not
>>  good.  (C-1) should be 2289, (F-1) (H-1) should be 241,
>>  (F-2) (G-2) (H-2) should be [241].

> I think that the --unicode mode is a dead-end (it made sense when it was
                   ^^^^^^^^^--> --unibyte
> introduced, but in my mind it's always been a temporary workaround for cases
> which the multibyte mode doesn't support correctly yet; nowadays multibyte
> mode behaves sufficiently well that --unibyte mode should be strongly
> discouraged).

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

> Thus I think that neither F-1, G-1, F-2, G-2, or H-2 are wrong (maybe
> they're not right either, but we shouldn't waste any time on them).

If Richard agree with that, I'll modify the info along that
line, i.e. clear enough for normal multibyte users.

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

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

---
Ken'ichi HANDA
handa@m17n.org