From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: with-output-to-temp-buffer and help-mode Date: Fri, 25 Jul 2014 08:34:22 -0700 (PDT) Message-ID: References: <1yppgtua5n.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1406302493 4566 80.91.229.3 (25 Jul 2014 15:34:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jul 2014 15:34:53 +0000 (UTC) To: Leo Liu , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 25 17:34:47 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XAhW9-0003ah-Ic for ged-emacs-devel@m.gmane.org; Fri, 25 Jul 2014 17:34:45 +0200 Original-Received: from localhost ([::1]:55447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAhW9-0007HR-1k for ged-emacs-devel@m.gmane.org; Fri, 25 Jul 2014 11:34:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAhVz-0007HJ-6b for emacs-devel@gnu.org; Fri, 25 Jul 2014 11:34:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XAhVr-0007ab-6l for emacs-devel@gnu.org; Fri, 25 Jul 2014 11:34:35 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:43774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAhVr-0007Zs-0C for emacs-devel@gnu.org; Fri, 25 Jul 2014 11:34:27 -0400 Original-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 s6PFYOj1022824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jul 2014 15:34:25 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6PFYNU6009525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Jul 2014 15:34:24 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6PFYNBe025346; Fri, 25 Jul 2014 15:34:23 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:173144 Archived-At: > > So I think this should just be reverted. >=20 > See Martin's comment in > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16038#14, there seems to b= e > problems either way. No, the solution should have been simple. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16038#71 Better yet, read the whole thread, and the thread of the original bug report (from me) that Martin referred to. > Note also temp-buffer-setup-hook is part of the public hooks of > with-output-to-temp-buffer so the macro makes no guarantee it will be in > Help mode. I.e. it is permissible for a user to have (add-hook > 'temp-buffer-setup-hook 'fancy-help-mode t) >=20 > The more important reason is we have variants of those macros and it is > time to consolidate them. I'll find time to do that. Sorry just came > back from a break and it has been very busy lately. But I'll get to it > soon. Please don't. The last go-round of such "consolidation" is how we got into the current mess. Please see my original report of the problem and my suggestion for fixing it. You can start with the URL above. The solution to the (minor) problem that "temp" was really about "help" and there was nothing for temporary buffers *without* help-mode should have been (as originally suggested) to: (1) rename the "temp" macro (`with-output-to-temp-buffer') while keeping the old name as an alias AND (2) create a new macro that really is for temporary buffers (without any help-mode stuff). What we got instead was a new macro for help (good) and a blind removal of the help-mode stuff from the existing "temp" macro (bad!). That requires every existing use of `with-output-to-temp-buffer' to be revisited and adjusted to use the new help macro (or not, rarely) instead. Worse: For code that needs to work with multiple Emacs versions, it also means adding an ugly workaround or two. Something like this, for instance, substituting it for (existing occurrences of the old) `with-output-to-temp-buffer': (defmacro my-kludgy-with-help-window (buffer &rest body) "`with-help-window', if available; else `with-output-to-temp-buffer'." (if (fboundp 'with-help-window) `(with-help-window ,buffer ,@body) `(with-output-to-temp-buffer ,buffer ,@body))) Of course, wholesale replacement by such a macro would not deal directly or correctly with existing occurrences of `with-output-to-temp-buffer' where there was accompanying code that=20 removed/inhibited the help-mode stuff (i.e., that tried to treat it as really just a temporary buffer). Whatever the workaround, each occurrence of `with-output-to-temp-buffer' really needs to be checked to see what TRT to do is. It's hard for me to believe that (a) things were "fixed" the way they were and (b) that it has taken so long for someone besides me to speak up about DTRT (thank you, Glenn). FWIW: I have great respect for Martin's work. This time, for whatever reasons, and whatever combination of fixers was responsible for the state we're in now, things have not turned out so well. To me, the right solution is still the same: (a) revert the changes to `with-output-to-temp-buffer' and (b) keep the changes to the Emacs code that use the fine new macro (`with-help-window'). In addition, to address the original problem I reported, (c) create a new macro with `temp' in the name, which does no help-mode stuff - it would do essentially what the current (i.e., changed) `with-output-to-temp-buffer' does, and (d) alias `with-output-to-temp-buffer' to `with-help-window' and deprecate `with-output-to-temp-buffer'. The change for the last paragraph, (c) and (d), is *not* urgent. It is essentially a nice-to-have, to end up with "temp" meaning only temporary (not also help) and "help" meaning help. But (a) and (b) should be done now (before Emacs 24.4), to bring some sanity back. Those of us who have already adjusted our code to fit the new mess will just have to unadjust it.