bug#72460: [patch] add commands for setting keyboard translations interactively

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> > +(defcustom key-translate-selection-function #'key-select-translation
>> Do we need this?
> Short answer: yes.
>
> I wanted a way for users to customise how the current translation
> pairs are presented when they choose one to remove. The initial
> motivation was that some users might want to customise the formatting
> of the pairs; "X -> Y" vs "X → Y" vs "X Y" etc. (I'm the sort of user
> who cares about this sort of thing a lot).

Rewriting a whole new `key-translate-selection-function` function for
that is not significantly easier than rewriting a whole new
`key-translate-remove`, so I think this is firmly in the overengineering
side of the camp.

> I also envisage that many users will want to use/expect
> completing-read (as in the default) and will want the from/to elements
> vertically aligned (again, I am this user).

AFAICT, you're the first user to propose this functionality in Emacs's
40 years life, so I wouldn't bet on "many users".

BTW, I just noticed:

> +    ;; Populate collection
> +    (map-char-table format-func keyboard-translate-table)
> +    (get-text-property 0 'key-translate-from
> +                       (completing-read "Key Translation: " collection))))

You can't trust `get-text-property` here (especially since you don't
even force `completing-read` to `require-match`).
Instead you should do something like `key-parse`.

> I think here I was just copying the current calling convention for the
> existing (non-interactive) `key-translate'. Its docstring reads:
>
>> Both FROM and TO should be specified by strings that satisfy
>> `key-valid-p'.
>
> I sort of assumed someone cleverer than me had a good reason.

I suspect this is because we expect this function to be called from
a `~/.emacs` with a literal constant as argument, and we've tried to
unify on using the "KBD" syntax for those cases, since it's a friendlier
syntax than the "vector of events" where you need to distinguish between
symbols and chars with/without modifiers.

Since the arg of `key-translate` can be only a valid char (rather than
any arbitrary key potentially with modifiers), the argument is much less
strong, but my guess is that it was uniformity.

In the case of `key-translate-remove` I don't expect the arg to be
a literal constant in the code, so "nice/uniform syntax to write the
argument value" shouldn't be a concern.  🙂


        Stefan