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:58:07 +0100 Message-ID: <871v2jyf74.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> <878vwryfzd.fsf@escher.fritz.box> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1299456425 15917 80.91.229.12 (7 Mar 2011 00:07:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2011 00:07:05 +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 01:07:00 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 1PwNyW-0004dG-GJ for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Mar 2011 01:07:00 +0100 Original-Received: from localhost ([127.0.0.1]:56161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwNyV-0007yH-LM for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Mar 2011 19:06:59 -0500 Original-Received: from [140.186.70.92] (port=55041 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwNyP-0007w9-8n for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 19:06:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PwNyO-0004mQ-0m for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 19:06:53 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PwNyN-0004mJ-VT for bug-gnu-emacs@gnu.org; Sun, 06 Mar 2011 19:06:51 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PwNqo-0007nl-FS; Sun, 06 Mar 2011 18:59:02 -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: Sun, 06 Mar 2011 23:59:02 +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.129945589829936 (code B ref 8147); Sun, 06 Mar 2011 23:59:02 +0000 Original-Received: (at 8147) by debbugs.gnu.org; 6 Mar 2011 23:58:18 +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 1PwNq6-0007mn-1G for submit@debbugs.gnu.org; Sun, 06 Mar 2011 18:58:18 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1PwNq3-0007mb-QI for 8147@debbugs.gnu.org; Sun, 06 Mar 2011 18:58:17 -0500 Original-Received: (qmail invoked by alias); 06 Mar 2011 23:58:08 -0000 Original-Received: from i59F5B595.versanet.de (EHLO escher.home) [89.245.181.149] by mail.gmx.net (mp017) with SMTP; 07 Mar 2011 00:58:08 +0100 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX1+cZvJWrzicGlzu2ukoMGSOewZIp/fz/NR9CMZw3r BRTvyG/nq0Xc0C Original-Received: by escher.home (Postfix, from userid 1000) id 0B20E63370; Mon, 7 Mar 2011 00:58:07 +0100 (CET) In-Reply-To: <878vwryfzd.fsf@escher.fritz.box> (Stephen Berman's message of "Mon, 07 Mar 2011 00:41:10 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 06 Mar 2011 18:59:02 -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:44723 Archived-At: Sorry, I mistakenly sent my followup from a different email address. Steve Berman On Mon, 07 Mar 2011 00:41:10 +0100 Stephen Berman wrote: > 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....