GNU bug report logs - #55393
describe-keymap: suggest symbol at point

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55393 in the body.
You can then email your comments to 55393 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: describe-keymap: suggest symbol at point
Date: Fri, 13 May 2022 09:35:25 +0530

[Message part 1 (text/plain, inline)]

Tags: patch

describe-keymap differs from other describe-* commands in that it does
not suggest the symbol at point which always annoyed me.  This patch
makes describe-keymap consider the symbol at point first.

[ I hope it is okay to use if-let family of macros in these files now?  ]

[0001-describe-keymap-Suggest-symbol-at-point.patch (text/patch, attachment)]

[Message part 3 (text/plain, inline)]

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
Repository revision: ca3858563c7ba8ee3caa82fbd2b7c386ea60c0d3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: NixOS 21.11 (Porcupine)

Configured using:
 'configure
 --prefix=/nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0
 --disable-build-details --with-modules --with-x-toolkit=lucid
 --with-xft --with-cairo --with-native-compilation'

Message #8 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: 55393 <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Fri, 13 May 2022 10:54:12 +0530

[Message part 1 (text/plain, inline)]

[வெள்ளி மே 13, 2022] Visuwesh wrote:

> Tags: patch
>
> describe-keymap differs from other describe-* commands in that it does
> not suggest the symbol at point which always annoyed me.  This patch
> makes describe-keymap consider the symbol at point first.
>
> [ I hope it is okay to use if-let family of macros in these files now?  ]
>
>
>
>
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
> Repository revision: ca3858563c7ba8ee3caa82fbd2b7c386ea60c0d3
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
> System Description: NixOS 21.11 (Porcupine)
>
> Configured using:
>  'configure
>  --prefix=/nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0
>  --disable-build-details --with-modules --with-x-toolkit=lucid
>  --with-xft --with-cairo --with-native-compilation'

Turns out I did not git pull master properly so that patch was against
an old master.  Updated patch attached here,

[0001-describe-keyap-Suggest-symbol-at-point.patch (text/x-patch, inline)]

From 1911ea3d4963bc945953886fb625db6c838f19cb Mon Sep 17 00:00:00 2001
From: Visuwesh <visuweshm <at> gmail.com>
Date: Fri, 13 May 2022 10:52:09 +0530
Subject: [PATCH] describe-keyap: Suggest symbol at point

* lisp/help-fns.el (help-fns--most-relevant-active-keymap): Suggest
the symbol at point if it is a keymap.
* etc/NEWS: Announce the change.
---
 etc/NEWS         |  5 +++++
 lisp/help-fns.el | 19 ++++++++++++-------
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index e09834c..54647b8 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -562,6 +562,11 @@ minor modes are listed after the major mode.
 The apropos commands will now select the apropos window if
 'help-window-select' is non-nil.
 
+---
+*** 'describe-keymap' now considers the symbol at point
+'describe-keymap' suggests the symbol at point as the default candidate
+if it is a keymap.
+
 ** Outline Mode
 
 +++
diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 927a4f0..2636ba9 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -1884,16 +1884,21 @@ variable with value KEYMAP."
 The heuristic to determine which keymap is most likely to be
 relevant to a user follows this order:
 
-1. 'keymap' text property at point
-2. 'local-map' text property at point
-3. the `current-local-map'
+1. symbol at point
+2. 'keymap' text property at point
+3. 'local-map' text property at point
+4. the `current-local-map'
 
 This is used to set the default value for the interactive prompt
 in `describe-keymap'.  See also `Searching the Active Keymaps'."
