GNU bug report logs - #78905
31.0.50; Extra dot in C-h k output

Previous Next

To reply to this bug, email your comments to 78905 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Extra dot in C-h k output
Date: Thu, 26 Jun 2025 11:51:45 +0200

Hi,

On the current master, I see:

1. emacs -Q
2. C-x C-j
3. C-h k d

This produces a *Help* buffer saying:

  d runs the command dired-flag-file-deletion (found in dired-mode-map),
  which is an interactive byte-code-function in ‘dired.el’.

  It is bound to d.
  .

  (dired-flag-file-deletion ARG &optional INTERACTIVE)
  ...


Note the extra, unexpected dot and newline after "It is bound to d."


Best regards,

Eshel

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eshel Yaron <me <at> eshelyaron.com>, 78905 <at> debbugs.gnu.org
Subject: Re: bug#78905: 31.0.50; Extra dot in C-h k output
Date: Thu, 26 Jun 2025 12:54:37 +0200

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

On Thu, 26 Jun 2025 11:51:45 +0200 Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> wrote:

> Hi,
>
> On the current master, I see:
>
> 1. emacs -Q
> 2. C-x C-j
> 3. C-h k d
>
> This produces a *Help* buffer saying:
>
>   d runs the command dired-flag-file-deletion (found in dired-mode-map),
>   which is an interactive byte-code-function in ‘dired.el’.
>
>   It is bound to d.
>   .
>
>   (dired-flag-file-deletion ARG &optional INTERACTIVE)
>   ...
>
>
> Note the extra, unexpected dot and newline after "It is bound to d."

This is due to this commit:

commit ebeeced9e3ca94bbb679730155a2582bc12f8ea7
Author:     Eli Zaretskii <eliz <at> gnu.org>
Commit:     Eli Zaretskii <eliz <at> gnu.org>
CommitDate: Tue May 13 18:50:31 2025 +0300

    Fix description of a remapped command's bindings
    
    * lisp/help-fns.el (help-fns--key-bindings): Qualify the
    description of any menu-bar bindings by remapping.  (Bug#78391)

The following patch is a possible fix (at least, it prevents the extra
dot in the above recipe):

[Message part 2 (text/x-patch, inline)]

diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 481360b5d3c..81ca89ea0ac 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -632,7 +632,7 @@ help-fns--key-bindings
                              (format-message "`%s'" remapped)
 		           "an anonymous command"))
                   (princ "as well.\n"))
-                (or remapped (princ "."))
+                (or remapped (unless (bolp) (princ ".")))
                 (fill-region-as-paragraph start (point))))
             (ensure-empty-lines)))))))
 

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

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 78905 <at> debbugs.gnu.org
Subject: Re: bug#78905: 31.0.50; Extra dot in C-h k output
Date: Thu, 26 Jun 2025 15:15:47 +0300

> Date: Thu, 26 Jun 2025 11:51:45 +0200
> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> Hi,
> 
> On the current master, I see:
> 
> 1. emacs -Q
> 2. C-x C-j
> 3. C-h k d
> 
> This produces a *Help* buffer saying:
> 
>   d runs the command dired-flag-file-deletion (found in dired-mode-map),
>   which is an interactive byte-code-function in ‘dired.el’.
> 
>   It is bound to d.
>   .
> 
>   (dired-flag-file-deletion ARG &optional INTERACTIVE)
>   ...
> 
> 
> Note the extra, unexpected dot and newline after "It is bound to d."

Thanks.  Does the patch below fix the problem?

diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 481360b..e56433e 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -632,7 +632,7 @@ help-fns--key-bindings
                              (format-message "`%s'" remapped)
 		           "an anonymous command"))
                   (princ "as well.\n"))
-                (or remapped (princ "."))
+                (or remapped menus (princ "."))
                 (fill-region-as-paragraph start (point))))
             (ensure-empty-lines)))))))
 

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78905 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#78905: 31.0.50; Extra dot in C-h k output
Date: Thu, 26 Jun 2025 14:47:32 +0200

On Thu, 26 Jun 2025 15:15:47 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Date: Thu, 26 Jun 2025 11:51:45 +0200
>> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 
>> Hi,
>> 
>> On the current master, I see:
>> 
>> 1. emacs -Q
>> 2. C-x C-j
>> 3. C-h k d
>> 
>> This produces a *Help* buffer saying:
>> 
>>   d runs the command dired-flag-file-deletion (found in dired-mode-map),
>>   which is an interactive byte-code-function in ‘dired.el’.
>> 
>>   It is bound to d.
>>   .
>> 
>>   (dired-flag-file-deletion ARG &optional INTERACTIVE)
>>   ...
>> 
>> 
>> Note the extra, unexpected dot and newline after "It is bound to d."
>
> Thanks.  Does the patch below fix the problem?
>
> diff --git a/lisp/help-fns.el b/lisp/help-fns.el
> index 481360b..e56433e 100644
> --- a/lisp/help-fns.el
> +++ b/lisp/help-fns.el
> @@ -632,7 +632,7 @@ help-fns--key-bindings
>                               (format-message "`%s'" remapped)
>  		           "an anonymous command"))
>                    (princ "as well.\n"))
> -                (or remapped (princ "."))
> +                (or remapped menus (princ "."))
>                  (fill-region-as-paragraph start (point))))
>              (ensure-empty-lines)))))))
>  

