From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: insert-file-contents and format-decode Date: Sat, 30 Jun 2007 20:30:29 -0400 Message-ID: References: <4666BF5F.5030301@gmx.at> <46753850.2090708@gmx.at> <46778ACB.1000704@gmx.at> <467E47AF.1080702@gmx.at> <4680B80E.5090709@gmx.at> <468204D8.8010700@gmx.at> <46863F67.20208@gmx.at> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1183249875 651 80.91.229.12 (1 Jul 2007 00:31:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2007 00:31:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 02:31:09 2007 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.50) id 1I4nLH-00088r-Qr for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2007 02:31:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I4nLH-0006QT-9R for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2007 20:31:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I4nKh-0005uk-3k for emacs-devel@gnu.org; Sat, 30 Jun 2007 20:30:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I4nKg-0005tq-HL for emacs-devel@gnu.org; Sat, 30 Jun 2007 20:30:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I4nKg-0005ta-7L for emacs-devel@gnu.org; Sat, 30 Jun 2007 20:30:30 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I4nKf-0002Pb-TL for emacs-devel@gnu.org; Sat, 30 Jun 2007 20:30:30 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1I4nKf-0002m7-JR; Sat, 30 Jun 2007 20:30:29 -0400 In-reply-to: <46863F67.20208@gmx.at> (message from martin rudalics on Sat, 30 Jun 2007 13:32:55 +0200) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:74077 Archived-At: > We have a plan for dealing with functions called by `format-decode'. We > do not have a plan yet for dealing with `after-insert-file-functions'. > Shall we treat functions there the same way we treat functions called by > `format-decode'? > > If it's good for one, it's probably good for the other. Consistency > between the two features is also good. > > Do you see any reason NOT to do so? We could introduce one: Keep `format-decode' for practical use and `after-insert-file-functions' for applications that want to fine-tune every single step of the decoding process. Incoherence is a minus, not a plus. If there is no specific reason to treat them differentlky, let's treat them the same! I already changed my mind: I now think instead that `format-decode' and `after-insert-file-functions' _should_ be able to detect whether the insertion is done at the beginning of the current buffer or any other position (simply by comparing the `begin' argument with `point-min' wthout any need to widen the buffer). If you think that's useful, then let's not insert a save-restriction. So the only remaining change to be done is to inhibit execution of certain hooks in `format-decode' and around the calls to `after-insert-file-functions'. Would you like to implement this?