From unknown Fri Aug 15 03:56:16 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#17397 <17397@debbugs.gnu.org> To: bug#17397 <17397@debbugs.gnu.org> Subject: Status: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' Reply-To: bug#17397 <17397@debbugs.gnu.org> Date: Fri, 15 Aug 2025 10:56:16 +0000 retitle 17397 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer inv= oked for `describe-variable' reassign 17397 emacs submitter 17397 Drew Adams severity 17397 normal tag 17397 wontfix notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 17:33:31 2014 Received: (at submit) by debbugs.gnu.org; 3 May 2014 21:33:31 +0000 Received: from localhost ([127.0.0.1]:50023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WghYo-0005f0-No for submit@debbugs.gnu.org; Sat, 03 May 2014 17:33:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44252) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WghYl-0005ei-7w for submit@debbugs.gnu.org; Sat, 03 May 2014 17:33:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WghYV-0003Qq-PC for submit@debbugs.gnu.org; Sat, 03 May 2014 17:33:21 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:59544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WghYV-0003Qm-Lx for submit@debbugs.gnu.org; Sat, 03 May 2014 17:33:11 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WghYM-0003Ai-U4 for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 17:33:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WghYE-0003Nl-7y for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 17:33:02 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:29540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WghYD-0003Ng-Vu for bug-gnu-emacs@gnu.org; Sat, 03 May 2014 17:32:54 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s43LWq2N027536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 3 May 2014 21:32:53 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s43LWpPW015575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 3 May 2014 21:32:51 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s43LWoLh023708 for ; Sat, 3 May 2014 21:32:51 GMT MIME-Version: 1.0 Message-ID: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> Date: Sat, 3 May 2014 14:32:51 -0700 (PDT) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) emacs -Q M-: (add-hook 'temp-buffer-show-hook (lambda () (debug)) 'append) C-h v auto-mode-interpreter-regexp The hook is never invoked. It is invoked in all previous Emacs releases. Do the same thing in Emacs 24.3, for example, and you enter the debugger. This has an effect on my code and setup, where I have `fit-frame-if-one-window' on the hook: buffer *Help*, alone in its frame, must always be refit to the latest *Help* text. This is now broken. In GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-04-29 on ODIEONE Bzr revision: 117031 monnier@iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut= 08 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=3D/c/Devel/emacs/snapshot/trunk --enable-checking=3Dyes,glyphs 'CFLAGS=3D-O0 -g3' LDFLAGS=3D-Lc:/Devel/emacs/lib 'CPPFLAGS=3D-DGC_MCHECK=3D1 -Ic:/Devel/emacs/include'' From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 17:41:16 2014 Received: (at 17397) by debbugs.gnu.org; 3 May 2014 21:41:16 +0000 Received: from localhost ([127.0.0.1]:50038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WghgJ-0005sl-W9 for submit@debbugs.gnu.org; Sat, 03 May 2014 17:41:16 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:46248) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WghgI-0005sV-6J for 17397@debbugs.gnu.org; Sat, 03 May 2014 17:41:15 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s43Lf8rg031733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <17397@debbugs.gnu.org>; Sat, 3 May 2014 21:41:08 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s43Lf7AK021479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <17397@debbugs.gnu.org>; Sat, 3 May 2014 21:41:07 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s43Lf6xi029015 for <17397@debbugs.gnu.org>; Sat, 3 May 2014 21:41:06 GMT MIME-Version: 1.0 Message-ID: <19a2e3b1-10a4-41f8-81ca-33a2d428dd13@default> Date: Sat, 3 May 2014 14:41:06 -0700 (PDT) From: Drew Adams To: 17397@debbugs.gnu.org Subject: RE: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> In-Reply-To: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Needless to say, this bug is present also in the 24.4 pretest. (I am using this development version at Stefan's request, to try to catch the crash of bug #17340 with his patch.) From debbugs-submit-bounces@debbugs.gnu.org Tue May 13 17:24:55 2014 Received: (at 17397) by debbugs.gnu.org; 13 May 2014 21:24:55 +0000 Received: from localhost ([127.0.0.1]:34428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkKBy-0002xl-Em for submit@debbugs.gnu.org; Tue, 13 May 2014 17:24:54 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:32564) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkKBv-0002xV-Np for 17397@debbugs.gnu.org; Tue, 13 May 2014 17:24:52 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4DLOii4022482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <17397@debbugs.gnu.org>; Tue, 13 May 2014 21:24:45 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s4DLOhnl003649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <17397@debbugs.gnu.org>; Tue, 13 May 2014 21:24:44 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4DLOh4I016270 for <17397@debbugs.gnu.org>; Tue, 13 May 2014 21:24:43 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 13 May 2014 14:24:43 -0700 (PDT) From: Drew Adams To: 17397@debbugs.gnu.org Subject: RE: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> In-Reply-To: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) I would really like to get some help with this. So far, no response at all. Help functions using buffer *Help* previously used `with-output-to-temp-buffer', which runs `temp-buffer-setup-hook' and `temp-buffer-show-hook'. And previously the setup hook usually put the buffer in help mode. Now, *Help* is set up by `with-help-window', and neither of those hooks is run by it. This is a regression, to me - any code or any user who relies on those hooks being run for *Help* buffers is up the creek without a paddle, AFAICS. So be it. But what is that code or that user supposed to do now? `with-help-window' invokes `with-temp-buffer-window', which runs `temp-buffer-window-setup-hook' and `temp-buffer-window-show-hook'. To get *Help* to DTRT for the code or user that previously used `temp-buffer-setup-hook' or `temp-buffer-show-hook, is it appropriate to put the same things on `temp-buffer-window-setup-hook' and `temp-buffer-window-show-hook' instead? Or will that maybe have unwanted effects because `with-temp-buffer-window' is perhaps used for more than just *Help*? Not clear to me. And I find no help in the doc or NEWS - or in this bug thread, so far. Should I be adding `fit-frame-if-one-window' to `temp-buffer-window' for Emacs 24.4, to get the effect it has in Emacs 24.3 (and prior) by being on `temp-buffer-show-hook'? If not, how to get the same effect? If yes, how to deal with other possible uses of `with-temp-buffer-window', which have nothing to do with *Help*? (In the case of `fit-frame-if-one-window', that would probably not hurt anything, but the question is more general.) -- The existing doc is anyway wrong in some cases, AFAICT: The doc string of `with-temp-buffer-window' says: This construct is similar to `with-output-to-temp-buffer' but, neither runs `temp-buffer-setup-hook' which usually puts the buffer in Help mode, nor `temp-buffer-show-function' (the ACTION argument replaces this). And the doc string of `temp-buffer-setup-hook', likewise, says: This hook is normally set up with a function to put the buffer in Help mode. I don't get the impression that either of those statements is true anymore. It seems like there is *no relation* anymore between such temp-buffer things and Help mode. Furthermore, grepping for `temp-buffer-setup-hook' in the Emacs sources shows that it is not used for this at all anymore. A little help, please. From debbugs-submit-bounces@debbugs.gnu.org Wed May 14 03:07:11 2014 Received: (at 17397) by debbugs.gnu.org; 14 May 2014 07:07:11 +0000 Received: from localhost ([127.0.0.1]:34622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkTHS-0004wr-Tb for submit@debbugs.gnu.org; Wed, 14 May 2014 03:07:11 -0400 Received: from mout.gmx.net ([212.227.17.20]:56788) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkTHP-0004wL-0L for 17397@debbugs.gnu.org; Wed, 14 May 2014 03:07:08 -0400 Received: from [194.96.34.248] ([194.96.34.248]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M3u86-1X1j0w2sfC-00rVYG; Wed, 14 May 2014 09:07:00 +0200 Message-ID: <5373160A.3070604@gmx.at> Date: Wed, 14 May 2014 09:06:50 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 17397@debbugs.gnu.org Subject: Re: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Bz3TuIcBHz3wn6shbA2toUUEsePd2GL88yKYKJyv2CPAshZuke2 BbH9CSiN2Uy63B3LXulGtIyfmoOniIomBEtD3cBAewQm78huTPywqDq12SPGOLmHk8z6nGG NzQjJTtLBMARguzgFTogMy90CiFf9NVuFL0bXFVhb/huXiM3RyQIGoPEGxckGuQVodomNrZ qiJo8BZFqtN3wmkvrVm1g== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > To get *Help* to DTRT for the code or user that previously used > `temp-buffer-setup-hook' or `temp-buffer-show-hook, is it > appropriate to put the same things on `temp-buffer-window-setup-hook' > and `temp-buffer-window-show-hook' instead? Or will that maybe > have unwanted effects because `with-temp-buffer-window' is perhaps > used for more than just *Help*? Both `with-output-to-temp-buffer' and `with-temp-buffer-window' are and can be used for other things than displaying *Help*. > Not clear to me. And I find no help in the doc or NEWS - or in > this bug thread, so far. The manual says about `with-temp-buffer-window' that This macro uses the normal hooks `temp-buffer-window-setup-hook' and `temp-buffer-window-show-hook' in place of the analogous hooks run by `with-output-to-temp-buffer'. What else do you need? > Should I be adding `fit-frame-if-one-window' to `temp-buffer-window' > for Emacs 24.4, to get the effect it has in Emacs 24.3 (and prior) > by being on `temp-buffer-show-hook'? I suppose you want to add it to `temp-buffer-window-show-hook'. > If not, how to get the same effect? If yes, how to deal with other > possible uses of `with-temp-buffer-window', which have nothing to do > with *Help*? (In the case of `fit-frame-if-one-window', that would > probably not hurt anything, but the question is more general.) Emacs has a `temp-buffer-resize-mode' which is tied to temporary buffers and not to `help-mode'. To "deal with other possible uses" of temporary buffers, a function run by `temp-buffer-show-hook' or `temp-buffer-window-show-hook' should probably check whether the buffer is in help mode. In this regard nothing has changed wrt earlier version where a user removed `help-mode-setup' from `temp-buffer-setup-hook' and `help-mode-finish' from `temp-buffer-show-hook'. Maybe you could also use `help-mode-hook' to do something for help buffers exclusively and avoid other temporary buffers. > The existing doc is anyway wrong in some cases, AFAICT: The doc > string of `with-temp-buffer-window' says: > > This construct is similar to `with-output-to-temp-buffer' > but, neither runs `temp-buffer-setup-hook' which usually puts > the buffer in Help mode, nor `temp-buffer-show-function' (the > ACTION argument replaces this). What is wrong here? > And the doc string of `temp-buffer-setup-hook', likewise, says: > > This hook is normally set up with a function to put the buffer > in Help mode. This is still the case for the release version. IIRC Leo Liu changed it on the trunk so the doc-string should be probably updated there. > I don't get the impression that either of those statements is > true anymore. It seems like there is *no relation* anymore > between such temp-buffer things and Help mode. Furthermore, > grepping for `temp-buffer-setup-hook' in the Emacs sources > shows that it is not used for this at all anymore. The connection between temporary buffers and help mode is established by `with-help-window' which uses `with-temp-buffer-window'. martin From debbugs-submit-bounces@debbugs.gnu.org Wed May 14 12:25:55 2014 Received: (at 17397) by debbugs.gnu.org; 14 May 2014 16:25:55 +0000 Received: from localhost ([127.0.0.1]:35388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkc0A-0006Zb-4D for submit@debbugs.gnu.org; Wed, 14 May 2014 12:25:55 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:41557) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkc06-0006ZI-La for 17397@debbugs.gnu.org; Wed, 14 May 2014 12:25:51 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4EGPhir013627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 16:25:44 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EGPfoJ025700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2014 16:25:42 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EGPfBX010084; Wed, 14 May 2014 16:25:41 GMT MIME-Version: 1.0 Message-ID: <3c202eb7-5ea9-4f54-9438-12d5207af4e0@default> Date: Wed, 14 May 2014 09:25:40 -0700 (PDT) From: Drew Adams To: martin rudalics , 17397@debbugs.gnu.org Subject: RE: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> <5373160A.3070604@gmx.at> In-Reply-To: <5373160A.3070604@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > > To get *Help* to DTRT for the code or user that previously used > > `temp-buffer-setup-hook' or `temp-buffer-show-hook, is it > > appropriate to put the same things on `temp-buffer-window-setup-hook' > > and `temp-buffer-window-show-hook' instead? Or will that maybe > > have unwanted effects because `with-temp-buffer-window' is perhaps > > used for more than just *Help*? >=20 > Both `with-output-to-temp-buffer' and `with-temp-buffer-window' are > and can be used for other things than displaying *Help*. For `with-output-to-temp-buffer': NOW, yes. Before, no - it was pretty much hardwired to help mode. So there will be users and existing 3rd-party code that depend on that behavior, which endured for 30 years or so. This is why I have argued that the right fix for that problem was not to change the behavior of `with-output-to-temp-buffer', and thus gratuitously break such code and user expectations, but to make a new macro for dealing with temporary buffer display that was not hardwired to help. Emacs itself could move to using that new macro, of course, but there should be no reason to break the longstanding behavior of `with-output-to-temp-buffer'. > > Not clear to me. And I find no help in the doc or NEWS - or in > > this bug thread, so far. >=20 > The manual says about `with-temp-buffer-window' that >=20 > This macro uses the normal hooks `temp-buffer-window-setup-hook' > and `temp-buffer-window-show-hook' in place of the analogous > hooks run by `with-output-to-temp-buffer'. >=20 > What else do you need? What did I say? Yes, I read that in the manual. What about a function that has been on `temp-buffer-setup-hook' or `temp-buffer-show-hook', and that was specifically put there for help, i.e., that expects help mode? Is it necessarily appropriate to put that function on the *-window-* hooks, without modifying it to work around use in a non-help mode? I don't think that is the case, in general. And I don't see a hook that is analogous and specifically for help. In my case of `fit-frame-if-one-window', this is not a problem AFAICT - I added it to `temp-buffer-window-show-hook'. But in the general case there is a problem in moving a function from a temp-buffer hook to a temp-buffer-window hook, whenever that function is specifically aimed at help (expects help mode). Sure, users and libraries can also change such a function, so that it tests the buffer or mode to see whether it involves help. But this is gratuitous hassling, IMO - it should not be necessary. I made the further point that none of this is documented, AFAICT. Nothing about migrating one's use of temp-buffer stuff to whatever is appropriate for Emacs 24.4+. Nothing about incompatible behavior changes for the temp-buffer stuff. > > Should I be adding `fit-frame-if-one-window' to `temp-buffer-window' > > for Emacs 24.4, to get the effect it has in Emacs 24.3 (and prior) > > by being on `temp-buffer-show-hook'? >=20 > I suppose you want to add it to `temp-buffer-window-show-hook'. I supposed so too, and I did. I asked the question several times, hoping to incite adding some migration explanation to the doc. But thanks anyway for confirming. I still hope someone updates the doc. But again, though that is OK for `fit-frame-if-one-window', since I want to invoke that regardless of which temp buffer is displayed, it is not OK in general for functions that have been on `temp-buffer-show-hook'. It is likely that at least some such functions are specific to help mode, since `temp-buffer-show-hook' was dedicated to help previously (and for so long). What do you tell library maintainers or users who have a function on `temp-buffer-show-hook' that is appropriate for help mode but not for other temp buffers? Such information should be in the doc, IMO. > > If not, how to get the same effect? If yes, how to deal with other > > possible uses of `with-temp-buffer-window', which have nothing to do > > with *Help*? (In the case of `fit-frame-if-one-window', that would > > probably not hurt anything, but the question is more general.) >=20 > Emacs has a `temp-buffer-resize-mode' which is tied to temporary buffers > and not to `help-mode'. To "deal with other possible uses" of temporary > buffers, a function run by `temp-buffer-show-hook' or > `temp-buffer-window-show-hook' should probably check whether the buffer > is in help mode. It will have to, now. Too bad. > In this regard nothing has changed wrt earlier version where a user > removed `help-mode-setup' from `temp-buffer-setup-hook' and > `help-mode-finish' from `temp-buffer-show-hook'. That is a very roundabout way of saying that IF there previously were a user who for some reason coded things up to approximate what the code does now, THEN ... "Nothing has changed"! So-called temp-buffer display was previously coupled with help display. Functions on `temp-buffer-show-hook' in existing code or user setups could well depend on that behavior. It was expected that the temp buffer displayed would be in help mode - because it WAS - for 30 years. Sure, someone could have jumped through hoops to use `with-output-to-temp-buffer' without help mode. But that would have been relatively rare. What percentage of the uses of `with-output-to-temp-buffer' in the Emacs code corresponded to this? Not more than 1% would be my guess - maybe 0%. It is hardly the common use case of `with-output-to-temp-buffer'. To suggest that it is, that "nothing has changed", would be disingenuous. Yes, I note that you did not claim that in general - you qualified it as being the case only for such exceptional uses (without acknowledging that they are exceptional). But the impression can be got from a cursory reading that you are saying that nothing has changed in general, i.e., for most uses of `with-output-to-temp-buffer'. In fact, I have jumped through that hoop that in some of my code, so I do recognize such an exception: (defmacro bmkp-with-output-to-plain-temp-buffer (buf &rest body) "Like `with-output-to-temp-buffer', but with no *Help* navigation stuff." `(unwind-protect (progn (remove-hook 'temp-buffer-setup-hook 'help-mode-setup) (remove-hook 'temp-buffer-show-hook 'help-mode-finish) (with-output-to-temp-buffer ,buf ,@body)) (add-hook 'temp-buffer-setup-hook 'help-mode-setup) (add-hook 'temp-buffer-show-hook 'help-mode-finish))) But doing things like this was no doubt uncommon. That was the point of my original bug report asking that Emacs decouple temporary buffer display from help display, i.e., that it provide a real temp-buffer display that does not involve help (as does the macro above, in a workaround way). What was wrong was the way this decoupling was done in Emacs: changing the behavior of macro `with-output-to-temp-buffer'. That was misguided, IMHO, and not necessary. That boat has apparently sailed, however. > Maybe you could also use `help-mode-hook' to do something for help > buffers exclusively and avoid other temporary buffers. >=20 > > The existing doc is anyway wrong in some cases, AFAICT: The doc > > string of `with-temp-buffer-window' says: > > > > This construct is similar to `with-output-to-temp-buffer' > > but, neither runs `temp-buffer-setup-hook' which usually puts > > the buffer in Help mode, nor `temp-buffer-show-function' (the > > ACTION argument replaces this). >=20 > What is wrong here? `temp-buffer-setup-hook' no longer "usually puts the buffer in Help mode". > > And the doc string of `temp-buffer-setup-hook', likewise, says: > > > > This hook is normally set up with a function to put the buffer > > in Help mode. >=20 > This is still the case for the release version. IIRC Leo Liu changed it > on the trunk so the doc-string should be probably updated there. The doc string is not updated in the trunk build I cited, from April 29. I don't have a more recent build. But yes, the doc should be updated - that was what I was pointing out. > > I don't get the impression that either of those statements is > > true anymore. It seems like there is *no relation* anymore > > between such temp-buffer things and Help mode. Furthermore, > > grepping for `temp-buffer-setup-hook' in the Emacs sources > > shows that it is not used for this at all anymore. >=20 > The connection between temporary buffers and help mode is established > by `with-help-window' which uses `with-temp-buffer-window'. Yes, I know. And previously such a connection was hardwired in `with-output-to-temp-buffer'. That behavior should not have changed. Not because it was good to couple the two behaviors, but because they have been so coupled for a long time in `with-output-to-temp-buffers'. The right approach would have been to (a) leave `with-output-to-temp-buffer' the way it was, (b) decouple temp-buffer display from help mode by coming up with new macros, and (c) use the new macros in the Emacs source code (this has been done). That way, the Emacs code would no longer use `with-output-to-temp-buffer', and thus would no longer depend on a coupling of temp-buffer display with help, BUT users would not be bothered and existing 3rd-party code would not be broken by a change to `with-output-to-temp-buffer': it would continue to work as usual, coupling temp with help as before. Eventually, `with-output-to-temp-buffer' would be abandoned everywhere, naturally. I pointed this out in my original bug report. That is not what was done. We now have to live with the consequences of the incompatible change. That calls for doc that explains the change and how to deal with it. The doc (manual and/or NEWS) should clearly point out (a) what `with-output-to-temp-buffer' does now, and (b) that it does not do what it has always done before, and (c) this is how to migrate existing code that uses it: A, B, C,...Z. For Emacs's source code the change was trivial: replace uses of `with-output-to-temp-buffer' with uses of the new macro. But for 3rd-party code that supports multiple Emacs versions the change is not so trivial. It is too bad that we have arrived here, but we have. Now let's patch things up by at least letting users know about the damage done and how to make do with it. From debbugs-submit-bounces@debbugs.gnu.org Wed May 14 13:34:18 2014 Received: (at 17397) by debbugs.gnu.org; 14 May 2014 17:34:18 +0000 Received: from localhost ([127.0.0.1]:35470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkd4K-0000Ec-N6 for submit@debbugs.gnu.org; Wed, 14 May 2014 13:34:17 -0400 Received: from mout.gmx.net ([212.227.17.20]:62537) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkd4G-0000EE-DL for 17397@debbugs.gnu.org; Wed, 14 May 2014 13:34:14 -0400 Received: from [93.82.79.5] ([93.82.79.5]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M6eTo-1WysjQ0qrk-00wVoE; Wed, 14 May 2014 19:34:04 +0200 Message-ID: <5373A902.1020908@gmx.at> Date: Wed, 14 May 2014 19:33:54 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 17397@debbugs.gnu.org Subject: Re: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> <5373160A.3070604@gmx.at> <3c202eb7-5ea9-4f54-9438-12d5207af4e0@default> In-Reply-To: <3c202eb7-5ea9-4f54-9438-12d5207af4e0@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ktD3J9wZrnmMkcpyROnM0j5vJby3UYsMrP9eOnH+Y2bfn4NB2JF HHgkrslDD81nPkyB2BQ21AnVKJ2B2OD22lSRCm+URkwmLijFB3EqBgkZRXZFOVO+up+DS9a IaL57rExRH4Zs9AQwBVD3kkUJHskustihffAxrcVq0GhYn67SYk1t/wyRm6Rumq/G4JMo+H 7wahSrt5TGCICX6LV432A== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> Both `with-output-to-temp-buffer' and `with-temp-buffer-window' are >> and can be used for other things than displaying *Help*. > > For `with-output-to-temp-buffer': NOW, yes. Before, no - it was > pretty much hardwired to help mode. > > So there will be users and existing 3rd-party code that depend on > that behavior, which endured for 30 years or so. > > This is why I have argued that the right fix for that problem was > not to change the behavior of `with-output-to-temp-buffer', and thus > gratuitously break such code and user expectations, but to make a > new macro for dealing with temporary buffer display that was not > hardwired to help. > > Emacs itself could move to using that new macro, of course, but there > should be no reason to break the longstanding behavior of > `with-output-to-temp-buffer'. It wasn't my intention to change the longstanding behavior of `with-output-to-temp-buffer'. > What did I say? Yes, I read that in the manual. What about a function > that has been on `temp-buffer-setup-hook' or `temp-buffer-show-hook', > and that was specifically put there for help, i.e., that expects help > mode? Generally assuming that a temporary buffer is always in help mode is wrong. Callers of `with-output-to-temp-buffer' can always change the mode as, for example, ediff does. > Is it necessarily appropriate to put that function on the *-window-* > hooks, without modifying it to work around use in a non-help mode? > I don't think that is the case, in general. And I don't see a hook > that is analogous and specifically for help. > > In my case of `fit-frame-if-one-window', this is not a problem AFAICT > - I added it to `temp-buffer-window-show-hook'. But in the general > case there is a problem in moving a function from a temp-buffer hook to > a temp-buffer-window hook, whenever that function is specifically aimed > at help (expects help mode). > > Sure, users and libraries can also change such a function, so that it > tests the buffer or mode to see whether it involves help. But this is > gratuitous hassling, IMO - it should not be necessary. > > I made the further point that none of this is documented, AFAICT. > Nothing about migrating one's use of temp-buffer stuff to whatever > is appropriate for Emacs 24.4+. Nothing about incompatible > behavior changes for the temp-buffer stuff. It was wrong to put a function on `temp-buffer-show-hook' without testing whether the associated buffer was in help mode when the intention is to run the function for help mode buffers only. >> > Should I be adding `fit-frame-if-one-window' to `temp-buffer-window' >> > for Emacs 24.4, to get the effect it has in Emacs 24.3 (and prior) >> > by being on `temp-buffer-show-hook'? >> >> I suppose you want to add it to `temp-buffer-window-show-hook'. > > I supposed so too, and I did. I asked the question several times, > hoping to incite adding some migration explanation to the doc. But > thanks anyway for confirming. I still hope someone updates the doc. > > But again, though that is OK for `fit-frame-if-one-window', since I > want to invoke that regardless of which temp buffer is displayed, it > is not OK in general for functions that have been on > `temp-buffer-show-hook'. > > It is likely that at least some such functions are specific to help > mode, since `temp-buffer-show-hook' was dedicated to help previously > (and for so long). Such functions were based on a wrong assumption. > What do you tell library maintainers or users who have a function on > `temp-buffer-show-hook' that is appropriate for help mode but not > for other temp buffers? Such information should be in the doc, IMO. I tell them here on this list that such a function should have tested whether the buffer is in help mode. >> Emacs has a `temp-buffer-resize-mode' which is tied to temporary buffers >> and not to `help-mode'. To "deal with other possible uses" of temporary >> buffers, a function run by `temp-buffer-show-hook' or >> `temp-buffer-window-show-hook' should probably check whether the buffer >> is in help mode. > > It will have to, now. Too bad. On the contrary. Older versions of Emacs running your code will benefit from more correct code. > That is a very roundabout way of saying that IF there previously were > a user who for some reason coded things up to approximate what the > code does now, THEN ... "Nothing has changed"! > > So-called temp-buffer display was previously coupled with help display. > Functions on `temp-buffer-show-hook' in existing code or user setups > could well depend on that behavior. It was expected that the temp > buffer displayed would be in help mode - because it WAS - for 30 years. > > Sure, someone could have jumped through hoops to use > `with-output-to-temp-buffer' without help mode. But that would have > been relatively rare. What percentage of the uses of > `with-output-to-temp-buffer' in the Emacs code corresponded to this? > Not more than 1% would be my guess - maybe 0%. > > It is hardly the common use case of `with-output-to-temp-buffer'. > > To suggest that it is, that "nothing has changed", would be > disingenuous. Yes, I note that you did not claim that in general - > you qualified it as being the case only for such exceptional uses > (without acknowledging that they are exceptional). But the > impression can be got from a cursory reading that you are saying > that nothing has changed in general, i.e., for most uses of > `with-output-to-temp-buffer'. > > In fact, I have jumped through that hoop that in some of my code, > so I do recognize such an exception: > > (defmacro bmkp-with-output-to-plain-temp-buffer (buf &rest body) > "Like `with-output-to-temp-buffer', but with no *Help* navigation stuff." > `(unwind-protect > (progn > (remove-hook 'temp-buffer-setup-hook 'help-mode-setup) > (remove-hook 'temp-buffer-show-hook 'help-mode-finish) > (with-output-to-temp-buffer ,buf ,@body)) > (add-hook 'temp-buffer-setup-hook 'help-mode-setup) > (add-hook 'temp-buffer-show-hook 'help-mode-finish))) > > But doing things like this was no doubt uncommon. That was the point > of my original bug report asking that Emacs decouple temporary buffer > display from help display, i.e., that it provide a real temp-buffer > display that does not involve help (as does the macro above, in a > workaround way). So you fit a frame shown by `bmkp-with-output-to-plain-temp-buffer' even if the buffer is not in help mode? > What was wrong was the way this decoupling was done in Emacs: > changing the behavior of macro `with-output-to-temp-buffer'. That > was misguided, IMHO, and not necessary. That boat has apparently > sailed, however. Maybe. >> > This construct is similar to `with-output-to-temp-buffer' >> > but, neither runs `temp-buffer-setup-hook' which usually puts >> > the buffer in Help mode, nor `temp-buffer-show-function' (the >> > ACTION argument replaces this). >> >> What is wrong here? > > `temp-buffer-setup-hook' no longer "usually puts the buffer in Help > mode". I see. This is due to Leo's change. >> > And the doc string of `temp-buffer-setup-hook', likewise, says: >> > >> > This hook is normally set up with a function to put the buffer >> > in Help mode. >> >> This is still the case for the release version. IIRC Leo Liu changed it >> on the trunk so the doc-string should be probably updated there. > > The doc string is not updated in the trunk build I cited, from April 29. > I don't have a more recent build. But yes, the doc should be updated - > that was what I was pointing out. Agreed. >> The connection between temporary buffers and help mode is established >> by `with-help-window' which uses `with-temp-buffer-window'. > > Yes, I know. > > And previously such a connection was hardwired in > `with-output-to-temp-buffer'. That behavior should not have changed. > Not because it was good to couple the two behaviors, but because they > have been so coupled for a long time in `with-output-to-temp-buffers'. > > The right approach would have been to (a) leave > `with-output-to-temp-buffer' the way it was, (b) decouple temp-buffer > display from help mode by coming up with new macros, and (c) use the > new macros in the Emacs source code (this has been done). > > That way, the Emacs code would no longer use `with-output-to-temp-buffer', > and thus would no longer depend on a coupling of temp-buffer display > with help, BUT users would not be bothered and existing 3rd-party code > would not be broken by a change to `with-output-to-temp-buffer': it would > continue to work as usual, coupling temp with help as before. Eventually, > `with-output-to-temp-buffer' would be abandoned everywhere, naturally. I might agree with you here. > I pointed this out in my original bug report. That is not what was > done. We now have to live with the consequences of the incompatible > change. That calls for doc that explains the change and how to deal > with it. > > The doc (manual and/or NEWS) should clearly point out (a) what > `with-output-to-temp-buffer' does now, Here ... > and (b) that it does not do what > it has always done before, and (c) this is how to migrate existing code > that uses it: A, B, C,...Z. > > For Emacs's source code the change was trivial: replace uses of > `with-output-to-temp-buffer' with uses of the new macro. ... and here ... > But for > 3rd-party code that supports multiple Emacs versions the change is not > so trivial. > > It is too bad that we have arrived here, but we have. Now let's patch > things up by at least letting users know about the damage done and how > to make do with it. ... you're lumping together a change in `with-help-window' with a change affecting `with-output-to-temp-buffer'. I can only address the former. martin From debbugs-submit-bounces@debbugs.gnu.org Wed May 14 15:35:20 2014 Received: (at 17397) by debbugs.gnu.org; 14 May 2014 19:35:21 +0000 Received: from localhost ([127.0.0.1]:34832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkexR-0001yf-Ii for submit@debbugs.gnu.org; Wed, 14 May 2014 15:35:18 -0400 Received: from userp1050.oracle.com ([156.151.31.82]:20144) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkexJ-0001yK-9d for 17397@debbugs.gnu.org; Wed, 14 May 2014 15:35:12 -0400 Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by userp1050.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4EIg759019770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <17397@debbugs.gnu.org>; Wed, 14 May 2014 18:42:07 GMT Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4EIg2Wg024353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 18:42:03 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s4EIg1qR008509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2014 18:42:02 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EIg1ui025845; Wed, 14 May 2014 18:42:01 GMT MIME-Version: 1.0 Message-ID: Date: Wed, 14 May 2014 11:41:59 -0700 (PDT) From: Drew Adams To: martin rudalics , 17397@debbugs.gnu.org Subject: RE: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> <5373160A.3070604@gmx.at> <3c202eb7-5ea9-4f54-9438-12d5207af4e0@default> <5373A902.1020908@gmx.at> In-Reply-To: <5373A902.1020908@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userp1040.oracle.com [156.151.31.81] X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > >> Both `with-output-to-temp-buffer' and `with-temp-buffer-window' are > >> and can be used for other things than displaying *Help*. > > > > For `with-output-to-temp-buffer': NOW, yes. Before, no - it was > > pretty much hardwired to help mode. > > > > So there will be users and existing 3rd-party code that depend on > > that behavior, which endured for 30 years or so. > > > > This is why I have argued that the right fix for that problem was > > not to change the behavior of `with-output-to-temp-buffer', and thus > > gratuitously break such code and user expectations, but to make a > > new macro for dealing with temporary buffer display that was not > > hardwired to help. > > > > Emacs itself could move to using that new macro, of course, but there > > should be no reason to break the longstanding behavior of > > `with-output-to-temp-buffer'. >=20 > It wasn't my intention to change the longstanding behavior of > `with-output-to-temp-buffer'. Well, it's done. Is it your intention to revert that change? ;-) > > What did I say? Yes, I read that in the manual. What about a functio= n > > that has been on `temp-buffer-setup-hook' or `temp-buffer-show-hook', > > and that was specifically put there for help, i.e., that expects help > > mode? >=20 > Generally assuming that a temporary buffer is always in help mode is > wrong. Callers of `with-output-to-temp-buffer' can always change the > mode as, for example, ediff does. As we have discussed at length elsewhere, `with-output-to-temp-buffer' was NOT just about temporary buffers. In spite of its name, it was about a temporary buffer in help mode. That's a fact of life. I lamented the name-vs-behavior mismatch, and filed a bug about that, but that's the way it became over time, and it's been that way for a very long time now. > > Is it necessarily appropriate to put that function on the *-window-* > > hooks, without modifying it to work around use in a non-help mode? > > I don't think that is the case, in general. And I don't see a hook > > that is analogous and specifically for help. > > > > In my case of `fit-frame-if-one-window', this is not a problem AFAICT > > - I added it to `temp-buffer-window-show-hook'. But in the general > > case there is a problem in moving a function from a temp-buffer hook t= o > > a temp-buffer-window hook, whenever that function is specifically aime= d > > at help (expects help mode). > > > > Sure, users and libraries can also change such a function, so that it > > tests the buffer or mode to see whether it involves help. But this is > > gratuitous hassling, IMO - it should not be necessary. > > > > I made the further point that none of this is documented, AFAICT. > > Nothing about migrating one's use of temp-buffer stuff to whatever > > is appropriate for Emacs 24.4+. Nothing about incompatible > > behavior changes for the temp-buffer stuff. >=20 > It was wrong to put a function on `temp-buffer-show-hook' without > testing whether the associated buffer was in help mode when the > intention is to run the function for help mode buffers only. I disagree. `with-output-to-temp-buffer' simply has never (almost never; I cannot find an old enough version where it was ever the case) been about temp buffers other than help-mode buffers. You cannot just reinterpret things based on what the name suggests it should do. It has not done what its name says for 30 years now. On the contrary, in the very rare cases where someone actually tried to use `w-o-t-t-b' for something other than help mode, s?he had to jump through a hoop to get that behavior. It is not up to all functions that have been on that hook to test whether the buffer is in help mode. The behavior has been to ALWAYS put the buffer in help mode. To get a different behavior you needed to jump through a hoop (removing stuff from `temp-buffer-setup-hook'). > >> > Should I be adding `fit-frame-if-one-window' to `temp-buffer-wind= ow' > >> > for Emacs 24.4, to get the effect it has in Emacs 24.3 (and prior= ) > >> > by being on `temp-buffer-show-hook'? > >> > >> I suppose you want to add it to `temp-buffer-window-show-hook'. > > > > I supposed so too, and I did. I asked the question several times, > > hoping to incite adding some migration explanation to the doc. But > > thanks anyway for confirming. I still hope someone updates the doc. > > > > But again, though that is OK for `fit-frame-if-one-window', since I > > want to invoke that regardless of which temp buffer is displayed, it > > is not OK in general for functions that have been on > > `temp-buffer-show-hook'. > > > > It is likely that at least some such functions are specific to help > > mode, since `temp-buffer-show-hook' was dedicated to help previously > > (and for so long). >=20 > Such functions were based on a wrong assumption. No, they were not. They were based on the longstanding and documented behavior of `with-output-to-temp-buffer'. See above. The macro was simply misnamed for what it did. And there unfortunately was no macro that did what its name suggests. That was the original bug I reported. > > What do you tell library maintainers or users who have a function on > > `temp-buffer-show-hook' that is appropriate for help mode but not > > for other temp buffers? Such information should be in the doc, IMO. >=20 > I tell them here on this list that such a function should have tested > whether the buffer is in help mode. Not helpful, IMO. > >> Emacs has a `temp-buffer-resize-mode' which is tied to temporary buff= ers > >> and not to `help-mode'. To "deal with other possible uses" of tempor= ary > >> buffers, a function run by `temp-buffer-show-hook' or > >> `temp-buffer-window-show-hook' should probably check whether the buff= er > >> is in help mode. > > > > It will have to, now. Too bad. >=20 > On the contrary. Older versions of Emacs running your code will benefit > from more correct code. "It", not "I". I don't have any such code. Anyway, that is not "on the contrary". You confirm that "It will have to, now." What is too bad is that the function code needs to be changed at all= . There was no need to change the misnamed `with-output-to-temp-buffer' behavior. You even claimed above that that was not your intention. If the behavior had not been changed then there would be no "too bad" here - no ne= ed to change a function someone has on the hook. > So you fit a frame shown by `bmkp-with-output-to-plain-temp-buffer' even > if the buffer is not in help mode? Yes. I already made it clear that my use of `fit-frame-if-one-window' on `temp-buffer-show-hook' is not a problem for non-help modes. And I said clearly that I have added it to `temp-buffer-window-show-hook'. That will not be true in general for functions that users and libraries have on `with-output-to-temp-buffer'. That's the point here. > > What was wrong was the way this decoupling was done in Emacs: > > changing the behavior of macro `with-output-to-temp-buffer'. That > > was misguided, IMHO, and not necessary. That boat has apparently > > sailed, however. >=20 > Maybe. You mean there's hope? > I see. This is due to Leo's change. > > The right approach would have been to (a) leave > > `with-output-to-temp-buffer' the way it was, (b) decouple temp-buffer > > display from help mode by coming up with new macros, and (c) use the > > new macros in the Emacs source code (this has been done). > > > > That way, the Emacs code would no longer use `with-output-to-temp- > > buffer', and thus would no longer depend on a coupling of temp-buffer > > display with help, BUT users would not be bothered and existing 3rd-pa= rty > > code would not be broken by a change to `with-output-to-temp-buffer': = it > > would continue to work as usual, coupling temp with help as before. > > Eventually, `with-output-to-temp-buffer' would be abandoned everywhere= , > > naturally. >=20 > I might agree with you here. You mean there's hope? ;-) > > I pointed this out in my original bug report. That is not what was > > done. We now have to live with the consequences of the incompatible > > change. That calls for doc that explains the change and how to deal > > with it. > > > > The doc (manual and/or NEWS) should clearly point out (a) what > > `with-output-to-temp-buffer' does now, >=20 > Here ... If you mean that it suffices to let users know about such things in a bug thread then I disagree. In particular, NEWS should mention incompatibl= e changes and tell users how to migrate code to accommodate those changes. > > and (b) that it does not do what > > it has always done before, and (c) this is how to migrate existing cod= e > > that uses it: A, B, C,...Z. > > > > For Emacs's source code the change was trivial: replace uses of > > `with-output-to-temp-buffer' with uses of the new macro. >=20 > ... and here ... Dunno what you are saying here; sorry. "Here ... and here ..." what? > ... you're lumping together a change in `with-help-window' with a change > affecting `with-output-to-temp-buffer'. I can only address the former. Why do you say that? I have no problem with the creation of `with-help-window' and its use in Emacs code, including instead of `with-output-to-temp-buffer'. It is the incompatible change to `with-output-to-temp-buffer' that is the problem. That, and a lack of doc mentioning such things to users. From debbugs-submit-bounces@debbugs.gnu.org Thu May 15 03:50:52 2014 Received: (at 17397) by debbugs.gnu.org; 15 May 2014 07:50:52 +0000 Received: from localhost ([127.0.0.1]:35160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkqRG-0000hV-QX for submit@debbugs.gnu.org; Thu, 15 May 2014 03:50:51 -0400 Received: from mout.gmx.net ([212.227.17.20]:54966) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkqRD-0000hF-My for 17397@debbugs.gnu.org; Thu, 15 May 2014 03:50:49 -0400 Received: from [194.96.35.110] ([194.96.35.110]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M0tr1-1X4RzT35O3-00v96M; Thu, 15 May 2014 09:50:41 +0200 Message-ID: <537471C7.2000007@gmx.at> Date: Thu, 15 May 2014 09:50:31 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 17397@debbugs.gnu.org Subject: Re: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> <5373160A.3070604@gmx.at> <3c202eb7-5ea9-4f54-9438-12d5207af4e0@default> <5373A902.1020908@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5kl73nWzkxU2sjaJ+SsVSQCzUB8C60WQyCIUw7LWeitEDo9dEUO CBtpMyJkJepp8TAoVEbcNB9Au3rsVpxIq/IfLfyU0ca6w9DhjdVeRsh/PoM2J9UNH6tCDlw c0DaU3RZQKPO+E4+DzihdckowrtQ8aMK9U/z8vvExD+oFvlrbyVRBpv4XJ9Hki5sGLRYlrV xUhyq2hyL6g6ROrFQSh+A== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> It wasn't my intention to change the longstanding behavior of >> `with-output-to-temp-buffer'. > > Well, it's done. Is it your intention to revert that change? ;-) No. I'm too surprised that it didn't cause any misbehavior so far. > As we have discussed at length elsewhere, `with-output-to-temp-buffer' was > NOT just about temporary buffers. In spite of its name, it was about a > temporary buffer in help mode. That's a fact of life. I lamented the > name-vs-behavior mismatch, and filed a bug about that, but that's the way > it became over time, and it's been that way for a very long time now. Since after Leo has taken it out, I haven't seen any complaints yet. So even if it is a fact of life it apparently didn't have any real impact. Now if only all facts of life were like this ... > I disagree. `with-output-to-temp-buffer' simply has never (almost never; > I cannot find an old enough version where it was ever the case) been about > temp buffers other than help-mode buffers. > > You cannot just reinterpret things based on what the name suggests it > should do. It has not done what its name says for 30 years now. > > On the contrary, in the very rare cases where someone actually tried to > use `w-o-t-t-b' for something other than help mode, s?he had to jump > through a hoop to get that behavior. > > It is not up to all functions that have been on that hook to test whether > the buffer is in help mode. Obviously not. But if a function wants to act only upon buffers in help mode, that function should check whether the buffer is in help mode. > The behavior has been to ALWAYS put the buffer > in help mode. If the intention was to ALWAYS put the buffer in help mode, there would not have been any reason to do it with a hook. Rather, the `help-mode' call would have been hardcoded in `with-output-to-temp-buffer'. > To get a different behavior you needed to jump through a > hoop (removing stuff from `temp-buffer-setup-hook'). IIRC clients do that by simply changing the mode in the BODY of `with-output-to-temp-buffer'. >> > It is likely that at least some such functions are specific to help >> > mode, since `temp-buffer-show-hook' was dedicated to help previously >> > (and for so long). >> >> Such functions were based on a wrong assumption. > > No, they were not. They were based on the longstanding and documented > behavior of `with-output-to-temp-buffer'. See above. The macro was > simply misnamed for what it did. And there unfortunately was no macro > that did what its name suggests. That was the original bug I reported. I see only one manual reference for `temp-buffer-setup-hook' which says that "This hook is normally set up with a function to put the buffer in Help mode.". The term "normally" clearly implies that an application in order to be safe must handle behavior that is not normal. >> > What do you tell library maintainers or users who have a function on >> > `temp-buffer-show-hook' that is appropriate for help mode but not >> > for other temp buffers? Such information should be in the doc, IMO. >> >> I tell them here on this list that such a function should have tested >> whether the buffer is in help mode. > > Not helpful, IMO. Our opinions differ. >> >> Emacs has a `temp-buffer-resize-mode' which is tied to temporary buffers >> >> and not to `help-mode'. To "deal with other possible uses" of temporary >> >> buffers, a function run by `temp-buffer-show-hook' or >> >> `temp-buffer-window-show-hook' should probably check whether the buffer >> >> is in help mode. >> > >> > It will have to, now. Too bad. >> >> On the contrary. Older versions of Emacs running your code will benefit >> from more correct code. > > "It", not "I". I don't have any such code. Then I don't understand why you've been asking for help before. > Anyway, that is not "on the contrary". You confirm that "It will have to, > now." What is too bad is that the function code needs to be changed at all. It should never have been written that way. So "now" is a good occasion to fix this. > There was no need to change the misnamed `with-output-to-temp-buffer' > behavior. You even claimed above that that was not your intention. If the > behavior had not been changed then there would be no "too bad" here - no need > to change a function someone has on the hook. So let's delay this discussion until "someone" shows up. > You mean there's hope? That the `with-output-to-temp-buffer' change will be reverted? If someone finds a real problem in it, yes. >> I might agree with you here. > > You mean there's hope? ;-) See above. >> > I pointed this out in my original bug report. That is not what was >> > done. We now have to live with the consequences of the incompatible >> > change. That calls for doc that explains the change and how to deal >> > with it. >> > >> > The doc (manual and/or NEWS) should clearly point out (a) what >> > `with-output-to-temp-buffer' does now, >> >> Here ... > > If you mean that it suffices to let users know about such things in a > bug thread then I disagree. In particular, NEWS should mention incompatible > changes and tell users how to migrate code to accommodate those changes. > >> > and (b) that it does not do what >> > it has always done before, and (c) this is how to migrate existing code >> > that uses it: A, B, C,...Z. >> > >> > For Emacs's source code the change was trivial: replace uses of >> > `with-output-to-temp-buffer' with uses of the new macro. >> >> ... and here ... > > Dunno what you are saying here; sorry. "Here ... and here ..." what? > >> ... you're lumping together a change in `with-help-window' with a change >> affecting `with-output-to-temp-buffer'. I can only address the former. > > Why do you say that? I have no problem with the creation of > `with-help-window' and its use in Emacs code, including instead of > `with-output-to-temp-buffer'. It is the incompatible > change to `with-output-to-temp-buffer' that is the problem. That, and a > lack of doc mentioning such things to users. If you mean that we should document the removal of `help-mode' from `temp-buffer-setup-hook' then I obviously agree. I have no idea what else you mean to do. martin From debbugs-submit-bounces@debbugs.gnu.org Thu May 15 10:02:39 2014 Received: (at 17397) by debbugs.gnu.org; 15 May 2014 14:02:39 +0000 Received: from localhost ([127.0.0.1]:36174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkwF4-0003xy-Rl for submit@debbugs.gnu.org; Thu, 15 May 2014 10:02:39 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:44283) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkwF0-0003xe-Jq for 17397@debbugs.gnu.org; Thu, 15 May 2014 10:02:35 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4FE2Rd9001715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 14:02:28 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s4FE2OaY025998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 14:02:25 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4FE2OTX000288; Thu, 15 May 2014 14:02:24 GMT MIME-Version: 1.0 Message-ID: <934fdf6d-ae95-4d87-a303-ea2bf340e3d2@default> Date: Thu, 15 May 2014 07:02:23 -0700 (PDT) From: Drew Adams To: martin rudalics , 17397@debbugs.gnu.org Subject: RE: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> <5373160A.3070604@gmx.at> <3c202eb7-5ea9-4f54-9438-12d5207af4e0@default> <5373A902.1020908@gmx.at> <537471C7.2000007@gmx.at> In-Reply-To: <537471C7.2000007@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > >> It wasn't my intention to change the longstanding behavior of > >> `with-output-to-temp-buffer'. > > > > Well, it's done. Is it your intention to revert that change? ;-) >=20 > No. I'm too surprised that it didn't cause any misbehavior so far. Bug reports of regressions don't count? > > As we have discussed at length elsewhere, `with-output-to-temp-buffer' > > was NOT just about temporary buffers. In spite of its name, it was ab= out > > a temporary buffer in help mode. That's a fact of life. I lamented t= he > > name-vs-behavior mismatch, and filed a bug about that, but that's the = way > > it became over time, and it's been that way for a very long time now. >=20 > Since after Leo has taken it out, I haven't seen any complaints yet. So > even if it is a fact of life it apparently didn't have any real impact. > Now if only all facts of life were like this ... This and related bug reports are complaints. And they describe real impact= . > > I disagree. `with-output-to-temp-buffer' simply has never (almost nev= er; > > I cannot find an old enough version where it was ever the case) been > > about temp buffers other than help-mode buffers. > > > > You cannot just reinterpret things based on what the name suggests it > > should do. It has not done what its name says for 30 years now. > > > > On the contrary, in the very rare cases where someone actually tried t= o > > use `w-o-t-t-b' for something other than help mode, s?he had to jump > > through a hoop to get that behavior. > > > > It is not up to all functions that have been on that hook to test whet= her > > the buffer is in help mode. >=20 > Obviously not. But if a function wants to act only upon buffers in help > mode, that function should check whether the buffer is in help mode. Not if the macro used is `with-output-to-temp-buffer', since it has always taken care of establishing help mode. Until now. > > The behavior has been to ALWAYS put the buffer in help mode. >=20 > If the intention was to ALWAYS put the buffer in help mode, there would > not have been any reason to do it with a hook. Rather, the `help-mode' > call would have been hardcoded in `with-output-to-temp-buffer'. Do you really want to argue about what the original intentions were? `with-output-to-temp-buffer' was co-opted to serve only help, fairly early in its history. The name itself betrays a mismatch between its (longstanding) behavior and what its original intention might have been (as reflected by its name). You seem to be stretching, to find any justification whatsoever for this incompatible change to the behavior of `with-output-to-temp-buffer'. If you hide your eyes, of course you won't see - nothing I can do about that. > >> > It is likely that at least some such functions are specific to he= lp > >> > mode, since `temp-buffer-show-hook' was dedicated to help previou= sly > >> > (and for so long). > >> > >> Such functions were based on a wrong assumption. > > > > No, they were not. They were based on the longstanding and documented > > behavior of `with-output-to-temp-buffer'. See above. The macro was > > simply misnamed for what it did. And there unfortunately was no macro > > that did what its name suggests. That was the original bug I reported= . >=20 > I see only one manual reference for `temp-buffer-setup-hook' which says > that "This hook is normally set up with a function to put the buffer in > Help mode.". The term "normally" clearly implies that an application in > order to be safe must handle behavior that is not normal. You are ignoring reality. Code and users have had a reasonable expectation for 30 years about the behavior of `with-output-to-temp-buffer', and that has now been thrown out the window gratuitously. Gratuitously, because nothing was gained by it. Emacs could just as well have moved on to use new and different macros, without changing the `w-o-t-t-b' behavior. That was totally uncalled for and serves no purpose. Not necessary. > >> > What do you tell library maintainers or users who have a function= on > >> > `temp-buffer-show-hook' that is appropriate for help mode but not > >> > for other temp buffers? Such information should be in the doc, I= MO. > >> > >> I tell them here on this list that such a function should have tested > >> whether the buffer is in help mode. > > > > Not helpful, IMO. >=20 > Our opinions differ. Yes. Some info from a developer that is only buried in some bug thread might be helpful to the few who read that thread. But not more useful than that. Emacs users deserve better communication. Especially about incompatible changes. Especially about behavior that has remained stable for 30 years. Not communicating such info properly is irresponsible, IMHO. > If you mean that we should document the removal of `help-mode' from > `temp-buffer-setup-hook' then I obviously agree. Good. And consequently from `with-output-to-temp-buffer-buffer', which is what users will see in their code. Start with that. Plus an explanation of how to migrate code that expects `with-output-to-temp-buffer-buffer' to establish help mode. (Mention `with-help-window', `with-temp-buffer-window', etc.) Better would of course be to not screw `with-output-to-temp-buffer' at all. Emacs gains nothing by messing with that, and would lose nothing by restoring its behavior. I've seen no argument showing a loss by doing that. Do you have such an argument? Changing `w-o-t-t-b' is not at all necessary to accomplish the clean separation of temp buffer setup from help buffer setup that was the goal (and which I was the one to propose, FWIW). From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 02:22:44 2014 Received: (at 17397) by debbugs.gnu.org; 16 May 2014 06:22:45 +0000 Received: from localhost ([127.0.0.1]:36643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlBXY-0003eF-DQ for submit@debbugs.gnu.org; Fri, 16 May 2014 02:22:44 -0400 Received: from mout.gmx.net ([212.227.15.19]:54689) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlBXV-0003du-Fs for 17397@debbugs.gnu.org; Fri, 16 May 2014 02:22:42 -0400 Received: from [188.22.47.37] ([188.22.47.37]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lrek1-1Wuh6A0gsn-013N8k; Fri, 16 May 2014 08:22:31 +0200 Message-ID: <5375AE9C.2050304@gmx.at> Date: Fri, 16 May 2014 08:22:20 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams , 17397@debbugs.gnu.org Subject: Re: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> <5373160A.3070604@gmx.at> <3c202eb7-5ea9-4f54-9438-12d5207af4e0@default> <5373A902.1020908@gmx.at> <537471C7.2000007@gmx.at> <934fdf6d-ae95-4d87-a303-ea2bf340e3d2@default> In-Reply-To: <934fdf6d-ae95-4d87-a303-ea2bf340e3d2@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qP0kTFIykA75L6P1yc9BCMLfooY2YEg1fuyFof2vulHJk4Cqo2Y FMLTmeehrL11cERVpOHeAvpG01ue6djpTJ7M2s6zpt7wpT64bvtFwIZZjWTn01VG3ut3s15 pWe9NaThygADMnoc43v9pcrc6F1bXCPFH4oI1puW2A/jpLPAv2cIHJIZz1Eso22w+naCs4/ tQb8M/Kvp8xO5godLzSWw== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17397 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > You are ignoring reality. Indeed. I'll stop doing that now. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 10 19:01:52 2021 Received: (at 17397) by debbugs.gnu.org; 10 Oct 2021 23:01:52 +0000 Received: from localhost ([127.0.0.1]:56024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZhpH-0001DT-My for submit@debbugs.gnu.org; Sun, 10 Oct 2021 19:01:52 -0400 Received: from mail-pg1-f175.google.com ([209.85.215.175]:44659) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZhpC-00013s-8Y for 17397@debbugs.gnu.org; Sun, 10 Oct 2021 19:01:48 -0400 Received: by mail-pg1-f175.google.com with SMTP id s11so9033422pgr.11 for <17397@debbugs.gnu.org>; Sun, 10 Oct 2021 16:01:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=zEzEw9slgXyF+4UrFn/Qq0Ah+C8DLLHmw/AZmn3CYXM=; b=stbrFe2wPXP2YE9SqyWxtvmcHtw88JjraVekah5ZFDNivr9DFfFdDdhRqbWzNC/E/L tBL0XKVzE6euog5cS8Bp8jU1EHZx6wUGaaN1PHTGcHx3r6WBZvj60S4i75neoI989wTK 4ZmrqF0uBrc0nUAqiPyLph6fiXLzzfzsM5jXahJkioV1RIuVeVOSMGJPZ29vEJAnqT4Z GgmEtLqutgj8zzSxgPU2JFPo6LHfpUEUyT1t6+axvQEQWZkfyByALefu9Psi+VuuFHLe z4a9CY8vlfqYy/IlR1GvCXNelTWyUAf0VyxPlTmGV9eIzHi8KcjIDdwejOSs7aa3IHqL NNaA== X-Gm-Message-State: AOAM5328qsVpaADn+ChUYmugT/ewHzhlFXZnaVytBERx4HLgHXwjMcvD 34QSTBBQYgyd97xM5IAxPYtp9paiGdaR6+5IRzI= X-Google-Smtp-Source: ABdhPJycEcm018dEUAyyOaOhHukqlAqhb0OSQWspEJCMjtbuWr/+9We2zfBwfwYUT27+Im62LA2DQiXIcRBYEe+ubWo= X-Received: by 2002:a62:cd0f:0:b0:447:b8fe:d6c2 with SMTP id o15-20020a62cd0f000000b00447b8fed6c2mr22076098pfg.70.1633906900452; Sun, 10 Oct 2021 16:01:40 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 10 Oct 2021 16:01:40 -0700 From: Stefan Kangas In-Reply-To: <537471C7.2000007@gmx.at> (martin rudalics's message of "Thu, 15 May 2014 09:50:31 +0200") References: <18354a80-fa76-43bd-a06b-7d2c4ccbbfd4@default> <5373160A.3070604@gmx.at> <3c202eb7-5ea9-4f54-9438-12d5207af4e0@default> <5373A902.1020908@gmx.at> <537471C7.2000007@gmx.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Date: Sun, 10 Oct 2021 16:01:40 -0700 Message-ID: Subject: Re: bug#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 17397 Cc: 17397@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) tags 17397 + wontfix notabug close 17397 thanks martin rudalics writes: >>> It wasn't my intention to change the longstanding behavior of >>> `with-output-to-temp-buffer'. >> >> Well, it's done. Is it your intention to revert that change? ;-) > > No. I'm too surprised that it didn't cause any misbehavior so far. It's kind of hard to follow this bug report. >From what I gather, it's about reverting some change that was made many years ago, and the conclusion was that we don't intend to do that. In any case, that's even more unlikely to happen now, seven years later, so it hardly makes sense to keep this open. I'm therefore closing this bug report. From unknown Fri Aug 15 03:56:16 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 08 Nov 2021 12:24:07 +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