From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss Date: Mon, 07 Mar 2011 00:41:10 +0100 Message-ID: <878vwryfzd.fsf@escher.fritz.box> References: <8762s2akxq.fsf@escher.fritz.box> <87oc5pff43.fsf@stupidchicken.com> <878vwtt7t0.fsf@escher.fritz.box> <87k4gcxkyp.fsf@escher.fritz.box> <87k4gct2mc.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1299463904 13391 80.91.229.12 (7 Mar 2011 02:11:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2011 02:11:44 +0000 (UTC) Cc: 8147@debbugs.gnu.org To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 07 03:11:40 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PwPv8-0005c7-KE for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Mar 2011 03:11:38 +0100 Original-Received: from localhost ([127.0.0.1]:60586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwPv8-0005Eo-2a for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Mar 2011 21:11:38 -0500 Original-Received: from [140.186.70.92] (port=33192 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwPNV-0006HN-P1 for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 20:36:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PwPNT-0002mk-VI for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 20:36:53 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PwPNT-0002mg-SO for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 20:36:51 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PwP5F-00014y-R5; Sun, 06 Mar 2011 20:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Mar 2011 01:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8147 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8147-submit@debbugs.gnu.org id=B8147.12994606224065 (code B ref 8147); Mon, 07 Mar 2011 01:18:01 +0000 Original-Received: (at 8147) by debbugs.gnu.org; 7 Mar 2011 01:17:02 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PwP4H-00013T-Ix for submit@debbugs.gnu.org; Sun, 06 Mar 2011 20:17:02 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1PwNZe-0007PO-IW for 8147@debbugs.gnu.org; Sun, 06 Mar 2011 18:41:20 -0500 Original-Received: (qmail invoked by alias); 06 Mar 2011 23:41:12 -0000 Original-Received: from i59F5B595.versanet.de (EHLO escher.home) [89.245.181.149] by mail.gmx.net (mp018) with SMTP; 07 Mar 2011 00:41:12 +0100 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX1+XE40mV0qXJxEdH0yUwNJ6CBaw3UwM5FMGAWRoCO U7TiYiuYAgzQIk Original-Received: by escher.home (Postfix, from userid 1000) id C619F63370; Mon, 7 Mar 2011 00:41:10 +0100 (CET) In-Reply-To: <87k4gct2mc.fsf@stupidchicken.com> (Chong Yidong's message of "Sun, 06 Mar 2011 15:28:43 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Sun, 06 Mar 2011 20:16:59 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 06 Mar 2011 20:18:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:44726 Archived-At: On Sun, 06 Mar 2011 15:28:43 -0500 Chong Yidong wrote: > Stephen Berman writes: > >> I just tested this with the doc string of help-buffer in *Help*. There >> are two links in this doc string: clicking on `help-xref-following' >> shows the error message "Current buffer is not in Help mode", which is >> certainly better than overwriting the content of the buffer; but >> clicking on `help-mode.el' finds that file and puts point on the >> beginning of help-buffer's definition, i.e., still does what this kind >> of link has always done. It is confusing to have this divergence in >> behavior between the two kinds of links. Instead of signalling an >> error, couldn't the help-xref-following buttons just show the help in >> the *Help* buffer, as in the following patch? > > The buffer from you pasted the button might not be *Help*; it could be > any other buffer in Help mode. So wouldn't it be inconsistent either > way? Do you mean that if the button inserted[1] into a buffer A comes from a help-mode buffer other than *Help* -- call it B --, you expect that clicking on the button in A would display the help in B rather than in *Help*? This is not my expectation; rather, I would expect the help to be displayed in *Help*, so there would be no inconsisency. Do you know of any cases where it is, or is clearly intended, to be displayed in B instead of *Help*? If there isn't any, then maybe help-buffer should simply always use *Help*, never current-buffer. I found some problematic cases in Emacs that seem to support this conclusion. One case is strokes-help in strokes.el: it uses a help-mode buffer called *Help with Strokes*, so this is buffer B above. When I click on a help link in that buffer, the help is displayed in the same buffer (using either the original help-buffer, the one with your patch, or the one with mine) -- but there is no back button, so the only way to see the strokes help again is to reinvoke strokes-help (which now overwrites the content of the previous help). If the links used *Help* instead of the current buffer, there would be now problem. Two other cases are describe-current-coding-system in mule-diag.el and r2b-help in refbib.el. Both of these use *Help*, but apparently do not add to help-xref-stack: if a standard help command is called, the back and forward buttons never return to the coding system or refbib help, so here, too, the only way to see the help again is to reinvoke the command. These commands should, it seems, either use help-xref-stack or not call their help buffer *Help*. Footnotes: [1] Not yanked, since the link property is excluded from yanked text. Given the complications, maybe it wouldn't be such a bad idea to exclude it also from insert-buffer, as in my first patch in this bug thread....