GNU bug report logs - #41836
26.3; Could we stop `help-buffer' from ever signalling errors?

Previous Next

Package: emacs;

Reported by: Phil Sainty <psainty <at> orcon.net.nz>

Date: Sat, 13 Jun 2020 13:30:02 UTC

Severity: wishlist

Found in version 26.3

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#41836; Package emacs. (Sat, 13 Jun 2020 13:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Phil Sainty <psainty <at> orcon.net.nz>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 13 Jun 2020 13:30:02 GMT) Full text and rfc822 format available.

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; Could we stop `help-buffer' from ever signalling errors?
Date: Sun, 14 Jun 2020 01:29:01 +1200
At present (current master branch included), `help-buffer'
returns the following:

  (buffer-name
   (if (not help-xref-following)
       (get-buffer-create "*Help*")
     (unless (derived-mode-p 'help-mode)
       (error "Current buffer is not in Help mode"))
     (current-buffer)))


Is there any reason not to change it to this?

  (buffer-name
   (if (and help-xref-following (derived-mode-p 'help-mode))
       (current-buffer)
     (get-buffer-create "*Help*")))


That way, even in unexpected situations, we can still show the
user some help.

My motivation is from wondering whether it was simple to
display all of the function and variable symbols displayed by
`so-long-commentary' as help buttons.  I found that calling
`help-make-xrefs' does exactly that, but then trying to use any
of the buttons causes the "Current buffer is not in Help mode"
error.

With the suggested change I get the desirable behaviour of those
help buttons popping up a help window with the relevant help.
It seems to work beautifully for my use-case, and would surely
be equally useful in other similar situations.

Is there any good reason to maintain that error?


-Phil




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#41836; Package emacs. (Thu, 21 Jan 2021 16:06:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 41836 <at> debbugs.gnu.org
Subject: Re: bug#41836: 26.3; Could we stop `help-buffer' from ever
 signalling errors?
Date: Thu, 21 Jan 2021 17:04:53 +0100
Phil Sainty <psainty <at> orcon.net.nz> writes:

> My motivation is from wondering whether it was simple to
> display all of the function and variable symbols displayed by
> `so-long-commentary' as help buttons.  I found that calling
> `help-make-xrefs' does exactly that, but then trying to use any
> of the buttons causes the "Current buffer is not in Help mode"
> error.
>
> With the suggested change I get the desirable behaviour of those
> help buttons popping up a help window with the relevant help.
> It seems to work beautifully for my use-case, and would surely
> be equally useful in other similar situations.
>
> Is there any good reason to maintain that error?

Looking at the code, my impression is that `help-make-xrefs' is meant to
be used in `help-mode' buffers only, and the `error' call is just a
sanity check for that, kinda?  Lifting the restriction by removing that
`error' would allow other usages.  I'm not sure whether they're
all taken into account, though.

Anybody got an opinion here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#41836; Package emacs. (Mon, 06 Jun 2022 14:13:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 41836 <at> debbugs.gnu.org
Subject: Re: bug#41836: 26.3; Could we stop `help-buffer' from ever
 signalling errors?
Date: Mon, 06 Jun 2022 16:12:23 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Looking at the code, my impression is that `help-make-xrefs' is meant to
> be used in `help-mode' buffers only, and the `error' call is just a
> sanity check for that, kinda?  Lifting the restriction by removing that
> `error' would allow other usages.  I'm not sure whether they're
> all taken into account, though.
>
> Anybody got an opinion here?

The explanation for all this was in bug#8147, and Stephen Berman
proposed an alternate fix (which Stefan agreed with).  But it was never
applied, so I did that in Emacs 29, which also solves this bug report, I
think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 29.1, send any further explanations to 41836 <at> debbugs.gnu.org and Phil Sainty <psainty <at> orcon.net.nz> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 06 Jun 2022 14:13:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 05 Jul 2022 11:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 267 days ago.

Previous Next


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