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: [Emacs-diffs] /srv/bzr/emacs/trunk r103854: Reimplementlist-processes in Lisp. Date: Thu, 7 Apr 2011 10:00:47 -0700 Message-ID: <3020B91746414BA38A14779DD133543B@us.oracle.com> References: <87zko2rj4f.fsf@stupidchicken.com><769DFAFA380F4178A5E5CCC2DCDADAC0@us.oracle.com> <87ipuqf3xe.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1302195671 3365 80.91.229.12 (7 Apr 2011 17:01:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 7 Apr 2011 17:01:11 +0000 (UTC) Cc: 'Emacs developers' To: "'Chong Yidong'" , "'Juanma Barranquero'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 07 19:01:07 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q7sZp-0003X9-Bj for ged-emacs-devel@m.gmane.org; Thu, 07 Apr 2011 19:01:01 +0200 Original-Received: from localhost ([127.0.0.1]:34920 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q7sZo-00026m-Eq for ged-emacs-devel@m.gmane.org; Thu, 07 Apr 2011 13:01:00 -0400 Original-Received: from [140.186.70.92] (port=41183 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q7sZj-00026a-8d for emacs-devel@gnu.org; Thu, 07 Apr 2011 13:00:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q7sZh-0004IU-Nl for emacs-devel@gnu.org; Thu, 07 Apr 2011 13:00:55 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:31549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q7sZh-0004IQ-E4 for emacs-devel@gnu.org; Thu, 07 Apr 2011 13:00:53 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p37H0nZb015938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2011 17:00:50 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p37H0lYG008287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 17:00:48 GMT Original-Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p37H0lOY028008; Thu, 7 Apr 2011 12:00:47 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Apr 2011 10:00:47 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ipuqf3xe.fsf@stupidchicken.com> Thread-Index: Acv1PMhyaWVkiHr8ReKClAlAvdFKJQABP1SQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D9DEDC0.00C1:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.87.113.121 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138285 Archived-At: > > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8368 > > > > Thanks, I had forgotten that report. > > > > I basically agree with the first part, i.e., that it's a mistake to > > assume any relationship between temporary and help. > > Now that we have with-help-window (added by Martin Rudalics > in 2007), it makes sense to put help-mode-setup and > help-mode-finish there, rather than applying them to all > with-output-to-temp-buffer calls. > > Some uses of temp_output_buffer_setup in the C code may need > to be fixed to call help-mode-* explicitly, but that should be easy. > > As for temp-buffer-setup-hook itself, maybe we should deprecate it. Please be careful in this regard. The use of help stuff for "temporary" buffers is now quite old. Lots of code out there expects it. As I mentioned in the bug #8368 report, I'd suggest just aliasing to rename `*-temp-*' to `*-help-*', and then creating a separate, _real_ temporary buffer functionality that would not involve anything help- or completion-related. IOW, just call things as they really are, but don't change or get rid of any functionality. From that moment on, users would see and use `*-help-*' where they used to use `*-temp-*', and any old code with `*-temp-*' references would still work the same. The new, real temporary-buffer stuff would have a different name (e.g. `*-temporary-*') so there would be no ambiguity or conflict. Deprecating the hook would be unwise, IMO. It is used by 3rd-party code, if not by vanilla Emacs code. It should simply be renamed to `help-buffer-setup-hook' and be run exactly as it is today (in the renamed `with-output-to-temp-buffer', aka `with-output-to-help-buffer'). No changes in functionality. No surprises. Just make the names and the doc make better sense from now on. > (The name is confusing, since with-temp-buffer does not run it when > setting up the buffer.) (I think you meant `with-output-to-temp-buffer'?) Depends what you mean by "setting up". It is run just after erasing the buffer. Seems like pretty much the moment of buffer setup, to me. > AFAICT, anything you put in the hook can be accomplished > equivalently using the with-output-to-temp-buffer body Hooks can be bound (dynamically), changing code behavior. Sure, you can put a function variable into the body, to get a similar effect, but that's essentially using a hook! Anyway, what you say is true of lots of hooks: given access to the body they can be done without. There's nothing wrong with keeping this hook. And it is no doubt used in 3rd-party code. > (one difference is that the hook is run before rebinding > standard-output, but probably no one needs this). > So, with help-mode-setup moved out into > with-help-window, we can dispense with this hook. Why move it to something that has to do with a window (display)? Why move it anywhere? The only real problem (see the bug report) is the possible confusion over naming. > As for list-* commands not obeying temp-buffer-resize-mode, how about > adding a display-buffer-hook, renaming temp-buffer-resize-mode to > display-buffer-resize-mode (and moving it from help.el to window.el), > and making that mode act on all uses of display-buffer-hook? Then we > can probably either deprecate temp-buffer-show-hook or make > it an alias for display-buffer-hook. I don't see why you're thinking of doing all of this. What is the problem (problems?) you are trying to solve by this manoeuver?