* Deprecation of define-key?
@ 2022-07-29 15:33 Philip Kaludercic
2022-07-29 16:16 ` Andreas Schwab
0 siblings, 1 reply; 15+ messages in thread
From: Philip Kaludercic @ 2022-07-29 15:33 UTC (permalink / raw)
To: emacs-devel
The docstring for `define-key' currently says:
This is a legacy function; see ‘keymap-set’ for the recommended
function to use instead.
yet `keymap-set' uses `define-key' internally. Is there a long-term
plan to re implement parts of keymap.el in C?
If not, this should be rephrased (my understanding up until now was that
keymap-* is a higher-level abstraction) I'd also like to suggest
distributing keymap on ELPA, as there seems to be interest in using the
new macros for packages that still support versions of Emacs prior to
29.0.50.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-07-29 15:33 Deprecation of define-key? Philip Kaludercic
@ 2022-07-29 16:16 ` Andreas Schwab
2022-07-30 11:46 ` Philip Kaludercic
0 siblings, 1 reply; 15+ messages in thread
From: Andreas Schwab @ 2022-07-29 16:16 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: emacs-devel
On Jul 29 2022, Philip Kaludercic wrote:
> The docstring for `define-key' currently says:
>
> This is a legacy function; see ‘keymap-set’ for the recommended
> function to use instead.
>
> yet `keymap-set' uses `define-key' internally. Is there a long-term
> plan to re implement parts of keymap.el in C?
>
> If not, this should be rephrased (my understanding up until now was that
> keymap-* is a higher-level abstraction)
I don't see any need. The use of define-key in keymap-set is an
implementation detail.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-07-29 16:16 ` Andreas Schwab
@ 2022-07-30 11:46 ` Philip Kaludercic
2022-07-30 11:51 ` Lars Ingebrigtsen
0 siblings, 1 reply; 15+ messages in thread
From: Philip Kaludercic @ 2022-07-30 11:46 UTC (permalink / raw)
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> On Jul 29 2022, Philip Kaludercic wrote:
>
>> The docstring for `define-key' currently says:
>>
>> This is a legacy function; see ‘keymap-set’ for the recommended
>> function to use instead.
>>
>> yet `keymap-set' uses `define-key' internally. Is there a long-term
>> plan to re implement parts of keymap.el in C?
>>
>> If not, this should be rephrased (my understanding up until now was that
>> keymap-* is a higher-level abstraction)
>
> I don't see any need. The use of define-key in keymap-set is an
> implementation detail.
That is obvious, the question is should package developers avoid using
`define-key' if possible or not?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-07-30 11:46 ` Philip Kaludercic
@ 2022-07-30 11:51 ` Lars Ingebrigtsen
2022-07-31 6:48 ` Jean Louis
2022-08-02 9:44 ` Augusto Stoffel
0 siblings, 2 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-30 11:51 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Andreas Schwab, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> That is obvious, the question is should package developers avoid using
> `define-key' if possible or not?
As the doc string says -- `keymap-set' is the recommended function to
use. However, `define-key' is not (and won't be) obsoleted, so it's up
to them to follow the recommendation (or not).
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-07-30 11:51 ` Lars Ingebrigtsen
@ 2022-07-31 6:48 ` Jean Louis
2022-07-31 7:14 ` Visuwesh
2022-08-02 9:44 ` Augusto Stoffel
1 sibling, 1 reply; 15+ messages in thread
From: Jean Louis @ 2022-07-31 6:48 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Philip Kaludercic, Andreas Schwab, emacs-devel
* Lars Ingebrigtsen <larsi@gnus.org> [2022-07-30 14:51]:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> > That is obvious, the question is should package developers avoid using
> > `define-key' if possible or not?
>
> As the doc string says -- `keymap-set' is the recommended function to
> use. However, `define-key' is not (and won't be) obsoleted, so it's up
> to them to follow the recommendation (or not).
After replacing `define-key' with `keymap-set' I got following:
Debugger entered--Lisp error: (error "[8388710] is not a valid key definition; see ‘key-valid-p’")
signal(error ("[8388710] is not a valid key definition; see ‘key-..."))
error("%S is not a valid key definition; see `key-valid-p..." [8388710])
keymap--check([8388710])
for this definition:
(keymap-set dired-mode-map (kbd "s-f") 'cf-file-for-person)
So how I am supposed to make it work? I need to use the super key and
F to file files under person's directory.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-07-31 6:48 ` Jean Louis
@ 2022-07-31 7:14 ` Visuwesh
0 siblings, 0 replies; 15+ messages in thread
From: Visuwesh @ 2022-07-31 7:14 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Philip Kaludercic, Andreas Schwab, emacs-devel
[ஞாயிறு ஜூலை 31, 2022] Jean Louis wrote:
> (keymap-set dired-mode-map (kbd "s-f") 'cf-file-for-person)
>
> So how I am supposed to make it work? I need to use the super key and
> F to file files under person's directory.
(keymap-set dired-mode-map "s-f" 'cf-file-for-person)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-07-30 11:51 ` Lars Ingebrigtsen
2022-07-31 6:48 ` Jean Louis
@ 2022-08-02 9:44 ` Augusto Stoffel
2022-08-02 9:54 ` Philip Kaludercic
2022-08-02 10:00 ` Lars Ingebrigtsen
1 sibling, 2 replies; 15+ messages in thread
From: Augusto Stoffel @ 2022-08-02 9:44 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Philip Kaludercic, Andreas Schwab, emacs-devel
On Sat, 30 Jul 2022 at 13:51, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> That is obvious, the question is should package developers avoid using
>> `define-key' if possible or not?
>
> As the doc string says -- `keymap-set' is the recommended function to
> use. However, `define-key' is not (and won't be) obsoleted, so it's up
> to them to follow the recommendation (or not).
I didn't catch any of the previous discussion about keymap.el, but I
have a comment -- sorry if redundant.
Wouldn't it make sense to let keymap-set take multiple key-definition
pairs as arguments, like setq et al? This would be very convenient
e.g. in user configuration files, where currently one often finds long
sequences of define-key calls. This looks much better to me:
(keymap-set some-map
"a" 'command-a
"b" 'command-b
"c" 'command-c)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-08-02 9:44 ` Augusto Stoffel
@ 2022-08-02 9:54 ` Philip Kaludercic
2022-08-02 10:01 ` Lars Ingebrigtsen
2022-08-02 10:00 ` Lars Ingebrigtsen
1 sibling, 1 reply; 15+ messages in thread
From: Philip Kaludercic @ 2022-08-02 9:54 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: Lars Ingebrigtsen, Andreas Schwab, emacs-devel
Augusto Stoffel <arstoffel@gmail.com> writes:
> On Sat, 30 Jul 2022 at 13:51, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> That is obvious, the question is should package developers avoid using
>>> `define-key' if possible or not?
>>
>> As the doc string says -- `keymap-set' is the recommended function to
>> use. However, `define-key' is not (and won't be) obsoleted, so it's up
>> to them to follow the recommendation (or not).
>
> I didn't catch any of the previous discussion about keymap.el, but I
> have a comment -- sorry if redundant.
>
> Wouldn't it make sense to let keymap-set take multiple key-definition
> pairs as arguments, like setq et al? This would be very convenient
> e.g. in user configuration files, where currently one often finds long
> sequences of define-key calls.
One thing I still don't understand about keymap (which is part of the
reason I initiated this thread), is who the "target audience" is, if
any? Core development, ELPA packages in general, user configurations,
or someone else?
> This looks much better to me:
>
> (keymap-set some-map
> "a" 'command-a
> "b" 'command-b
> "c" 'command-c)
Not quite the same, but that is what `defvar-keymap' allows you to do. E.g.
(defvar-keymap gnus-undo-mode-map
"C-M-_" #'gnus-undo
"C-_" #'gnus-undo
"C-x u" #'gnus-undo
;; many people are used to type `C-/' on GUI frames and get `C-_'.
"C-/" #'gnus-undo)
Just in this case binding a variable and defining a map is merged into
one, instead of modifying an existing map.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-08-02 9:44 ` Augusto Stoffel
2022-08-02 9:54 ` Philip Kaludercic
@ 2022-08-02 10:00 ` Lars Ingebrigtsen
2022-08-02 10:11 ` Philip Kaludercic
2022-08-02 10:14 ` Augusto Stoffel
1 sibling, 2 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-02 10:00 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: Philip Kaludercic, Andreas Schwab, emacs-devel
Augusto Stoffel <arstoffel@gmail.com> writes:
> Wouldn't it make sense to let keymap-set take multiple key-definition
> pairs as arguments, like setq et al? This would be very convenient
> e.g. in user configuration files, where currently one often finds long
> sequences of define-key calls. This looks much better to me:
>
> (keymap-set some-map
> "a" 'command-a
> "b" 'command-b
> "c" 'command-c)
I think that makes sense, and we'd just have to extend the definition
from
(keymap-set KEYMAP KEY DEFINITION)
to
(keymap-set KEYMAP KEY DEFINITION &rest PAIRS)
But how should the indentation be? It's not a definition form, so
indenting it like the above would be unusual.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-08-02 9:54 ` Philip Kaludercic
@ 2022-08-02 10:01 ` Lars Ingebrigtsen
2022-08-02 10:06 ` Philip Kaludercic
0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-02 10:01 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Augusto Stoffel, Andreas Schwab, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> One thing I still don't understand about keymap (which is part of the
> reason I initiated this thread), is who the "target audience" is, if
> any? Core development, ELPA packages in general, user configurations,
> or someone else?
Everybody?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-08-02 10:01 ` Lars Ingebrigtsen
@ 2022-08-02 10:06 ` Philip Kaludercic
2022-08-02 10:11 ` Lars Ingebrigtsen
0 siblings, 1 reply; 15+ messages in thread
From: Philip Kaludercic @ 2022-08-02 10:06 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Augusto Stoffel, Andreas Schwab, emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> One thing I still don't understand about keymap (which is part of the
>> reason I initiated this thread), is who the "target audience" is, if
>> any? Core development, ELPA packages in general, user configurations,
>> or someone else?
>
> Everybody?
In that case I think keymap.el should be make avalaible on ELPA, so it
can be reasonably used in packages before the year 2030. If there is no
interest or a technical reason against doing so, I would try replicating
the functionality in compat.el, but I haven't looked into what this
would mean in more detail.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-08-02 10:00 ` Lars Ingebrigtsen
@ 2022-08-02 10:11 ` Philip Kaludercic
2022-08-02 10:46 ` Lars Ingebrigtsen
2022-08-02 10:14 ` Augusto Stoffel
1 sibling, 1 reply; 15+ messages in thread
From: Philip Kaludercic @ 2022-08-02 10:11 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Augusto Stoffel, Andreas Schwab, emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> Wouldn't it make sense to let keymap-set take multiple key-definition
>> pairs as arguments, like setq et al? This would be very convenient
>> e.g. in user configuration files, where currently one often finds long
>> sequences of define-key calls. This looks much better to me:
>>
>> (keymap-set some-map
>> "a" 'command-a
>> "b" 'command-b
>> "c" 'command-c)
>
> I think that makes sense, and we'd just have to extend the definition
> from
>
> (keymap-set KEYMAP KEY DEFINITION)
>
> to
>
> (keymap-set KEYMAP KEY DEFINITION &rest PAIRS)
>
> But how should the indentation be? It's not a definition form, so
> indenting it like the above would be unusual.
Why should this kind of indentation only be used for definition forms?
I wouldn't consider `progn', `pcase', or `cl-callf' definitions, and
they all have the `lisp-indent-function' property set. I believe the
indentation that Augusto suggested is perfectly reasonable.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-08-02 10:06 ` Philip Kaludercic
@ 2022-08-02 10:11 ` Lars Ingebrigtsen
0 siblings, 0 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-02 10:11 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Augusto Stoffel, Andreas Schwab, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> In that case I think keymap.el should be make avalaible on ELPA, so it
> can be reasonably used in packages before the year 2030. If there is no
> interest or a technical reason against doing so, I would try replicating
> the functionality in compat.el, but I haven't looked into what this
> would mean in more detail.
Replicating it in compat.el would make more sense, I think.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-08-02 10:00 ` Lars Ingebrigtsen
2022-08-02 10:11 ` Philip Kaludercic
@ 2022-08-02 10:14 ` Augusto Stoffel
1 sibling, 0 replies; 15+ messages in thread
From: Augusto Stoffel @ 2022-08-02 10:14 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Philip Kaludercic, Andreas Schwab, emacs-devel
On Tue, 2 Aug 2022 at 12:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>> (keymap-set some-map
>> "a" 'command-a
>> "b" 'command-b
>> "c" 'command-c)
>
> But how should the indentation be? It's not a definition form, so
> indenting it like the above would be unusual.
I use the above indentation style in my personal config on the grounds
that the first argument is “special”.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Deprecation of define-key?
2022-08-02 10:11 ` Philip Kaludercic
@ 2022-08-02 10:46 ` Lars Ingebrigtsen
0 siblings, 0 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-02 10:46 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Augusto Stoffel, Andreas Schwab, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Why should this kind of indentation only be used for definition forms?
> I wouldn't consider `progn', `pcase', or `cl-callf' definitions, and
> they all have the `lisp-indent-function' property set.
But they're not normal functions.
> I believe the indentation that Augusto suggested is perfectly
> reasonable.
(keymap-set some-map
"a" 'command-a)
looks pretty odd to me, and I think anybody reading such code would
assume that `keymap-set' is a macro doing something odd.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2022-08-02 10:46 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-29 15:33 Deprecation of define-key? Philip Kaludercic
2022-07-29 16:16 ` Andreas Schwab
2022-07-30 11:46 ` Philip Kaludercic
2022-07-30 11:51 ` Lars Ingebrigtsen
2022-07-31 6:48 ` Jean Louis
2022-07-31 7:14 ` Visuwesh
2022-08-02 9:44 ` Augusto Stoffel
2022-08-02 9:54 ` Philip Kaludercic
2022-08-02 10:01 ` Lars Ingebrigtsen
2022-08-02 10:06 ` Philip Kaludercic
2022-08-02 10:11 ` Lars Ingebrigtsen
2022-08-02 10:00 ` Lars Ingebrigtsen
2022-08-02 10:11 ` Philip Kaludercic
2022-08-02 10:46 ` Lars Ingebrigtsen
2022-08-02 10:14 ` Augusto Stoffel
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.