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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72460 in the body.
You can then email your comments to 72460 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: hugo <at> heagren.com
To: bug-gnu-emacs <at> gnu.org
Subject: [patch] add commands for setting keyboard translations interactively
Date: Sun, 04 Aug 2024 13:16:29 +0100

[Message part 1 (text/plain, inline)]

Dear all,

The attached patch adds commands for adding and removing entries in
`keyboard-translate-table' interactively:
- add an interactive spec to `key-translate'
- add a new command `key-translate-remove', which does the opposite of
  `key-translate'.
- add an option for users to customise how the latter function prompts
  for which from/to pair is removed. The default just lists them with
  `completing-read'.

I find this sort of thing useful for cases where I want to use
something other than space as a word separator (e.g. when typing lots
of function names), or when for a long period I want to use the symbol
which is usually on the shift of a key (i.e. I know I want to type "+"
a lot, but not "=").

The patch doesn't contain a NEWS entry yet -- I wanted to get the
greenlight on the code first.

Best,

Hugo

[0001-Add-commands-to-interactively-set-unset-keyboard-tra.patch (text/x-diff, attachment)]

Message #8 received at 72460 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#72460: [patch] add commands for setting keyboard translations
 interactively
Date: Sat, 17 Aug 2024 11:46:42 +0300

> Date: Sun, 04 Aug 2024 13:16:29 +0100
> From: hugo <at> heagren.com
> 
> The attached patch adds commands for adding and removing entries in
> `keyboard-translate-table' interactively:
> - add an interactive spec to `key-translate'
> - add a new command `key-translate-remove', which does the opposite of
>    `key-translate'.
> - add an option for users to customise how the latter function prompts
>    for which from/to pair is removed. The default just lists them with
>    `completing-read'.
> 
> I find this sort of thing useful for cases where I want to use
> something other than space as a word separator (e.g. when typing lots
> of function names), or when for a long period I want to use the symbol
> which is usually on the shift of a key (i.e. I know I want to type "+"
> a lot, but not "=").
> 
> The patch doesn't contain a NEWS entry yet -- I wanted to get the
> greenlight on the code first.

Thanks.

Stefan, any comments?

Message #11 received at 72460 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: hugo <at> heagren.com
Cc: 72460 <at> debbugs.gnu.org
Subject: Re: bug#72460: [patch] add commands for setting keyboard
 translations interactively
Date: Mon, 19 Aug 2024 10:42:43 -0400

> I find this sort of thing useful for cases where I want to use
> something other than space as a word separator (e.g. when typing lots
> of function names), or when for a long period I want to use the symbol
> which is usually on the shift of a key (i.e. I know I want to type "+"
> a lot, but not "=").

Interesting.  I can see that `keyboard-translate-table` is indeed
a cheap way to implement it.

[ This said, it applies at a very low level (directly inside
  `read-event`) and only to "characters" (e.g. not to the `tab` or
  `return` keys), which can make it both maybe too powerful and yet not
  flexible enough.  ]

