unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Gilles <gilles.usenet@gmail.com>,
	"54161@debbugs.gnu.org" <54161@debbugs.gnu.org>
Subject: bug#54161: [External] : bug#54161: 27.2; `define-minor-mode' with alist of key bindings
Date: Sat, 26 Feb 2022 03:20:27 +0000	[thread overview]
Message-ID: <SJ0PR10MB54880F1793725B300C4DBA06F33F9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CAHf9+CvXQXvt5e0Hu64xZOu0USb5LhsnzLZyvQ44FHJ1KLhUKw@mail.gmail.com>

> > > where each KEY-SEQUENCE and DEFINITION are arguments suitable for
> > > passing to 'define-key'.

As a starter, it would be better to say "arguments suitable
for `define-key', and not speak of what you "pass" to it.

> > I think that's the case in these examples, no?  Both (kbd "C-o") and
> > "\C-o" are suitable args for `define-key'.
> 
> The Lisp object (kbd "C-o") (a two-element list) is not a suitable
> argument for define-key. The Lisp *expression* (kbd "C-o") *returns*
> a suitable argument for define-key.

Sure.  It depends on how one reads "passing" an arg.  And
notice that you wrote "suitable argument for define-key,
which already shifts the focus to what the function accepts
and not to what you "pass" it.

A user writes an argument expression in a function-application
expression "(define-key...)".  Lisp evals each argument
expression and applies the function that's the car of the
overall expression to the evaluated arg expressions.

The function receives Lisp objects. The user writes an
expression - especially in the typical case of using
`define-key' or `:keymap'.

It's easy to read "passing" as being about the expressions
you write, even if that's not ultimately all that's involved.
And especially for something like `define-key' and arg
expressions like (kbd...).

The odd "tolerance" (if that's what it is) of (kbd "<")
confuses things further wrt the behavior.  As agreed in
the source Q&A in emacs.SE, neither of us understands why
the same error is NOT raised for (kbd "<") as is raised
for (kbd "C-<").  In both cases if the alist arg to
:keymap is quoted then what gets passed is a 2-element
list with car `kbd'.  Why does (kbd "<") work?  That can
lead (did lead) to the confusion about (kbd "C-<").

"Something you can pass to define-key" can mislead, even
if correct when viewed right.  This should be worded in
some less ambiguous way in the doc.  It's possible to think
of "passing" (kbd "C->") to define-key - it all depends on
how one interprets "passing" something to a function.

An example in the doc would help, along with speaking of
something "acceptable to `define-key' as an arg - something
such as what `kbd returns."  Putting the emphasis on what
the function accepts rather than on what you "pass" can tend
to shift the focus from an expression you write to the result
of its evaluation, which is what the function receives.

Yes, the function is passed the result of evaluating the
sexp.  But it's easy to think of what you write as being
what you "pass" to the function.  Especially if you try
"passing" (writing) "(kbd ">")" and no error is raised.
It's the inconsistency that misled, and made the user
think that there was a particular problem with (kbd "C->"). 

  reply	other threads:[~2022-02-26  3:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25 17:48 bug#54161: 27.2; `define-minor-mode' with alist of key bindings Drew Adams
2022-02-25 21:41 ` Gilles
2022-02-26  3:20   ` Drew Adams [this message]
2022-02-28  9:46   ` Lars Ingebrigtsen
2022-03-01  1:21   ` Michael Heerdegen
2022-03-01 15:41     ` Lars Ingebrigtsen
2022-03-01 18:16       ` bug#54161: [External] : " Drew Adams
2022-03-01 22:18         ` Michael Heerdegen
2022-03-01 22:52           ` Lars Ingebrigtsen
2022-03-01 23:56             ` Michael Heerdegen
2022-03-02  0:04               ` Michael Heerdegen
2022-03-01 18:11     ` Drew Adams
2022-02-25 22:33 ` Drew Adams
2022-02-25 22:43   ` Drew Adams

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=SJ0PR10MB54880F1793725B300C4DBA06F33F9@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=54161@debbugs.gnu.org \
    --cc=gilles.usenet@gmail.com \
    /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).