Allow user defined keys in translation rules

[corytertel]

Fixed an issue where devil wouldn't work with user defined keys with a - in them.

Examples of popular user defined keys include <C-i>, <C-m>, and <control-x>.

[susam]

Hello! Thank you for working with this project and sending a pull request too. I need more details to understand exactly what issue this pull request is meant to fix. The current version of Devil should work fine out of the box for custom key sequences like C-i, C-m, etc. For example, consider the following configuration:

(global-set-key (kbd "C-i") (lambda () (interactive) (message "You typed C-i")))
(global-set-key (kbd "C-m") (lambda () (interactive) (message "You typed C-m")))
(global-set-key (kbd "C-x") (lambda () (interactive) (message "You typed C-x")))
(require 'devil)
(global-devil-mode)

Now if we type , i Devil correctly translates this to C-i and the message You typed C-i is displayed in the echo area. Likewise for the , m and , x.

That's why I am not sure if I have understood the issue correctly. I believe the following details will help me to understand the issue better:

1. Elisp code that creates a user-defined key for which Devil does not work.
2. Elisp code that loads and/or configures Devil.
3. The exact keys I need to type to reproduce the issue.
4. What the expected behaviour is when the keys mentioned in point 3 are typed and what behaviour is observed instead.

[corytertel]

Sorry for not providing any detail. New keys can be defined to allow Emacs to interpret existing key presses in different ways. For example, Emacs treats C-i as TAB. If you bind a key to either C-i or TAB, the other key will get bound as well. This is legacy behavior.

(define-key input-decode-map [?\C-i] [C-i])

This creates a new, user-defined key <C-i>. You can now bind a key to <C-i>. This key press is still control + i on the keyboard, but it does not get picked up as TAB.

;; Now:
(equal (kbd "TAB") (kbd "C-i"))   ; -> t
(equal (kbd "TAB") (kbd "<C-i>")) ; -> nil

Currently, this would not work with devil.

(global-set-key (kbd "<C-i>") (lambda () (interactive) (message "You typed <C-i>")))
(global-set-key (kbd "TAB") (lambda () (interactive) (message "You typed TAB")))

(use-package devil
  :config
  (setq devil-translations (list (cons "%k i" "<C-i>"))))

Typing , i does not work.

Devil: , i is undefined

With the existing devil--invalid-key-p, <C-i> would be detected as invalid, even though it is a perfectly valid key. This is because it has a - in its name. Because user-defined keys are surrounded by < >, I have changed the regex to allow all user-defined keys.

<C-i> is just one example. Any user defined key is possible. (Personally I have a few.)

[susam]

Thank you for the detailed description of the issue. I could reproduce this issue. Your fix seems to work well too.

I need the commit message to be reworded so that it follows the commit conventions this project has been using. Only a few minor changes are needed. In particular, please see points 1, 3, and 4 of https://github.com/susam/devil/blob/63a9bdce3de8b2e5a04d21484ae5d1a8899c7116/CONTRIBUTING.org. Something like the following should be okay:

Allow user defined keys in translation rules

It should be possible to do amend the commit message and update this pull request with the following commands:

git commit --amend
git push -f

I could also make this amend myself locally and merge it to main, however, when I do so the commit hash changes and GitHub does not recognise that this PR has been merged to main and therefore keeps this PR open. Of course, I could close this PR manually then. While making the GitHub PR workflow happy is not a major concern, it would make my work a little easier if you amend the commit message and update this PR.

I'll test this PR out a little more over the next few days. I am planning to merge this to the main branch in a week or two. Thanks again for taking the time to work with this project and creating this pull request.

[corytertel]

Any update on getting this merged?

[susam]

Thank you for your comment. I have now merged this to main. This fix will become available on MELPA in a few hours. Further, this fix will be part of the next release (version 0.7.0).