Re: Terminal or keyboard decoding system?

[Stefan Monnier]

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

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

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

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

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

>    Or should this be done using a coding system, e.g.,
>    keyboard-coding-system or terminal-coding-system?

Definitely not (these deal with characters like those that can occur
inside a string, i.e. not ones with modifiers).

> 2. Emacs key representations seem to come in two forms: a 28-bit integer
>    (e.g., "H-M-A-a" is (1<<24)+(1<<27)+(1<<22)+97) and a symbol list
>    (e.g., "H-<f1>" is 'H-f1), both of which are then stored in a vector.
>    To be able to disambiguate between shifted versions and non-shifted
>    versions, I ended up computing [3] the values directly for the
>    integer representation, since event-convert-list (used internally by
>    define-key) strips off shift modifiers for alphabetic characters in C
>    code, and provides no way to work around it. However, "C-a" and
>    "C-S-a" seem to be work perfectly fine if the integer value is
>    computed explicitly; is this expected, or are there other minefields
>    that I haven't encountered?

As mentioned above, there are indeed weirdnesses here around the
equivalence between `A` and `S-a` as well as between `C-A` and `C-S-a`
but I think the better place to address them is in a bug report.

It is a fairly messy part, since the shift and control modifiers break
the clean separation between a character and a modifier (since the `A`
character is also an `a` with a shift modifier and since `C-a` is
itself a character as well).


        Stefan