From: acdw <acdw@acdw.net>
To: "Juri Linkov" <juri@linkov.net>
Cc: emacs-devel@gnu.org
Subject: Re: Suggestion for improving ergonomics of repeat-maps: define-repeat-map
Date: Fri, 10 Sep 2021 00:53:10 +0000 [thread overview]
Message-ID: <f93d9ca9-0780-407c-9c8f-e51076aa00b5@www.fastmail.com> (raw)
In-Reply-To: <874katproz.fsf@mail.linkov.net>
On 2021-09-09 (Thursday) at 17:50, Juri Linkov <juri@linkov.net> wrote:
> > I've written a package[1] for my own ease of use in defining
> > repeat-maps for Emacs 28, and a few people have told me I should see
> > about adding it to Emacs proper. So here we are.
>
> Thanks, this would be a nice addition.
>
> > (defvar case-repeat-map
> > (let ((map (make-sparse-keymap)))
> > (define-key map "c" #'capitalize-word)
> > (define-key map "u" #'upcase-word)
> > (define-key map "l" #'downcase-word)
> > ;; movement
> > (define-key map "f" #'forward-word-with-case)
> > (define-key map "b" #'backward-word-with-case)
> > map)
> > "A map to repeat word-casing commands. For use with `repeat-mode'.")
>
> The reason why currently in Emacs core repeat-maps are defined this way
> is because this is a standard way to define a keymap.
>
> If normal keymaps were defined with a macro similar to the macro
> that you created, it would be easier to migrate the existing repeat-maps
> to your macro. I mean if we had a macro `define-keymap' that defines
> normal keymaps and that is similar to your `define-repeat-map',
> then creating a repeat-map from the normal map would require just
> changing the macro name `define-keymap' to `define-repeat-map'.
I think this is an absolutely wonderful idea, especially to have `define-keymap' be more like `setq' (in fact, I think even more functions could be defined this way, but I digress). I can work on a `define-keymap' this weekend, and incorporate `define-repeat-keymap' in it :D
>
> > I wrote the macro `define-repeat-map' to alleviate this large amount
> > of configuration. Using this macro, the above turns into this:
> >
> > ~~~
> > (define-repeat-map case
> > ("c" capitalize-word
> > "u" upcase-word
> > "l" downcase-word)
> > (:continue "f" forward-word
> > "b" backward-word)
> > (:enter downcase-dwim
> > upcase-dwim
> > capitalize-dwim))
>
> I'd like to hear more opinions whether the above macro is a better
> way to define repeat-maps in Emacs core. I'm sure this macro is nice
> to use in a personal customization init file, but the question is
> about using it in Emacs core. If this will be preferable for Emacs core,
> then it could be included in repeat.el. Otherwise, GNU ELPA is a better place.
> Then for Emacs core I'd suggest at least to add another macro
> 'define-repeat-key' that will remove the need of adding manually
> `(put command 'repeat-map 'case-repeat-map)`, e.g.:
>
> (defvar case-repeat-map
> (let ((map (make-sparse-keymap)))
> (define-repeat-key map "c" #'capitalize-word)
> (define-repeat-key map "u" #'upcase-word)
> (define-repeat-key map "l" #'downcase-word)
> ;; movement
> (define-repeat-key map "f" #'forward-word-with-case)
> (define-repeat-key map "b" #'backward-word-with-case)
> map)
>
> Then it will preserve the same style already used in core.
This is the biggest reason I'm asking about `define-repeat-map' here; It's definitely a user-configuration-ease type macro/function (honestly this probably should be a function, the more I think about it). It's not very "Emacs-y", from what I've seen of the "Emacs-y" way to do things.
However, `define-repeat-key' /does/ have some functionality that's not included in even the code you've included: it automatically creates the necessary aliases for continuation commands, which you'd need to do separately to create `forward-word-with-case' and `backward-word-with-case', above.
Though now that I'm thinking of it, I'd probably rewrite your example to include
(define-repeat-key map "f" (defalias 'forward-word-with-case 'forward-word))
Though I don't think /that's/ very "Emacs-y", either.
At the very least I'd be happy to add `define-repeat-map' or something like it to ELPA.
--
~ acdw
acdw.net | breadpunk.club/~breadw
prev parent reply other threads:[~2021-09-10 0:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-08 3:22 Suggestion for improving ergonomics of repeat-maps: define-repeat-map acdw
2021-09-08 14:54 ` Philip Kaludercic
2021-09-08 17:01 ` acdw
2021-09-09 17:50 ` Juri Linkov
2021-09-09 18:06 ` Lars Ingebrigtsen
2021-09-09 20:35 ` Augusto Stoffel
2021-09-09 20:39 ` Lars Ingebrigtsen
2021-09-10 0:53 ` acdw
2021-09-10 10:53 ` Lars Ingebrigtsen
2021-10-04 8:22 ` Lars Ingebrigtsen
2021-10-04 9:05 ` Adam Porter
2021-10-04 9:49 ` Lars Ingebrigtsen
2021-10-04 11:29 ` Adam Porter
2021-10-04 11:33 ` Lars Ingebrigtsen
2021-10-04 18:18 ` Juri Linkov
2021-10-04 19:02 ` Lars Ingebrigtsen
2021-10-04 19:24 ` Stefan Monnier
2021-10-04 19:54 ` Lars Ingebrigtsen
2021-10-04 20:16 ` Lars Ingebrigtsen
2021-09-10 0:53 ` acdw [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f93d9ca9-0780-407c-9c8f-e51076aa00b5@www.fastmail.com \
--to=acdw@acdw.net \
--cc=emacs-devel@gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).