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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: wishlist; Reported by: Phil Sainty <psainty@HIDDEN>; dated Sat, 13 Jun 2020 13:30:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 41836 <at> debbugs.gnu.org:


Received: (at 41836) by debbugs.gnu.org; 21 Jan 2021 16:05:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 21 11:05:07 2021
Received: from localhost ([127.0.0.1]:59133 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l2cSJ-0004x1-FR
	for submit <at> debbugs.gnu.org; Thu, 21 Jan 2021 11:05:07 -0500
Received: from quimby.gnus.org ([95.216.78.240]:58998)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1l2cSH-0004wL-FZ
 for 41836 <at> debbugs.gnu.org; Thu, 21 Jan 2021 11:05:05 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=a6//u1peSP0ROHfQbyV+w43mYj//kdJr6VTkyQpb4eE=; b=eiThLIUlX+yjdqn7MFLS2jQht6
 rg48KE9PPjYPoI3sNEw2G3Ir3ftF59Acvfqx524qKAFDY411hcSdyerkGF7KUpNrUrsM/V0shZM0A
 dud2zOGDXT+jfpPdz6XcJmdSDFYbEEgJymuIVmsMO0+fUgQ/wLFIjb7LSQuHCQwDJw+0=;
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1l2cS7-0006gk-VG; Thu, 21 Jan 2021 17:04:58 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Phil Sainty <psainty@HIDDEN>
Subject: Re: bug#41836: 26.3; Could we stop `help-buffer' from ever
 signalling errors?
References: <871rmj9js2.fsf@HIDDEN>
X-Now-Playing: Richard Bone's _Third Noise Principle (Formative North
 American Electronica 1975-1984) (1)_: "Mambopolis"
Date: Thu, 21 Jan 2021 17:04:53 +0100
In-Reply-To: <871rmj9js2.fsf@HIDDEN> (Phil Sainty's message of "Sun, 14
 Jun 2020 01:29:01 +1200")
Message-ID: <87im7q8ee2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Phil Sainty <psainty@HIDDEN> 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-xre [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41836
Cc: 41836 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Phil Sainty <psainty@HIDDEN> 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@HIDDEN:
bug#41836; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 13 Jun 2020 13:29:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 13 09:29:20 2020
Received: from localhost ([127.0.0.1]:41077 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jk6Do-0000xg-Im
	for submit <at> debbugs.gnu.org; Sat, 13 Jun 2020 09:29:20 -0400
Received: from lists.gnu.org ([209.51.188.17]:55184)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <psainty@HIDDEN>) id 1jk6Dl-0000xX-Ur
 for submit <at> debbugs.gnu.org; Sat, 13 Jun 2020 09:29:18 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:55924)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <psainty@HIDDEN>)
 id 1jk6Dl-00029x-Ou
 for bug-gnu-emacs@HIDDEN; Sat, 13 Jun 2020 09:29:17 -0400
Received: from smtp-1.orcon.net.nz ([60.234.4.34]:41427)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <psainty@HIDDEN>)
 id 1jk6Dk-0008DS-1P
 for bug-gnu-emacs@HIDDEN; Sat, 13 Jun 2020 09:29:17 -0400
Received: from [101.53.216.184] (port=53304 helo=shodan)
 by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1)
 (envelope-from <psainty@HIDDEN>) id 1jk6Dc-0007uH-FV
 for bug-gnu-emacs@HIDDEN; Sun, 14 Jun 2020 01:29:08 +1200
User-agent: mu4e 1.4.9; emacs 26.3
From: Phil Sainty <psainty@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 26.3; Could we stop `help-buffer' from ever signalling errors?
Date: Sun, 14 Jun 2020 01:29:01 +1200
Message-ID: <871rmj9js2.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-GeoIP: NZ
Received-SPF: pass client-ip=60.234.4.34; envelope-from=psainty@HIDDEN;
 helo=smtp-1.orcon.net.nz
X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/13 09:29:09
X-ACL-Warn: Detected OS   = Linux 3.11 and newer
X-Spam_score_int: -25
X-Spam_score: -2.6
X-Spam_bar: --
X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=_AUTOLEARN
X-Spam_action: no action
X-Spam-Score: 0.4 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)

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




Acknowledgement sent to Phil Sainty <psainty@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#41836; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Thu, 21 Jan 2021 16:15:01 UTC

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