Since the sexp `(or remapped menus (princ "."))' is within a sexp
beginning `(when menus ...)' and nothing nullifies `menus' within that
sexp, doesn't this change then make `(princ ".")' a no-op?

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 78905 <at> debbugs.gnu.org, me <at> eshelyaron.com
Subject: Re: bug#78905: 31.0.50; Extra dot in C-h k output
Date: Thu, 26 Jun 2025 16:05:13 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Eshel Yaron <me <at> eshelyaron.com>,  78905 <at> debbugs.gnu.org
> Date: Thu, 26 Jun 2025 14:47:32 +0200
> 
> Since the sexp `(or remapped menus (princ "."))' is within a sexp
> beginning `(when menus ...)' and nothing nullifies `menus' within that
> sexp, doesn't this change then make `(princ ".")' a no-op?

Sorry, a thinko.  The below is better, I hope.

diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 481360b..ff69227 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -632,7 +632,7 @@ help-fns--key-bindings
                              (format-message "`%s'" remapped)
 		           "an anonymous command"))
                   (princ "as well.\n"))
-                (or remapped (princ "."))
+                (or remapped (= (point) start) (princ "."))
                 (fill-region-as-paragraph start (point))))
             (ensure-empty-lines)))))))
 

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78905 <at> debbugs.gnu.org, me <at> eshelyaron.com
Subject: Re: bug#78905: 31.0.50; Extra dot in C-h k output
Date: Thu, 26 Jun 2025 16:10:48 +0200

On Thu, 26 Jun 2025 16:05:13 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Eshel Yaron <me <at> eshelyaron.com>,  78905 <at> debbugs.gnu.org
>> Date: Thu, 26 Jun 2025 14:47:32 +0200
>> 
>> Since the sexp `(or remapped menus (princ "."))' is within a sexp
>> beginning `(when menus ...)' and nothing nullifies `menus' within that
>> sexp, doesn't this change then make `(princ ".")' a no-op?
>
> Sorry, a thinko.  The below is better, I hope.
>
> diff --git a/lisp/help-fns.el b/lisp/help-fns.el
> index 481360b..ff69227 100644
> --- a/lisp/help-fns.el
> +++ b/lisp/help-fns.el
> @@ -632,7 +632,7 @@ help-fns--key-bindings
>                               (format-message "`%s'" remapped)
>  		           "an anonymous command"))
>                    (princ "as well.\n"))
> -                (or remapped (princ "."))
> +                (or remapped (= (point) start) (princ "."))
>                  (fill-region-as-paragraph start (point))))
>              (ensure-empty-lines)))))))

Yes, this is effectively equivalent to the patch I posted ;-)

Steve Berman

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78905 <at> debbugs.gnu.org
Subject: Re: bug#78905: 31.0.50; Extra dot in C-h k output
Date: Thu, 26 Jun 2025 16:21:49 +0200

Hi,

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Thu, 26 Jun 2025 16:05:13 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman <at> gmx.net>
>>> Cc: Eshel Yaron <me <at> eshelyaron.com>,  78905 <at> debbugs.gnu.org
>>> Date: Thu, 26 Jun 2025 14:47:32 +0200
>>> 
>>> Since the sexp `(or remapped menus (princ "."))' is within a sexp
>>> beginning `(when menus ...)' and nothing nullifies `menus' within that
>>> sexp, doesn't this change then make `(princ ".")' a no-op?
>>
>> Sorry, a thinko.  The below is better, I hope.
>>
>> diff --git a/lisp/help-fns.el b/lisp/help-fns.el
>> index 481360b..ff69227 100644
>> --- a/lisp/help-fns.el
>> +++ b/lisp/help-fns.el
>> @@ -632,7 +632,7 @@ help-fns--key-bindings
>>                               (format-message "`%s'" remapped)
>>  		           "an anonymous command"))
>>                    (princ "as well.\n"))
>> -                (or remapped (princ "."))
>> +                (or remapped (= (point) start) (princ "."))
>>                  (fill-region-as-paragraph start (point))))
>>              (ensure-empty-lines)))))))
>
> Yes, this is effectively equivalent to the patch I posted ;-)

Both variants seem to work over here :)


Thanks,

Eshel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: stephen.berman <at> gmx.net, 78905-done <at> debbugs.gnu.org
Subject: Re: bug#78905: 31.0.50; Extra dot in C-h k output
Date: Thu, 26 Jun 2025 17:40:23 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  78905 <at> debbugs.gnu.org
> Date: Thu, 26 Jun 2025 16:21:49 +0200
> 
> Hi,
> 
> Stephen Berman <stephen.berman <at> gmx.net> writes:
> 
> > On Thu, 26 Jun 2025 16:05:13 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> >>> From: Stephen Berman <stephen.berman <at> gmx.net>
> >>> Cc: Eshel Yaron <me <at> eshelyaron.com>,  78905 <at> debbugs.gnu.org
> >>> Date: Thu, 26 Jun 2025 14:47:32 +0200
> >>> 
> >>> Since the sexp `(or remapped menus (princ "."))' is within a sexp
> >>> beginning `(when menus ...)' and nothing nullifies `menus' within that
> >>> sexp, doesn't this change then make `(princ ".")' a no-op?
> >>
> >> Sorry, a thinko.  The below is better, I hope.
> >>
> >> diff --git a/lisp/help-fns.el b/lisp/help-fns.el
> >> index 481360b..ff69227 100644
> >> --- a/lisp/help-fns.el
> >> +++ b/lisp/help-fns.el
> >> @@ -632,7 +632,7 @@ help-fns--key-bindings
> >>                               (format-message "`%s'" remapped)
> >>  		           "an anonymous command"))
> >>                    (princ "as well.\n"))
> >> -                (or remapped (princ "."))
> >> +                (or remapped (= (point) start) (princ "."))
> >>                  (fill-region-as-paragraph start (point))))
> >>              (ensure-empty-lines)))))))
> >
> > Yes, this is effectively equivalent to the patch I posted ;-)
> 
> Both variants seem to work over here :)

Thanks, installed, and closing the bug.

Previous Next

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