GNU bug report logs - #72460
[patch] add commands for setting keyboard translations interactively

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: hugo <at> heagren.com, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 72460 <at> debbugs.gnu.org
Subject: bug#72460: [patch] add commands for setting keyboard translations interactively
Date: Sat, 14 Sep 2024 10:38:04 +0300

Hugo,

Any followups to Stefan's comments?

> Cc: 72460 <at> debbugs.gnu.org
> Date: Sat, 31 Aug 2024 09:56:58 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> 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
> 
> 
> 
> 
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.