>> > +(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