From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.bugs Subject: bug#43617: 27.1; Define-minor-mode keybindings not get precedence over global keymap Date: Sun, 27 Sep 2020 13:00:51 +0200 Message-ID: References: <53faa17bc88194ba2a67440eb1ddd139ea1188c3.camel@gmail.com> <87eemoljlj.fsf@gnus.org> <878scwljdp.fsf@gnus.org> <59b95abb-1c57-4a94-b6e0-7f4bdeef72ee@default> <87h7rk1rkt.fsf@igel.home> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002de05e05b04977c3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38053"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43617@debbugs.gnu.org, Lars Ingebrigtsen , Andreas Schwab To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 27 13:02:26 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kMURm-0009oH-7b for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Sep 2020 13:02:26 +0200 Original-Received: from localhost ([::1]:38650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kMURl-0005I9-AC for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Sep 2020 07:02:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kMURR-0005Go-Ub for bug-gnu-emacs@gnu.org; Sun, 27 Sep 2020 07:02:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36918) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kMURO-0006rm-3t for bug-gnu-emacs@gnu.org; Sun, 27 Sep 2020 07:02:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kMURO-0008Kw-23 for bug-gnu-emacs@gnu.org; Sun, 27 Sep 2020 07:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Sep 2020 11:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 43617-submit@debbugs.gnu.org id=B43617.160120447331989 (code B ref 43617); Sun, 27 Sep 2020 11:02:02 +0000 Original-Received: (at 43617) by debbugs.gnu.org; 27 Sep 2020 11:01:13 +0000 Original-Received: from localhost ([127.0.0.1]:48464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kMUQb-0008Jt-7Y for submit@debbugs.gnu.org; Sun, 27 Sep 2020 07:01:13 -0400 Original-Received: from mail-vk1-f176.google.com ([209.85.221.176]:33198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kMUQV-0008Jc-So for 43617@debbugs.gnu.org; Sun, 27 Sep 2020 07:01:11 -0400 Original-Received: by mail-vk1-f176.google.com with SMTP id q13so874307vkd.0 for <43617@debbugs.gnu.org>; Sun, 27 Sep 2020 04:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WPpozd4Nf1WFumL96rmo7BxoZRYKCxs3hZIKWTWfFqA=; b=El8nyGgZSVIT/jU0kUb+MkQG77VShDb6IFHYOKConUP0w5MVNZvGYpcOuoItDDuY5A kEfG99ZmEB5aFxWURUFcbG59vO0rgBdrzb+IDNA/pBjzekB3/FfT0Y6Xic17iVjRq+li Iwh9M1yGwLYlUI3hHIIqZMJIHHNwxUYeSFPBADsN2lK6qUngMZxo16MACETk+sIsSd3R 9RAjiB55R87uU83a+hzUZ76j04FZCZEKxfDevsvNJEhroj4X3xqTEu3ghqFHkRWnSzJG x2HkhPXhaNhdpHBXFTXFXKtajWqRWYjM2LLPwjcLI4DhmP+ND+U6B0c5cP20PqGrWQg1 YwBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WPpozd4Nf1WFumL96rmo7BxoZRYKCxs3hZIKWTWfFqA=; b=YdgDTYmPVAvxty/gRxY509CtK8XFhBUoR7pvSsKeTo46Gd7qNJP2kRe3LubkUnHpDi 9pB2/MZIfwh7mGCw91MX6SKZPCQE5O1SwLeLYKaKqKNKwzQW1g/226w1DDaspwpsnu1N DqOZvObyCveTRNoNfg8xFF0vmitah8NC8V50j14new9m7p19ImbWc5kmtoHXN5Kh+nYj gOzgE2AFp4gFcRmss/WjD0SDFIJjZRElTQ9hCE40oZhfCE6GXWpgnq94dirnY5FrCxum lIaQjYm3uMdBTtkGEaUwARVpAozZX0YPXeq+rWmAPa5WrTudWJR/zx0KFmxAaeQSHi59 uJKg== X-Gm-Message-State: AOAM530e9JBxG3wZ8VI9oI6nWlMwt9hU+ff759YtJfYWCZSCCg2jZaaS wCOq2b3xE5X6Vmi+C+TSTxGCcREH9cp6EHKwm2c= X-Google-Smtp-Source: ABdhPJxjltGY33bLdxva52Hl/brp2FpHktLbewlPmQJx0x2i1/OPROFlwJSKf/sAT57gh4o4sXrSyK7Rp3hdI+4D54Y= X-Received: by 2002:ac5:cd88:: with SMTP id i8mr3002512vka.4.1601204462147; Sun, 27 Sep 2020 04:01:02 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:189107 Archived-At: --0000000000002de05e05b04977c3 Content-Type: text/plain; charset="UTF-8" Well it seems quite obvious now that I simply overlooked the fact that quoting a list results in its elements not getting evaluated. I would argue that, although there might be no real bug in the doc, the doc still somehow helped me to overlook this fact. I think backquoting is not very much a hassle, but it would be nice to get reminded about it for when using the (kbd ...) construct. Of course if the (kbd "j") would not have worked I would have been less confused and maybe had found the mistake myself, but because that one did work it appeared to me to be a bug. Anyway, I think a simple change/addition in the docstring and/or the examples in section 23.3.3 of the elisp manual could help make things clearer. On Sat, 26 Sep 2020 at 18:05, Drew Adams wrote: > > > The cons ((kbd "C-n") . 'foo) is exactly such a > > > (KEY . BINDING) pair - both KEY and BINDING are > > > suitable arguments for `define-key'. > > > > Is it? > > > > ELISP> (define-key global-map '(kbd "C-n") ''foo) > > *** Eval error *** Wrong type argument: arrayp, (kbd "C-n") > > I get your point. I guess maybe there are two ways > to read the doc string. > > The most _useful_ behavior for users, IMO, is for > `define-minor-mode' to allow expressions in arg > KEYMAP (when it's such a list) that correspond to > what a user writes in `(define-key ...)'. > > Is that particular list form of KEYMAP intended > mostly for programmatically supplying such a list, > or for users to write such a list? > > If the former, why is it needed/helpful at all, > since code can just as easily create a keymap arg. > If the latter, it gives users an easy way to write > key bindings directly for `define-minor-mode'. > > I hadn't even paid attention to the existence of > such a form for the KEYMAP arg. But it looks like > it could be handy for users to write - IF the sexp > to write is simple and straightforward. > > If users instead need to use backquote syntax or > jump through other hoops to write such a KEYMAP > sexp, then what's the point - what's the use case? > > Maybe there _is_ a programmatic use case. If so, > what is it? > --0000000000002de05e05b04977c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well it seems quite obvious now that I simply overlooked t= he fact that quoting a list results in its elements not getting evaluated. = I would argue that, although there might be no real bug in the doc, the doc= still somehow helped me to overlook this fact. I think backquoting is not = very much a hassle, but it would be nice to get reminded about it for when = using the (kbd ...) construct. Of course if the (kbd "j") would n= ot have worked I would have been less confused and maybe had found the mist= ake myself, but because that one did work it appeared to me to be a bug. An= yway, I think a simple change/addition in the docstring and/or the examples= in section 23.3.3 of the elisp manual could help make things clearer.
<= /div>
O= n Sat, 26 Sep 2020 at 18:05, Drew Adams <drew.adams@oracle.com> wrote:
> > The cons ((kbd "C-n") = . 'foo) is exactly such a
> > (KEY . BINDING) pair - both KEY and BINDING are
> > suitable arguments for `define-key'.
>
> Is it?
>
> ELISP> (define-key global-map '(kbd "C-n") ''= foo)
> *** Eval error ***=C2=A0 Wrong type argument: arrayp, (kbd "C-n&q= uot;)

I get your point.=C2=A0 I guess maybe there are two ways
to read the doc string.

The most _useful_ behavior for users, IMO, is for
`define-minor-mode' to allow expressions in arg
KEYMAP (when it's such a list) that correspond to
what a user writes in `(define-key ...)'.

Is that particular list form of KEYMAP intended
mostly for programmatically supplying such a list,
or for users to write such a list?

If the former, why is it needed/helpful at all,
since code can just as easily create a keymap arg.
If the latter, it gives users an easy way to write
key bindings directly for `define-minor-mode'.

I hadn't even paid attention to the existence of
such a form for the KEYMAP arg.=C2=A0 But it looks like
it could be handy for users to write - IF the sexp
to write is simple and straightforward.

If users instead need to use backquote syntax or
jump through other hoops to write such a KEYMAP
sexp, then what's the point - what's the use case?

Maybe there _is_ a programmatic use case.=C2=A0 If so,
what is it?
--0000000000002de05e05b04977c3--