Re: Best way to intercept terminal escape sequences?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>>> As mentioned, read-event did not do obey keyboard-coding-system in
>>>> earlier Emacsen, so any affected package is more likely to be fixed than
>>>> broken by making a change that reverts to this previous behavior.
>> > Handa, could you take a look at the feasibility of moving the
>> > decode_keyboard_code to a later stage such that read-event still returns
>> > raw bytes for ttys?
>> ping?
> "... read-event still returns raw bytes" means that you can't get, for
> instance, A-ogonek event by read-event (or read-char) even if you type
> A-ogonek from a terminal.  I don't remember well but one reason of
> moving keyboard-coding-system handling from keymap to the current
> place was to make read-event on tty work as the same way as that on
> graphic terminal.  So, I think we should not change it.

IIRC the reason to decode earlier was so that things like
input-decode-map and friends get to see real chars rather than bytes,
but none of those reasons require read-event to always return chars.

IIRC one of the main problems with earlier code was that encoded-kb
would sometimes see bytes and sometimes chars (i.e. it would normally
see bytes under a tty except when using leim), so it sometimes
incorrectly took chars for bytes and re-decoded them.

> Is it difficult to make new functions, say tty-getc and tty-ungetc, to
> handle responsding escape sequences sent from terminal?

It doesn't look easy at all, since the current code does decoding before
placing the bytes in the event-queue (i.e. by the time Elisp code gets
a chance to look at the queue, the decoding has already taken place).

It would be better to decode later (i.e. after placing the events on
the event-queue), tho still before leim and input-decode-map.

We can then easily provide a "new" function to read "decoded events".
We could call it ... read-char ;-)


        Stefan