From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: recursive load case in openp Date: Thu, 11 Apr 2002 09:01:30 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200204111301.g3BD1VI30043@rum.cs.yale.edu> References: <200204102343.IAA06716@etlken.m17n.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018530265 2309 127.0.0.1 (11 Apr 2002 13:04:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 11 Apr 2002 13:04:25 +0000 (UTC) Cc: rms@gnu.org, eliz@is.elta.co.il, walters@debian.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16veFU-0000b8-00 for ; Thu, 11 Apr 2002 15:04:24 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16veUP-0000MX-00 for ; Thu, 11 Apr 2002 15:19:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16veED-0001WI-00; Thu, 11 Apr 2002 09:03:05 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16veCm-0001VB-00; Thu, 11 Apr 2002 09:01:36 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g3BD1VI30043; Thu, 11 Apr 2002 09:01:31 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Kenichi Handa Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2531 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2531 > Richard Stallman writes: > >> Why does encode_coding_string call > >> temp_output_buffer_setup? > > To run post-read-conversion and pre-write-conversion > > functions of a coding system. We must make a temporary > > working buffer for them. > > > I don't see anything like that in the code of > > temp_output_buffer_setup. What exactly in the code of > > temp_output_buffer_setup do you actually want to do here? > > Here's a copy of temp_output_buffer_setup. I just need > lines from Fset_buffer to Ferase_buffer (inclusive). I would argue that the `run-hooks' part of the function should be taken out. Typically, this hook contains help-mode-setup which is either not what we want (when the buffer is only used internally) or if it is what we want, it's not enough (we additionally need to call help-setup-xref). I've already removed most C calls to with-output-to-temp-buffer by moving the corresponding code to elisp. Currently temp_output_buffer_setup is called from bytecode.c, coding.c and fileio.c (where the calls obviously would rather have a temp_buffer_setup, with none of that Qtemp_buffer_setup_hook business) and from Fwith_output_to_temp_buffer which could be recoded in elisp anyway as well as internal_with_output_to_temp_buffer. This last one is still used for several things, so we won't be able to get rid of it immediately: - " *Danger*" in alloc.c (should this really run temp_buffer_setup_hook ?). - "*Backtrace*" in eval.c (only used when stack-trace-on-error is non-nil. Is this ever used ? It seems that debug-on-error makes it obsolete). - "*Help*" in keyboard.c for the help-form (I think this should be moved to elisp, but I'm not sure how). - "*Completions*" in minibuf.c (I have all this code recoded and improved in elisp. And I can't see why *Completions* should use help-mode-setup). - "*Process List*" in proicess.c (again, should this use help-mode ?). Of course, in the mean time we should just create temp_buffer_setup and have temp_output_buffer_setup call it. Stefan