From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: with-output-to-temp-buffer and help-mode Date: Sat, 26 Jul 2014 11:00:19 +0200 Message-ID: <53D36E23.8060409@gmx.at> References: <1yppgtua5n.fsf@fencepost.gnu.org> <61a1087c-3e21-46df-a12c-22dce14e82b1@default> <87a97worge.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1406365265 11592 80.91.229.3 (26 Jul 2014 09:01:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jul 2014 09:01:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 26 11:00:58 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 1XAxqb-000127-Vl for ged-emacs-devel@m.gmane.org; Sat, 26 Jul 2014 11:00:58 +0200 Original-Received: from localhost ([::1]:58274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAxqb-00073V-Mx for ged-emacs-devel@m.gmane.org; Sat, 26 Jul 2014 05:00:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAxqR-00073L-N0 for emacs-devel@gnu.org; Sat, 26 Jul 2014 05:00:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XAxqK-0005ln-6J for emacs-devel@gnu.org; Sat, 26 Jul 2014 05:00:47 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:50974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAxqJ-0005lO-MH for emacs-devel@gnu.org; Sat, 26 Jul 2014 05:00:40 -0400 Original-Received: from [91.113.1.112] ([91.113.1.112]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M4GRv-1WJPY421aN-00rsli; Sat, 26 Jul 2014 11:00:31 +0200 In-Reply-To: <87a97worge.fsf@uwakimon.sk.tsukuba.ac.jp> X-Provags-ID: V03:K0:7RWoW/XAT7C8q0sQbj0McVl5vemDzU3FQm/cLGkws7DJgviz5hs dLhbTbeNGRbSUDMnEMYrZlSM9vQk1ZMDHgWEENujkhuoUD8ENvbouUkLx2xWP92cPqhDtkh eMT3kZpBsCzwTyXhl78QWUWbJODbAUS+he1xnfIgQ9LY25LBJCtEBamLO3wh6z5620J5pKU OCX1lNgDWjrk4cAwzlG4w== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.15.19 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:173166 Archived-At: The following annotations serve only to clarify some issues. I have no opinion on how to proceed in this matter. > 1. The "traditional" implementation of `with-output-to-temp-buffer' > provides (by default, and without option) many features to support > help-mode. (Fact: nobody argues with this.) It provided only one such feature - an explicit call to `help-mode' within `temp-buffer-setup-hook'. Richard once explained that he used a hook on purpose to make this feature optional. Also, there is no "traditional" semantics of this macro. Most features have been added over time and you usually could tell from functions using this macro whether a feature already existed at the time the function was written. > 3. The argument does not depend at all on the existence or frequency > of use cases that don't use the help features. It did for me since otherwise I would never have bothered about this issue. It only later occurred to me that people cared about cosmetic issues only. > 5. The strategy to deal with this (provide a new alias indicating the > traditional semantics properly, and a new function with an > appropriate name to indicate the non-help semantics) is > well-known, is well-known to have worked well in similar > circumstances, and should be adopted here, too. > We even know *why* it works well: because of (3), only new code > has need for the new function, and in new code it's almost as easy > to use a function with a new name as the documentation for the > "obvious" name will indicate that it's a backward compatibility > kludge. There is no such strategy. Most options of `with-output-to-temp-buffer' have been implemented with the help of hooks and hooks can be changed by the application and/or the user. The new macro can now either run the same hooks as `with-output-to-temp-buffer' in which case it will run into precisely the same problems (like turning on `help-mode') or run different hooks in which case users or developers will complain that the functions they use to put on the hooks of `with-output-to-temp-buffer' are not run any more (as happened with `with-help-window'). martin