> +  (interactive `(,(key-description `[,(read-char "From: ")])
> +                 ,(key-description `[,(read-char "To: ")])))

[ Personally, I'd add a comment lamenting the fact that `keymap-*`
  functions force us to use `key-description` here only for that to be
  undone by `key-parse`.  ]

> +(defcustom key-translate-selection-function #'key-select-translation

Do we need this?

> +pair in `keyboard-translate-table', and return a vector containing only
> +the FROM key of the selected pair (e.g. if the selected pair translates
> +\"=\" to \"+\", the function should return the vector [61])"

Why not return just the char rather than a vector containing the char?

> +(defun key-translate-remove (from)
> +  "Remove translation of FROM from `keyboard-translate-table'.
> +
> +FROM must satisfy `key-valid-p'.  If FROM has no entry in
> +`keyboard-translate-table', this has no effect."
> +  (interactive (list (key-description
> +                      (funcall key-translate-selection-function))))
> +  (set-char-table-range
> +   keyboard-translate-table (aref (key-parse from) 0) nil))

If FROM maps to a sequence of length != 1, we'll either signal an ugly
error or silently ignore the rest.
Any reason why you didn't make FROM be a simple character?


        Stefan

Message #14 received at 72460 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#72460: [patch] add commands for setting keyboard translations
 interactively
Date: Sat, 31 Aug 2024 11:08:02 +0300

Ping! Hugo, can you please respond to Stefan's review comments, so we
could make progress here?

> Cc: 72460 <at> debbugs.gnu.org
> Date: Mon, 19 Aug 2024 10:42:43 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > I find this sort of thing useful for cases where I want to use
> > something other than space as a word separator (e.g. when typing lots
> > of function names), or when for a long period I want to use the symbol
> > which is usually on the shift of a key (i.e. I know I want to type "+"
> > a lot, but not "=").
> 
> Interesting.  I can see that `keyboard-translate-table` is indeed
> a cheap way to implement it.
> 
> [ This said, it applies at a very low level (directly inside
>   `read-event`) and only to "characters" (e.g. not to the `tab` or
>   `return` keys), which can make it both maybe too powerful and yet not
>   flexible enough.  ]
> 
> > +  (interactive `(,(key-description `[,(read-char "From: ")])
> > +                 ,(key-description `[,(read-char "To: ")])))
> 
> [ Personally, I'd add a comment lamenting the fact that `keymap-*`
>   functions force us to use `key-description` here only for that to be
>   undone by `key-parse`.  ]
> 
> > +(defcustom key-translate-selection-function #'key-select-translation
> 
> Do we need this?
> 
> > +pair in `keyboard-translate-table', and return a vector containing only
> > +the FROM key of the selected pair (e.g. if the selected pair translates
> > +\"=\" to \"+\", the function should return the vector [61])"
> 
> Why not return just the char rather than a vector containing the char?
> 
> > +(defun key-translate-remove (from)
> > +  "Remove translation of FROM from `keyboard-translate-table'.
> > +
> > +FROM must satisfy `key-valid-p'.  If FROM has no entry in
> > +`keyboard-translate-table', this has no effect."
> > +  (interactive (list (key-description
> > +                      (funcall key-translate-selection-function))))
> > +  (set-char-table-range
> > +   keyboard-translate-table (aref (key-parse from) 0) nil))
> 
> If FROM maps to a sequence of length != 1, we'll either signal an ugly
> error or silently ignore the rest.
> Any reason why you didn't make FROM be a simple character?
> 
> 
>         Stefan
> 
> 
> 
> 
> 

Message #17 received at 72460 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: hugo <at> heagren.com
Cc: 72460 <at> debbugs.gnu.org
Subject: Re: bug#72460: [patch] add commands for setting keyboard
 translations interactively
Date: Sat, 31 Aug 2024 09:56:58 -0400

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

Message #20 received at 72460 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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
> 
> 
> 
> 
> 

Message #23 received at 72460 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: hugo <at> heagren.com
Cc: 72460 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#72460: [patch] add commands for setting keyboard translations
 interactively
Date: Sat, 28 Sep 2024 11:49:20 +0300

Ping! Hugo, please respond.

> Cc: 72460 <at> debbugs.gnu.org
> Date: Sat, 14 Sep 2024 10:38:04 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> 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
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Message #26 received at 72460 <at> debbugs.gnu.org (full text, mbox):

From: hugo <at> heagren.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72460 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#72460: [patch] add commands for setting keyboard translations
 interactively
Date: Sat, 28 Sep 2024 16:33:09 +0100

[Message part 1 (text/plain, inline)]

Hi all,

sorry, I was working on this last night , had the patch sorted, and
then somehow my browser crashed and I couldn't get to my email.
Apologies for all the delays.

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

Fair enough, I've got rid of the defcustom.

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

Good spot.

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

Nice, removing the defcustom makes the whole thing simpler anyway.

The way it works now is that `key-select-translation' returns a string
(which passes `key-valid-p'). I went with this because then it's very
straightforward to pass the result to `key-translate' in
`key-translate-remove'. The alternative would be to parse a key vector
out of the string at the end of `key-select-translation', but then
immediately convert this back into a string (a string like the one I
went with in the end) in the interactive form of `key-translate-remove'.

New patch attached.

Hugo

[0001-Add-commands-to-interactively-set-unset-keyboard-tra.patch (text/x-diff, attachment)]

Message #29 received at 72460 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: hugo <at> heagren.com
Cc: 72460 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#72460: [patch] add commands for setting keyboard
 translations interactively
Date: Sat, 28 Sep 2024 12:02:45 -0400

> New patch attached.

Thanks Hugo, LGTM.


        Stefan

Message #32 received at 72460 <at> debbugs.gnu.org (full text, mbox):

From: hugo <at> heagren.com
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 72460 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#72460: [patch] add commands for setting keyboard translations
 interactively
Date: Thu, 03 Oct 2024 03:45:02 +0100

[Message part 1 (text/plain, inline)]

Hi all,

following some short comments from Stefan, a better patch is now
attached. The new version accounts for the case where multiple
adjacent characters have the same translation and are thus presented
as a range in `map-char-table'. I've dealt with this by displaying
each one individually in the prompt, since:
- the user probably *initially set* them separately if they are using
  the interactive functions
- if they aren't using the interactive functions, the prompt doesn't
  matter

Since this is the only substantive change since I was last told this
looked good, I've also included a NEWS entry.

I have already assigned my copyright to the FSF.

Best,

Hugo

[0001-Add-commands-to-interactively-set-unset-keyboard-tra.patch (text/x-diff, attachment)]

Message #35 received at 72460 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: hugo <at> heagren.com
Cc: 72460 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#72460: [patch] add commands for setting keyboard
 translations interactively
Date: Thu, 03 Oct 2024 11:56:41 -0400

> Since this is the only substantive change since I was last told this
> looked good, I've also included a NEWS entry.

Thank you.  Pushed to `master`!


        Stefan

Previous Next

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