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 12:06:33 -0700 (PDT) Message-ID: <61a1087c-3e21-46df-a12c-22dce14e82b1@default> 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 1406315235 7292 80.91.229.3 (25 Jul 2014 19:07:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jul 2014 19:07:15 +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 21:07:05 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 1XAkpZ-0001Xj-TX for ged-emacs-devel@m.gmane.org; Fri, 25 Jul 2014 21:07:02 +0200 Original-Received: from localhost ([::1]:56372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAkpZ-0003Z6-Dh for ged-emacs-devel@m.gmane.org; Fri, 25 Jul 2014 15:07:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAkpN-0003Yk-5c for emacs-devel@gnu.org; Fri, 25 Jul 2014 15:06:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XAkpD-0007Ng-K0 for emacs-devel@gnu.org; Fri, 25 Jul 2014 15:06:49 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:28861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAkpD-0007NG-Ds for emacs-devel@gnu.org; Fri, 25 Jul 2014 15:06:39 -0400 Original-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 s6PJ6avj002890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jul 2014 19:06:37 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6PJ6ZZb001859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 19:06:35 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6PJ6Y3r025457; Fri, 25 Jul 2014 19:06:34 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: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:173148 Archived-At: > > 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!). >=20 > You seem to believe with-output-to-temp-buffer is only about help mode. No. Please read what I wrote. I explicitly said:=20 1. >> 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. and even more explicitly: 2. >> 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. ^^^^^^^^^^^^^^^^^ I made it clear that (a) regardless of its unfortunate name, `with-output-to-temp-buffer' IS "about help mode" most of the time (the vast majority of occurrences). But (b) there are some (pretty rare) occurrences where the code jumped through some extra hoops to explicitly remove the imposition of help-mode. I have some of the latter in my own code, so I'm well aware that not all uses of `with-output-to-temp-buffer' used help mode. The point is that they needed to, in effect, prevent or undo the help-mode part (which was the largest part) of what `with-output-to-temp-buffer' did. > Now there are places in emacs that show otherwise, for example, check > display-completion-list. The doc says the macro runs > temp-buffer-setup-hook which normally sets up the buffer in help mode. > So entering help mode is the default behaviour but not the only one, > and the decision is up to the user. Please read the bug threads, and reread my message that you are replying to. And please do not confuse things by referring to what `with-output-to-temp-buffer' does now, as if the decision of whether it imposed help-mode was always "up to the user". Sure, it was up to the user in the sense that someone using it could jump through some extra hoops to remove the imposition of help-mode. That was not done often, as you surely know. That was the point of the original bug report I filed: the macro name says nothing about help mode but the behavior was to impose help mode, unless you took extra measures. To get just a temporary buffer without help mode you had to work at it (remove hooks etc.). The point of my original bug report was twofold: (a) we should have a simple macro to use a temporary buffer, without it having anything to do with help mode, and (b) we should have a macro to do what `with-output-to-temp-buffer' does (did): use a buffer in help mode. The first macro should have "temp" in its name and the second should have "help" in its name. The bad name `with-output-to-temp-buffer' needs to be continued as a defalias for the new help-mode macro, but it should be deprecated. That is very different from what has been done. Martin created `with-help-window', which is (b). Good. But you simply changed the behavior of `with-output-to-temp-buffer' to be (a). You removed its use of help mode without changing the name, breaking tons of existing code that uses it expecting help mode. All of this has been explained 8 zillion times now. If you don't get it then I don't know what more could help you understand. And if you do get it then I can only conclude that what you are saying is motivated by bad faith, as it contradicts reality.