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#17397: 24.4.50; REGRESSION: `temp-buffer-show-hook' is no longer invoked for `describe-variable' Date: Thu, 15 May 2014 07:02:23 -0700 (PDT) Message-ID: <934fdf6d-ae95-4d87-a303-ea2bf340e3d2@default> 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> 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 1400162617 1262 80.91.229.3 (15 May 2014 14:03:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 May 2014 14:03:37 +0000 (UTC) To: martin rudalics , 17397@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 15 16:03:30 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 1WkwFp-0007uX-Ns for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 May 2014 16:03:25 +0200 Original-Received: from localhost ([::1]:58283 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkwFn-0006zW-Aj for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 May 2014 10:03:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkwFc-0006zF-0a for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 10:03:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkwFT-0005Bn-86 for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 10:03:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkwFT-0005Bf-5D for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 10:03:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WkwFS-0003yc-Gi for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 10:03:02 -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, 15 May 2014 14:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17397 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17397-submit@debbugs.gnu.org id=B17397.140016255915255 (code B ref 17397); Thu, 15 May 2014 14:03:02 +0000 Original-Received: (at 17397) by debbugs.gnu.org; 15 May 2014 14:02:39 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:89128 Archived-At: > >> 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).