From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 01 11:02:28 2011 Received: (at submit) by debbugs.gnu.org; 1 Mar 2011 16:02:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PuS1s-0003w2-Fz for submit@debbugs.gnu.org; Tue, 01 Mar 2011 11:02:28 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PuS1p-0003vp-Lu for submit@debbugs.gnu.org; Tue, 01 Mar 2011 11:02:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PuS1h-0004iz-Ro for submit@debbugs.gnu.org; Tue, 01 Mar 2011 11:02:20 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:37637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PuS1h-0004ir-PL for submit@debbugs.gnu.org; Tue, 01 Mar 2011 11:02:17 -0500 Received: from [140.186.70.92] (port=35111 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuS1g-0001nO-I8 for bug-gnu-emacs@gnu.org; Tue, 01 Mar 2011 11:02:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PuS1f-0004hY-FR for bug-gnu-emacs@gnu.org; Tue, 01 Mar 2011 11:02:16 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:37908) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PuS1f-0004gn-4N for bug-gnu-emacs@gnu.org; Tue, 01 Mar 2011 11:02:15 -0500 Received: (qmail invoked by alias); 01 Mar 2011 16:02:11 -0000 Received: from i59F576BB.versanet.de (EHLO escher.home) [89.245.118.187] by mail.gmx.net (mp023) with SMTP; 01 Mar 2011 17:02:11 +0100 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX18d/9xTfrAd+y4+0lTTrW8sJi9NiWpbNr2EdbhC4g LOp1dAiNeGPpNp Received: by escher.home (Postfix, from userid 1000) id 2EA5A638E6; Tue, 1 Mar 2011 17:02:09 +0100 (CET) From: Stephen Berman To: bug-gnu-emacs@gnu.org Subject: 24.0.50; Inserting *Help* buffer can lead to data loss Date: Tue, 01 Mar 2011 17:02:09 +0100 Message-ID: <8762s2akxq.fsf@escher.fritz.box> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 199.232.76.165 X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.6 (----) --=-=-= Content-Type: text/plain In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2011-02-23 on escher Windowing system distributor `The X.Org Foundation', version 11.0.10800000 configured using `configure '--without-toolkit-scroll-bars' 'CFLAGS=-g -O2 -fno-optimize-sibling-calls'' 1. emacs -Q 2. Start editing some buffer. 3. Bring up a doc string in a *Help* buffer with content that contains buttons to other doc strings, e.g. `C-h f completing-read'. 4. Return to the buffer in step 2 and type `M-x insert-buffer RET *Help*'. Note that the buttons in the inserted text are active. 5. Click on one of the buttons in the inserted text that links to another doc string, e.g. `try-completion'. => The previous content of the buffer you were editing is replaced by the doc string of the just clicked button (e.g. that of `try-completion'). This buffer is read-only, but if you make it writable and type `C-x _' to restore the previous content, you get the message "No undo information in this buffer". So whatever unsaved data was in the buffer prior to clicking the button is unrecoverable. I reported this problem to emacs-devel in May 2008 (see http://thread.gmane.org/gmane.emacs.devel/97367/) and there were a few ideas about how to deal with it, but none were pursued. I just got bit by it again -- more fool me, perhaps, but it gives me the opportunity to put it in the bug tracker. And I offer a fix to the immediate problem in the following patch, which prevents insert-buffer from inserting active help buttons. This extends to insert-buffer the default behavior of yanking the content of *Help*, since the help button text properties are in yank-excluded-properties by default. --=-=-= Content-Type: text/x-emacs-lisp Content-Disposition: inline Content-Description: insert-buffer patch *** /data/steve/bzr/emacs/trunk/lisp/simple.el 2011-02-23 15:11:01.000000000 +0100 --- /data/steve/bzr/emacs/quickfixes/lisp/simple.el 2011-03-01 15:04:22.000000000 +0100 *************** *** 3626,3631 **** --- 3626,3632 ---- (save-excursion (insert-buffer-substring (get-buffer buffer)) (point))) + (remove-yank-excluded-properties (point) (mark)) nil) (defun append-to-buffer (buffer start end) --=-=-= Content-Type: text/plain Steve Berman --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 02 12:07:44 2011 Received: (at 8147) by debbugs.gnu.org; 2 Mar 2011 17:07:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PupWZ-00051S-Ss for submit@debbugs.gnu.org; Wed, 02 Mar 2011 12:07:44 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PupWY-00051H-GM for 8147@debbugs.gnu.org; Wed, 02 Mar 2011 12:07:43 -0500 Received: from [207.96.179.97] (port=36434 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1PupWT-0001UB-7E; Wed, 02 Mar 2011 12:07:37 -0500 Received: by ceviche.home (Postfix, from userid 20848) id 2D63C660D6; Wed, 2 Mar 2011 12:07:36 -0500 (EST) From: Stefan Monnier To: Stephen Berman Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss Message-ID: References: <8762s2akxq.fsf@escher.fritz.box> Date: Wed, 02 Mar 2011 12:07:36 -0500 In-Reply-To: <8762s2akxq.fsf@escher.fritz.box> (Stephen Berman's message of "Tue, 01 Mar 2011 17:02:09 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 8147 Cc: 8147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) > I reported this problem to emacs-devel in May 2008 (see > http://thread.gmane.org/gmane.emacs.devel/97367/) and there were a few > ideas about how to deal with it, but none were pursued. I just got bit > by it again -- more fool me, perhaps, but it gives me the opportunity to > put it in the bug tracker. And I offer a fix to the immediate problem Maybe another approach is for those buttons to check that the current buffer is (derived-mode-p 'help-mode) before reusing it. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 03 12:57:11 2011 Received: (at 8147) by debbugs.gnu.org; 3 Mar 2011 17:57:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PvClz-0007ns-Mt for submit@debbugs.gnu.org; Thu, 03 Mar 2011 12:57:11 -0500 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PvClx-0007nZ-HK; Thu, 03 Mar 2011 12:57:10 -0500 Received: by wwc33 with SMTP id 33so1665716wwc.15 for ; Thu, 03 Mar 2011 09:57:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.182.212 with SMTP id o62mr903116wem.52.1299175023456; Thu, 03 Mar 2011 09:57:03 -0800 (PST) Received: by 10.216.26.4 with HTTP; Thu, 3 Mar 2011 09:57:03 -0800 (PST) Date: Thu, 3 Mar 2011 12:57:03 -0500 X-Google-Sender-Auth: wDq8_sPVBDwOdk46GeKwm9HqlEs Message-ID: Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss From: MON KEY To: 8147@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 8147 Cc: 6462@debbugs.gnu.org, Stephen Berman , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.7 (---) ,---- | 5. Click on one of the buttons in the inserted text that links to | another doc string, e.g. `try-completion'. `---- Unmentioned, but probably relevant is that clicking on these buttons will likely corrupt the `help-xref-stack' as well... See for example bug #6462 `disabled-command-function' corrupts the `help-xref-stack' http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6462 -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 17:02:25 2011 Received: (at 8147) by debbugs.gnu.org; 5 Mar 2011 22:02:26 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PvzYP-00088y-Ih for submit@debbugs.gnu.org; Sat, 05 Mar 2011 17:02:25 -0500 Received: from vm-emlprdomr-05.its.yale.edu ([130.132.50.146]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PvzYG-00087H-2m for 8147@debbugs.gnu.org; Sat, 05 Mar 2011 17:02:17 -0500 Received: from furball (c-71-192-165-84.hsd1.ct.comcast.net [71.192.165.84]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id p25M2ABx013609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Mar 2011 17:02:10 -0500 Received: by furball (Postfix, from userid 1000) id 0DED91607A5; Sat, 5 Mar 2011 16:10:20 -0500 (EST) From: Chong Yidong To: Stefan Monnier Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss References: <8762s2akxq.fsf@escher.fritz.box> Date: Sat, 05 Mar 2011 16:10:20 -0500 In-Reply-To: (Stefan Monnier's message of "Wed, 02 Mar 2011 12:07:36 -0500") Message-ID: <87oc5pff43.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 8147 Cc: Stephen Berman , 8147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Stefan Monnier writes: >> I reported this problem to emacs-devel in May 2008 (see >> http://thread.gmane.org/gmane.emacs.devel/97367/) and there were a few >> ideas about how to deal with it, but none were pursued. I just got bit >> by it again -- more fool me, perhaps, but it gives me the opportunity to >> put it in the bug tracker. And I offer a fix to the immediate problem > > Maybe another approach is for those buttons to check that the current > buffer is (derived-mode-p 'help-mode) before reusing it. I've committed just such a change. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 17:02:26 2011 Received: (at control) by debbugs.gnu.org; 5 Mar 2011 22:02:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PvzYO-00088t-QR for submit@debbugs.gnu.org; Sat, 05 Mar 2011 17:02:25 -0500 Received: from vm-emlprdomr-03.its.yale.edu ([130.132.50.144]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PvzYG-00087E-0l for control@debbugs.gnu.org; Sat, 05 Mar 2011 17:02:16 -0500 Received: from furball (c-71-192-165-84.hsd1.ct.comcast.net [71.192.165.84]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id p25M2Aao017913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 5 Mar 2011 17:02:10 -0500 Received: by furball (Postfix, from userid 1000) id 0103C1607BA; Sat, 5 Mar 2011 16:10:32 -0500 (EST) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 8147 Date: Sat, 05 Mar 2011 16:10:32 -0500 Message-ID: <871v2lff3r.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) close 8147 thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 19:24:40 2011 Received: (at 8147) by debbugs.gnu.org; 6 Mar 2011 00:24:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Pw1m3-0004SV-VH for submit@debbugs.gnu.org; Sat, 05 Mar 2011 19:24:40 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Pw1m0-0004SG-LL for 8147@debbugs.gnu.org; Sat, 05 Mar 2011 19:24:38 -0500 Received: (qmail invoked by alias); 06 Mar 2011 00:24:29 -0000 Received: from i59F55DC0.versanet.de (EHLO escher.home) [89.245.93.192] by mail.gmx.net (mp016) with SMTP; 06 Mar 2011 01:24:29 +0100 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX1/a7tArAAPa3pdt7UXG+awZBdKYREQYJ3/vReVhJ3 DJ30ChFlVveiae Received: by escher.home (Postfix, from userid 1000) id EEDC16336E; Sun, 6 Mar 2011 01:24:27 +0100 (CET) From: Stephen Berman To: Chong Yidong Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss References: <8762s2akxq.fsf@escher.fritz.box> <87oc5pff43.fsf@stupidchicken.com> Date: Sun, 06 Mar 2011 01:24:27 +0100 In-Reply-To: <87oc5pff43.fsf@stupidchicken.com> (Chong Yidong's message of "Sat, 05 Mar 2011 16:10:20 -0500") Message-ID: <878vwtt7t0.fsf@escher.fritz.box> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 8147 Cc: 8147@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Sat, 05 Mar 2011 16:10:20 -0500 Chong Yidong wrote: > Stefan Monnier writes: > >>> I reported this problem to emacs-devel in May 2008 (see >>> http://thread.gmane.org/gmane.emacs.devel/97367/) and there were a few >>> ideas about how to deal with it, but none were pursued. I just got bit >>> by it again -- more fool me, perhaps, but it gives me the opportunity to >>> put it in the bug tracker. And I offer a fix to the immediate problem >> >> Maybe another approach is for those buttons to check that the current >> buffer is (derived-mode-p 'help-mode) before reusing it. > > I've committed just such a change. 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? *** /data/steve/bzr/emacs/trunk/lisp/help-mode.el 2011-02-23 15:11:01.000000000 +0100 --- /data/steve/bzr/emacs/quickfixes/lisp/help-mode.el 2011-03-06 01:13:36.000000000 +0100 *************** *** 408,419 **** ;;;###autoload (defun help-buffer () "Return the name of a buffer for inserting help. ! If `help-xref-following' is non-nil, this is the name of the ! current buffer. ! Otherwise, it is *Help*; if no buffer with that name currently ! exists, it is created." (buffer-name ;for with-output-to-temp-buffer ! (if help-xref-following (current-buffer) (get-buffer-create "*Help*")))) --- 408,420 ---- ;;;###autoload (defun help-buffer () "Return the name of a buffer for inserting help. ! If `help-xref-following' is non-nil and the current buffer is ! derived from `help-mode', this is the name of the current buffer. ! Otherwise, return \"*Help*\", creating a buffer with that name if ! it does not already exist." (buffer-name ;for with-output-to-temp-buffer ! (if (and help-xref-following ! (derived-mode-p 'help-mode)) (current-buffer) (get-buffer-create "*Help*")))) Steve Berman From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 06 11:39:06 2011 Received: (at 8147) by debbugs.gnu.org; 6 Mar 2011 16:39:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PwGz3-0005TI-R8 for submit@debbugs.gnu.org; Sun, 06 Mar 2011 11:39:06 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1PwGz0-0005Sn-I8 for 8147@debbugs.gnu.org; Sun, 06 Mar 2011 11:39:04 -0500 Received: (qmail invoked by alias); 06 Mar 2011 16:38:56 -0000 Received: from i59F5B595.versanet.de (EHLO escher.home) [89.245.181.149] by mail.gmx.net (mp071) with SMTP; 06 Mar 2011 17:38:56 +0100 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX1+Lj2oE/zCLi8ndoM8XfGskhofMN9xhYhKbSAl4Ia D0EHBbNZlRc+rQ Received: by escher.home (Postfix, from userid 1000) id 42BB4638FA; Sun, 6 Mar 2011 17:38:54 +0100 (CET) From: Stephen Berman To: Chong Yidong Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss References: <8762s2akxq.fsf@escher.fritz.box> <87oc5pff43.fsf@stupidchicken.com> <878vwtt7t0.fsf@escher.fritz.box> Date: Sun, 06 Mar 2011 17:38:54 +0100 In-Reply-To: <878vwtt7t0.fsf@escher.fritz.box> (Stephen Berman's message of "Sun, 06 Mar 2011 01:24:27 +0100") Message-ID: <87k4gcxkyp.fsf@escher.fritz.box> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 8147 Cc: 8147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Sun, 06 Mar 2011 01:24:27 +0100 Stephen Berman wrote: > On Sat, 05 Mar 2011 16:10:20 -0500 Chong Yidong wrote: > >> Stefan Monnier writes: >> >>>> I reported this problem to emacs-devel in May 2008 (see >>>> http://thread.gmane.org/gmane.emacs.devel/97367/) and there were a few >>>> ideas about how to deal with it, but none were pursued. I just got bit >>>> by it again -- more fool me, perhaps, but it gives me the opportunity to >>>> put it in the bug tracker. And I offer a fix to the immediate problem >>> >>> Maybe another approach is for those buttons to check that the current >>> buffer is (derived-mode-p 'help-mode) before reusing it. >> >> I've committed just such a change. > > 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? Sorry, that should have been a patch against the version with your patch: *** /data/steve/bzr/emacs/trunk/lisp/help-mode.el 2011-03-06 17:31:58.000000000 +0100 --- /data/steve/bzr/emacs/quickfixes/lisp/help-mode.el 2011-03-06 01:13:36.000000000 +0100 *************** *** 408,424 **** ;;;###autoload (defun help-buffer () "Return the name of a buffer for inserting help. ! If `help-xref-following' is non-nil, this is the name of the ! current buffer. Signal an error if this buffer is not derived ! from `help-mode'. Otherwise, return \"*Help*\", creating a buffer with that name if it does not already exist." (buffer-name ;for with-output-to-temp-buffer ! (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)))) (defvar help-xref-override-view-map (let ((map (make-sparse-keymap))) --- 408,422 ---- ;;;###autoload (defun help-buffer () "Return the name of a buffer for inserting help. ! If `help-xref-following' is non-nil and the current buffer is ! derived from `help-mode', this is the name of the current buffer. Otherwise, return \"*Help*\", creating a buffer with that name if it does not already exist." (buffer-name ;for with-output-to-temp-buffer ! (if (and help-xref-following ! (derived-mode-p 'help-mode)) ! (current-buffer) ! (get-buffer-create "*Help*")))) (defvar help-xref-override-view-map (let ((map (make-sparse-keymap))) Steve Berman From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 06 15:28:59 2011 Received: (at 8147) by debbugs.gnu.org; 6 Mar 2011 20:28:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PwKZX-00031x-9g for submit@debbugs.gnu.org; Sun, 06 Mar 2011 15:28:59 -0500 Received: from vm-emlprdomr-05.its.yale.edu ([130.132.50.146]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PwKZU-00031l-VS for 8147@debbugs.gnu.org; Sun, 06 Mar 2011 15:28:57 -0500 Received: from furball ([64.134.240.221]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id p26KSjcl028254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Mar 2011 15:28:50 -0500 Received: by furball (Postfix, from userid 1000) id DC3A21604E8; Sun, 6 Mar 2011 15:28:43 -0500 (EST) From: Chong Yidong To: Stephen Berman Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss References: <8762s2akxq.fsf@escher.fritz.box> <87oc5pff43.fsf@stupidchicken.com> <878vwtt7t0.fsf@escher.fritz.box> <87k4gcxkyp.fsf@escher.fritz.box> Date: Sun, 06 Mar 2011 15:28:43 -0500 In-Reply-To: <87k4gcxkyp.fsf@escher.fritz.box> (Stephen Berman's message of "Sun, 06 Mar 2011 17:38:54 +0100") Message-ID: <87k4gct2mc.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 8147 Cc: 8147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 06 18:58:18 2011 Received: (at 8147) by debbugs.gnu.org; 6 Mar 2011 23:58:18 +0000 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 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 Received: (qmail invoked by alias); 06 Mar 2011 23:58:08 -0000 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 Received: by escher.home (Postfix, from userid 1000) id 0B20E63370; Mon, 7 Mar 2011 00:58:07 +0100 (CET) From: Stephen Berman To: Chong Yidong Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss 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> Date: Mon, 07 Mar 2011 00:58:07 +0100 In-Reply-To: <878vwryfzd.fsf@escher.fritz.box> (Stephen Berman's message of "Mon, 07 Mar 2011 00:41:10 +0100") Message-ID: <871v2jyf74.fsf@escher.fritz.box> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 8147 Cc: 8147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) 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.... From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 06 20:17:02 2011 Received: (at 8147) by debbugs.gnu.org; 7 Mar 2011 01:17:02 +0000 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 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 Received: (qmail invoked by alias); 06 Mar 2011 23:41:12 -0000 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 Received: by escher.home (Postfix, from userid 1000) id C619F63370; Mon, 7 Mar 2011 00:41:10 +0100 (CET) From: Stephen Berman To: Chong Yidong Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss References: <8762s2akxq.fsf@escher.fritz.box> <87oc5pff43.fsf@stupidchicken.com> <878vwtt7t0.fsf@escher.fritz.box> <87k4gcxkyp.fsf@escher.fritz.box> <87k4gct2mc.fsf@stupidchicken.com> Date: Mon, 07 Mar 2011 00:41:10 +0100 In-Reply-To: <87k4gct2mc.fsf@stupidchicken.com> (Chong Yidong's message of "Sun, 06 Mar 2011 15:28:43 -0500") Message-ID: <878vwryfzd.fsf@escher.fritz.box> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 8147 X-Mailman-Approved-At: Sun, 06 Mar 2011 20:16:59 -0500 Cc: 8147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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.... From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 07 11:20:22 2011 Received: (at 8147) by debbugs.gnu.org; 7 Mar 2011 16:20:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PwdAS-00084f-JO for submit@debbugs.gnu.org; Mon, 07 Mar 2011 11:20:21 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PwdAR-00084P-20 for 8147@debbugs.gnu.org; Mon, 07 Mar 2011 11:20:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALuUdE3O+LEt/2dsb2JhbACmU3W+O4ViBIUcj3E X-IronPort-AV: E=Sophos;i="4.62,277,1297054800"; d="scan'208";a="94870566" Received: from 206-248-177-45.dsl.teksavvy.com (HELO ceviche.home) ([206.248.177.45]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 07 Mar 2011 11:20:13 -0500 Received: by ceviche.home (Postfix, from userid 20848) id D0EDD660C9; Mon, 7 Mar 2011 11:20:12 -0500 (EST) From: Stefan Monnier To: Chong Yidong Subject: Re: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss Message-ID: References: <8762s2akxq.fsf@escher.fritz.box> <87oc5pff43.fsf@stupidchicken.com> <878vwtt7t0.fsf@escher.fritz.box> <87k4gcxkyp.fsf@escher.fritz.box> <87k4gct2mc.fsf@stupidchicken.com> Date: Mon, 07 Mar 2011 11:20:12 -0500 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) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 8147 Cc: Stephen Berman , 8147@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > 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? I don't think that's a problem. His patch looks good to me. The main issue is to avoid replacing the buffer's content when that content is not prepared for such replacement, and help-mode buffers are supposed to be prepared for it (e.g. proving the help-xref-stack to "undo"). Stefan From unknown Sat Aug 16 11:41:29 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 05 Apr 2011 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator