* Request: Specification For Denoting Keys
@ 2020-10-06 0:35 T.V Raman
2020-10-06 6:29 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: T.V Raman @ 2020-10-06 0:35 UTC (permalink / raw)
To: emacs-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 314 bytes --]
I'm looking for a specification for how keys are specified for function
kbd (found in edmacro.el).
For context, see this article I wrote up while looking into this:
https://emacspeak.blogspot.com/2020/10/on-defining-keys-in-emacs.html
--Raman
--
Thanks,
--Raman
7©4 Id: kg:/m/0285kf1 •0Ü8
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request: Specification For Denoting Keys
2020-10-06 0:35 Request: Specification For Denoting Keys T.V Raman
@ 2020-10-06 6:29 ` Eli Zaretskii
2020-10-06 14:37 ` T.V Raman
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2020-10-06 6:29 UTC (permalink / raw)
To: T.V Raman; +Cc: emacs-devel
> From: "T.V Raman" <raman@google.com>
> Date: Mon, 05 Oct 2020 17:35:50 -0700
>
> I'm looking for a specification for how keys are specified for function
> kbd (found in edmacro.el).
>
> For context, see this article I wrote up while looking into this:
> https://emacspeak.blogspot.com/2020/10/on-defining-keys-in-emacs.html
Can you tell what is missing from the node "Key Sequences" in the
ELisp manual? AFAICS, it provides examples of most (all?) possible
key "kinds" (characters, modifiers, function keys) that you could
need, but maybe we should expand that part.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request: Specification For Denoting Keys
2020-10-06 6:29 ` Eli Zaretskii
@ 2020-10-06 14:37 ` T.V Raman
2020-10-06 14:50 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: T.V Raman @ 2020-10-06 14:37 UTC (permalink / raw)
To: eliz; +Cc: raman, emacs-devel
It gives examples, but it's unclear that it covers all notations that
have been used in the wild over the years --- as in "everything in the
info node is handled by (kbd ...)" but not everything handled by (kbd
...) is in the info node. I'm not saying that the latter should
happen, I'm looking at what a new parallel ( (call it keyname)
function should be prepared to consume.Eli Zaretskii writes:
> > From: "T.V Raman" <raman@google.com>
> > Date: Mon, 05 Oct 2020 17:35:50 -0700
> >
> > I'm looking for a specification for how keys are specified for function
> > kbd (found in edmacro.el).
> >
> > For context, see this article I wrote up while looking into this:
> > https://emacspeak.blogspot.com/2020/10/on-defining-keys-in-emacs.html
>
> Can you tell what is missing from the node "Key Sequences" in the
> ELisp manual? AFAICS, it provides examples of most (all?) possible
> key "kinds" (characters, modifiers, function keys) that you could
> need, but maybe we should expand that part.
--
♉Id: kg:/m/0285kf1 🦮♉
--
♉Id: kg:/m/0285kf1 🦮♉
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request: Specification For Denoting Keys
2020-10-06 14:37 ` T.V Raman
@ 2020-10-06 14:50 ` Stefan Monnier
2020-10-06 15:05 ` T.V Raman
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2020-10-06 14:50 UTC (permalink / raw)
To: T.V Raman; +Cc: eliz, emacs-devel
> It gives examples, but it's unclear that it covers all notations that
> have been used in the wild over the years --- as in "everything in the
> info node is handled by (kbd ...)" but not everything handled by (kbd
> ...) is in the info node. I'm not saying that the latter should
> happen, I'm looking at what a new parallel ( (call it keyname)
> function should be prepared to consume.
I'm not sure I understand what you're getting at, but `kbd` should
(hopefully) be the reverse of `key-description`. IIRC there are a few
discrepancies between the two functions, but they should be considered
as bugs rather than as features.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Request: Specification For Denoting Keys
2020-10-06 14:50 ` Stefan Monnier
@ 2020-10-06 15:05 ` T.V Raman
2020-10-06 15:10 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: T.V Raman @ 2020-10-06 15:05 UTC (permalink / raw)
To: monnier; +Cc: raman, eliz, emacs-devel
thx. Because kbd traces back to reading in recorded kbd macros, it
does more than what a function that you use in defining keys need to
do -- look at edmacro-parse-keys to see what I mean by the above. For
instance, kbd handles things like M-x command-name that might have
been invoked while defining or recording a macro.
Stefan Monnier writes:
> > It gives examples, but it's unclear that it covers all notations that
> > have been used in the wild over the years --- as in "everything in the
> > info node is handled by (kbd ...)" but not everything handled by (kbd
> > ...) is in the info node. I'm not saying that the latter should
> > happen, I'm looking at what a new parallel ( (call it keyname)
> > function should be prepared to consume.
>
> I'm not sure I understand what you're getting at, but `kbd` should
> (hopefully) be the reverse of `key-description`. IIRC there are a few
> discrepancies between the two functions, but they should be considered
> as bugs rather than as features.
>
>
> Stefan
--
♉Id: kg:/m/0285kf1 🦮♉
--
♉Id: kg:/m/0285kf1 🦮♉
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request: Specification For Denoting Keys
2020-10-06 15:05 ` T.V Raman
@ 2020-10-06 15:10 ` Stefan Monnier
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2020-10-06 15:10 UTC (permalink / raw)
To: T.V Raman; +Cc: eliz, emacs-devel
> thx. Because kbd traces back to reading in recorded kbd macros, it
> does more than what a function that you use in defining keys need to
> do -- look at edmacro-parse-keys to see what I mean by the above. For
> instance, kbd handles things like M-x command-name that might have
> been invoked while defining or recording a macro.
Indeed, that's a historical accident.
First came the `edmacro` package and then people started (ab)using its
`read-kbd-macro` function for the more simple task of parsing
a slightly more human-friendly textual representation of keys sequences
than what you get by just using the "raw event vector".
Nobody took on the task of separating the two, so that's that.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-06 15:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-10-06 0:35 Request: Specification For Denoting Keys T.V Raman
2020-10-06 6:29 ` Eli Zaretskii
2020-10-06 14:37 ` T.V Raman
2020-10-06 14:50 ` Stefan Monnier
2020-10-06 15:05 ` T.V Raman
2020-10-06 15:10 ` Stefan Monnier
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).