-  (help-fns-find-keymap-name (or (get-char-property (point) 'keymap)
-                         (if (get-text-property (point) 'local-map)
-                             (get-char-property (point) 'local-map)
-                           (current-local-map)))))
+  (if-let ((sym (symbol-at-point))
+           (sym (when sym (intern-soft sym)))
+           (keymapp (ignore-errors (symbol-value sym))))
+      sym
+    (help-fns-find-keymap-name (or (get-char-property (point) 'keymap)
+                           (if (get-text-property (point) 'local-map)
+                               (get-char-property (point) 'local-map)
+                             (current-local-map))))))
 
 (defvar keymap-name-history nil
   "History for input to `describe-keymap'.")
-- 
2.33.1

Message #11 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 55393 <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Fri, 13 May 2022 09:23:06 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Fri, 13 May 2022 09:35:25 +0530
> 
> describe-keymap differs from other describe-* commands in that it does
> not suggest the symbol at point which always annoyed me.  This patch
> makes describe-keymap consider the symbol at point first.
> 
> [ I hope it is okay to use if-let family of macros in these files now?  ]

Yes, but I think a cleaner solution would be to do this kind of stuff
in the 'interactive' form of describe-keymap, instead of this
subroutine.  The DWIM-ish operation of describe-SOMETHING commands is
better done there, because it doesn't really belong to non-interactive
invocations.

Thanks.

Message #14 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55393 <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Fri, 13 May 2022 12:05:42 +0530

[வெள்ளி மே 13, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Date: Fri, 13 May 2022 09:35:25 +0530
>> 
>> describe-keymap differs from other describe-* commands in that it does
>> not suggest the symbol at point which always annoyed me.  This patch
>> makes describe-keymap consider the symbol at point first.
>> 
>> [ I hope it is okay to use if-let family of macros in these files now?  ]
>
> Yes, but I think a cleaner solution would be to do this kind of stuff
> in the 'interactive' form of describe-keymap, instead of this
> subroutine.  The DWIM-ish operation of describe-SOMETHING commands is
> better done there, because it doesn't really belong to non-interactive
> invocations.
>
> Thanks.

The 'interactive' form of describe-keymap uses this function.  I don't
see this function being used anywhere else either.

Message #17 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 55393 <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Fri, 13 May 2022 09:51:42 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 55393 <at> debbugs.gnu.org
> Date: Fri, 13 May 2022 12:05:42 +0530
> 
> > Yes, but I think a cleaner solution would be to do this kind of stuff
> > in the 'interactive' form of describe-keymap, instead of this
> > subroutine.  The DWIM-ish operation of describe-SOMETHING commands is
> > better done there, because it doesn't really belong to non-interactive
> > invocations.
> >
> > Thanks.
> 
> The 'interactive' form of describe-keymap uses this function.  I don't
> see this function being used anywhere else either.

Nothing prevents future reuse of the subroutine in another place.  I
would prefer to have this code directly in the interactive form, to be
more future-proof.  And note that the if-let form's result is not used
in any way in the rest of the code of that function, which also speaks
volumes of its being an independent issue.

Message #20 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55393 <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Fri, 13 May 2022 13:12:26 +0530

[Message part 1 (text/plain, inline)]

[வெள்ளி மே 13, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 55393 <at> debbugs.gnu.org
>> Date: Fri, 13 May 2022 12:05:42 +0530
>> 
>> > Yes, but I think a cleaner solution would be to do this kind of stuff
>> > in the 'interactive' form of describe-keymap, instead of this
>> > subroutine.  The DWIM-ish operation of describe-SOMETHING commands is
>> > better done there, because it doesn't really belong to non-interactive
>> > invocations.
>> >
>> > Thanks.
>> 
>> The 'interactive' form of describe-keymap uses this function.  I don't
>> see this function being used anywhere else either.
>
> Nothing prevents future reuse of the subroutine in another place.  I
> would prefer to have this code directly in the interactive form, to be
> more future-proof.  And note that the if-let form's result is not used
> in any way in the rest of the code of that function, which also speaks
> volumes of its being an independent issue.

Now done, please check.

[0001-describe-keymap-Suggest-symbol-at-point.patch (text/x-patch, attachment)]

Message #23 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 55393 <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Fri, 13 May 2022 15:06:40 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 55393 <at> debbugs.gnu.org
> Date: Fri, 13 May 2022 13:12:26 +0530
> 
> >> The 'interactive' form of describe-keymap uses this function.  I don't
> >> see this function being used anywhere else either.
> >
> > Nothing prevents future reuse of the subroutine in another place.  I
> > would prefer to have this code directly in the interactive form, to be
> > more future-proof.  And note that the if-let form's result is not used
> > in any way in the rest of the code of that function, which also speaks
> > volumes of its being an independent issue.
> 
> Now done, please check.

LGTM, thanks.

A minor nit:

> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -562,6 +562,11 @@ minor modes are listed after the major mode.
>  The apropos commands will now select the apropos window if
>  'help-window-select' is non-nil.
>  
> +---
> +*** 'describe-keymap' now considers the symbol at point.
> +'describe-keymap' suggests the symbol at point as the default
> +candidate if it is a keymap.

That "it" is ambiguous, since it could allude to more than one entity
mentioned before it.  I suggest to change the order, so that "if it is
a keymap" directly follows "symbol at point".

Let's wait for a day or two to let others time to comment on this.

Message #26 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55393 <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Fri, 13 May 2022 18:17:11 +0530

[Message part 1 (text/plain, inline)]

[வெள்ளி மே 13, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 55393 <at> debbugs.gnu.org
>> Date: Fri, 13 May 2022 13:12:26 +0530
>> 
>> >> The 'interactive' form of describe-keymap uses this function.  I don't
>> >> see this function being used anywhere else either.
>> >
>> > Nothing prevents future reuse of the subroutine in another place.  I
>> > would prefer to have this code directly in the interactive form, to be
>> > more future-proof.  And note that the if-let form's result is not used
>> > in any way in the rest of the code of that function, which also speaks
>> > volumes of its being an independent issue.
>> 
>> Now done, please check.
>
> LGTM, thanks.
>
> A minor nit:
>
>> --- a/etc/NEWS
>> +++ b/etc/NEWS
>> @@ -562,6 +562,11 @@ minor modes are listed after the major mode.
>>  The apropos commands will now select the apropos window if
>>  'help-window-select' is non-nil.
>>  
>> +---
>> +*** 'describe-keymap' now considers the symbol at point.
>> +'describe-keymap' suggests the symbol at point as the default
>> +candidate if it is a keymap.
>
> That "it" is ambiguous, since it could allude to more than one entity
> mentioned before it.  I suggest to change the order, so that "if it is
> a keymap" directly follows "symbol at point".
>

I changed the text to,

    *** 'describe-keymap' now considers the symbol at point.
    If the symbol at point is a keymap, 'describe-keymap' suggests it as
    the default candidate.

Updated patch below,

[0001-describe-keymap-Suggest-symbol-at-point.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

> Let's wait for a day or two to let others time to comment on this.

Sure!

Message #31 received at 55393-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 55393-done <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Sun, 15 May 2022 08:26:30 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 55393 <at> debbugs.gnu.org
> Date: Fri, 13 May 2022 18:17:11 +0530
> 
> I changed the text to,
> 
>     *** 'describe-keymap' now considers the symbol at point.
>     If the symbol at point is a keymap, 'describe-keymap' suggests it as
>     the default candidate.

Perfect, thanks.

> > Let's wait for a day or two to let others time to comment on this.
> 
> Sure!

No further comments, so I've now installed this on the master branch.

One nit for the future: please always mention the bug number, when
it's known, in the commit log message.  (I added it for you this
time.)

And with that, I'm closing the bug.  Thanks  for working on this.

Message #34 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: 55393 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Sun, 15 May 2022 11:18:08 +0530

[ஞாயிறு மே 15, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 55393 <at> debbugs.gnu.org
>> Date: Fri, 13 May 2022 18:17:11 +0530
>> 
>> I changed the text to,
>> 
>>     *** 'describe-keymap' now considers the symbol at point.
>>     If the symbol at point is a keymap, 'describe-keymap' suggests it as
>>     the default candidate.
>
> Perfect, thanks.
>
>> > Let's wait for a day or two to let others time to comment on this.
>> 
>> Sure!
>
> No further comments, so I've now installed this on the master branch.
>
> One nit for the future: please always mention the bug number, when
> it's known, in the commit log message.  (I added it for you this
> time.)
>

Sorry, I keep forgetting about this.  I will make sure to remember 
next time.
[ BTW, there's no way to know what the bug number will be when I first
  do M-x submit-emacs-patch, is there?  ]

> And with that, I'm closing the bug.  Thanks  for working on this.

Message #37 received at 55393 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 55393 <at> debbugs.gnu.org
Subject: Re: bug#55393: describe-keymap: suggest symbol at point
Date: Sun, 15 May 2022 09:19:08 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: eliz <at> gnu.org
> Date: Sun, 15 May 2022 11:18:08 +0530
> 
> [ஞாயிறு மே 15, 2022] Eli Zaretskii wrote:
> 
> > One nit for the future: please always mention the bug number, when
> > it's known, in the commit log message.  (I added it for you this
> > time.)
> >
> 
> Sorry, I keep forgetting about this.  I will make sure to remember 
> next time.
> [ BTW, there's no way to know what the bug number will be when I first
>   do M-x submit-emacs-patch, is there?  ]

No, there isn't.  (Some people first report the problem, and then post
the patch in a separate message, once they receive the response from
the bug tracker with the bug number, for this very reason.)  So for
the first submission you cannot put the number there.  However, for
the other submissions you can add it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.