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.

Full log


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




This bug report was last modified 2 years and 348 days ago.

Previous Next


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