Re: Terminal or keyboard decoding system?

[Ravi R]

On Sun 2021-09-19  7:23:09PM -04, Stefan Monnier <monnier@iro.umontreal.ca> 
wrote:
>> My current approach [2] is to bind the CSI sequence to the following
>
> AFAIK the CSI prefix is used for "all" key sequences as well as for
> other "side communication" (such as the bracketed paste functionality or
> the mouse events), so binding your function directly to CSI seems
> a bit drastic.
>
> IOW, Maybe a better option is to bind it to all the `CSI
> <digit>` sequences.  But I guess it depends what other sequences can
> occur in your terminal (in xterm, there are many standard keys that use
> sequences that start with CSI <digit>, and backeted paste actually also
> matches this pattern).

I do handle all sequences that can occur in my terminal, which are just
key sequences, focus in/out, and bracketed paste.

>>   1. read-char-exclusive can be advised by packages
>
> It can, but it doesn't seem common (I can't find any such occurrence in
> Emacs nor (Non)GNU ELPA other than inside a test inside Org) and it's
> not necessarily a problem.
> What problems have you encountered?

The multiple cursors package advises `read-key` which I originally used.
I haven't run into any packages that advise `read-char-exclusive`.

> BTW, why use `read-char-exclusive` rather than, say, `read-event`?

Fantastic catch! I did not know that `read-event` could be used here;
after replacing `read-char-exclusive` with `read-event`, two days of
emacs use has not resulted in the keystroke interleaving problem. Why
does this work better?

>>   3. Standard C-, M-, C-M- bindings cannot distinguish between shifted
>>      and non-shifted variants for characters: abcdefghjklnopqrstuvwxyz\
>> I don't understand the "C-DEL" issue at all, and work around the
>> shifted/non-shifted bindings via the following hacks:
>>   a. Mapping shifted to non-shifted versions in key-tranlation-map
>>   b. Add any non-shifted personal bindings (e.g., to "C-A" rather than
>>      "C-a") in local-function-key-map (really ugly)
>
> We have some long standing issues here, I think.
> Maybe a bug report is in order.

Ok, will do.

>> 1. Is modifying input-decode-map and key-translation-map the right
>>    approach?
>
> Yes (tho `key-translation-map` is better avoided, but sometimes it's
> the only option).

Why should it be avoided? I haven't run into any issues, but it'd be
good to know.

Regards,
Ravi