From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17109: 24.4.50; REGRESSION: `with-output-to-temp-buffer' is broken Date: Wed, 26 Mar 2014 18:52:54 -0700 (PDT) Message-ID: References: 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 1395885255 15015 80.91.229.3 (27 Mar 2014 01:54:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Mar 2014 01:54:15 +0000 (UTC) Cc: 17109@debbugs.gnu.org To: Leo Liu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 27 02:54:23 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WSzWR-00037e-A3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Mar 2014 02:54:23 +0100 Original-Received: from localhost ([::1]:51163 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSzWQ-0000HZ-PV for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Mar 2014 21:54:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSzWF-00009B-4E for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2014 21:54:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WSzW6-0007yO-GZ for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2014 21:54:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSzW6-0007yK-D1 for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2014 21:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WSzW5-0002Z8-Lw for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2014 21:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Mar 2014 01:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17109 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17109-submit@debbugs.gnu.org id=B17109.13958851839780 (code B ref 17109); Thu, 27 Mar 2014 01:54:01 +0000 Original-Received: (at 17109) by debbugs.gnu.org; 27 Mar 2014 01:53:03 +0000 Original-Received: from localhost ([127.0.0.1]:51548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WSzV8-0002Xf-Jy for submit@debbugs.gnu.org; Wed, 26 Mar 2014 21:53:03 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:44109) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WSzV4-0002XB-7p for 17109@debbugs.gnu.org; Wed, 26 Mar 2014 21:52:59 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2R1quFa029311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 01:52:57 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2R1qtal015478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2014 01:52:55 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2R1qtvO028659; Thu, 27 Mar 2014 01:52:55 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:87436 Archived-At: > > In a build as recent as this one there was no such problem: >=20 > See bug#16038 on why with-output-to-temp-buffer is no longer=20 > associated with help mode. You can use any major mode. It should still be associated with help mode. That's how you preserve its behavior. If you want to give it additional, alternative, optional behavior then add that, but do not change the default behavior. It has been "associated with help mode" for 30 years. That's what it does. That's what it's for (yes, in spite of its poor name). Please revert this incompatible change. >From your own post to the #16038 thread: "We are trying to consolidate the features of the two macros into one so no feature is lost." ^^^^^^^^^^^^^^^^^^^^^ Well bug #17109 shows that you've changed `with-output-to-temp-buffer' in an incompatible way, which contradicts your claim of not losing its behavior. If you want new, incompatible behavior, come up with a different, new macro. Why screw `with-output-to-temp-buffer'? There is no reason to change its behavior - ESPECIALLY if you want to eventually make it obsolete. This just gets worse and worse. Emacs has already added `with-help-window'. Fine. Add another one if you need it. But why must you mess with existing behavior like this? Create as many new functions and macros as you like, but do you need to be introducing incompatible behavior changes like this to existing functions & macros? Martin said: "`with-help-window' does some things differently which I could not put into `with-output-to-temp-buffer' due to compatibility issues." And so what has now happened to this precious `with-output-to-temp-buffer' compatibility? Out the window! You persisted: "The more interesting question is is it possible to merge these two macros?" That is not "the more interesting question". Just misguided. In the #16038 thread, I said, "Incorporate whatever you feel you need to into `with-output-to-temp-buffer', as long as "no feature is lost" from it." And now it is broken. What should have happened, to start with, is to fix bug #8368. And you have still NOT deprecated `with-output-to-temp-buffer'. As I said in the #16038 thread: If `with-output-to-temp-buffer' is deprecated, we should learn in the NEWS that this is the case AND what it is replaced by. IOW, tell users how to update their code. Likewise for the misnamed hooks etc. Instead, at least so far, NEWS has only this:=20 *** New macro `with-temp-buffer-window', similar to `with-output-to-temp-buffer'. And I said: If `with-temp-buffer-window' is supposed to be the replacement for `with-output-to-temp-buffer' then that needs to be stated clearly in the NEWS. Including a spec of what the replacement should be for different `with-output-to-temp-buffer' input patterns (formal parameters). And including hook use (correspondences). With any significant differences and limitations pointed out. That is how to help users transition from the old to the new. I imagine that you are well aware of that, but it's perhaps better not to guess. And: What `with-output-to-temp-buffer' patterns map to what `with-temp-buffer-window' patterns? What about the various hooks? So you feel fine just breaking the behavior of `with-output-to-temp-buffer' and not deprecating it. And not telling users how to get the equivalent of the old behavior, IOW how to fix their code that you've now broken by changing what `with-output-to-temp-buffer' does. This is madness. Leave `with-output-to-temp-buffer' alone. Use new code however you like. But don't gratuitously break the old code that you want to eventually make obsolete. Can you imagine if a company did that to paying customers with existing code? Emacs users don't pay you for their software, but that shouldn't make you feel free to screw them and just make gratuitous changes willy nilly.