[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [External] : Re: Moving kbd to subr.el
From: |
Drew Adams |
Subject: |
RE: [External] : Re: Moving kbd to subr.el |
Date: |
Tue, 19 Oct 2021 17:51:50 +0000 |
> this is all in the archives.
I'm sure it is. The request was for a _summary_
of the problem and why we would want to "replace
any use of" kbd, which was presented as the
"overarching plan".
> Here is one possible starting point:
> https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01098.html
Thanks. But what part of "summary" was unclear?
A pointer to the archives isn't what I had in mind.
> If you want to dig even deeper, see the test-cases
> in subr-tests.el, and the rest of this thread.
I asked for a summary, not a pointer to piles to
search through.
___
If your "starting point" is intended as a summary
of why we need to replace kbd then FWIW I'm not
convinced.
`kbd' accepts as input what Emacs itself writes
as help descriptions of key sequences.
Wrt your "starting point":
* _Emacs_ doesn't write "f 1" for what you apparently
expect/want. It writes "f <SPC> 1" for that.
And kbd correctly returns "f 1" for that, as that
return value can be used to bind a key.
* _Emacs_ doesn't write "f1" for what you apparently
expect/want. It writes "<f1>". And kbd correctly
returns [f1].
* _Emacs_ doesn't write "return" for what... It
writes "<return>". And kbd returns [return].
It's about how _Emacs_ itself talks to users about
keys - the names/descriptions it gives them in its
Help. Users of `kbd' can talk to Emacs in the same
terms that Emacs talks to them about keys.
`kbd' expects as input a description such as Emacs
itself uses in its help output. If you pass `kbd'
text that Emacs does NOT use as a key description
then all bets are off.
But if you find some _legitimate_ key description
(i.e., syntax that Emacs itself uses) that `kbd'
mishandles, maybe file a bug report for that?
Perhaps `kbd' should raise an error if its input
is _not_ a legitimate Emacs key description?
Would that have helped you avoid listing such
expressions as being problems with `kbd', i.e.,
reasons to replace `kbd'?
___
As for replacing syntax "\C-a" with "C-a", outside
of any use of `kbd': that's a different question,
I think.
That question doesn't seem to fit either your
"starting point" or Lars's confirmation that the
"overarching plan" is to replace `kbd'.
There seems to be more "arching" going on in this
thread than is contained in the "overarching plan".
I'd still like to see a clear summary of what are
thought to be the problems to solve, and what are
the proposed solutions. (Again, "summary", not
pointers to a discussion wall.)
- Re: Moving kbd to subr.el, (continued)
- Re: Moving kbd to subr.el, Lars Ingebrigtsen, 2021/10/18
- Re: Moving kbd to subr.el, Juri Linkov, 2021/10/19
- Re: Moving kbd to subr.el, Gregory Heytings, 2021/10/19
- Re: Moving kbd to subr.el, Philip Kaludercic, 2021/10/19
- Re: Moving kbd to subr.el, Gregory Heytings, 2021/10/19
- RE: [External] : Re: Moving kbd to subr.el, Drew Adams, 2021/10/19
- RE: [External] : Re: Moving kbd to subr.el, Stefan Kangas, 2021/10/19
- RE: [External] : Re: Moving kbd to subr.el,
Drew Adams <=
- RE: [External] : Re: Moving kbd to subr.el, Drew Adams, 2021/10/19
- Re: Moving kbd to subr.el, Richard Stallman, 2021/10/20
- Re: Moving kbd to subr.el, Richard Stallman, 2021/10/20
- Re: Moving kbd to subr.el, Po Lu, 2021/10/21
- Re: Moving kbd to subr.el, Stefan Monnier, 2021/10/19
- Re: Moving kbd to subr.el, Lars Ingebrigtsen, 2021/10/19
- Re: Moving kbd to subr.el, Stefan Kangas, 2021/10/19
- Re: Moving kbd to subr.el, Lars Ingebrigtsen, 2021/10/19
- Re: Moving kbd to subr.el, Stefan Kangas, 2021/10/19
- Re: Moving kbd to subr.el, Lars Ingebrigtsen, 2021/10/19