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: insert-file-contents and format-decode Date: Sun, 24 Jun 2007 12:30:07 +0200 Message-ID: <467E47AF.1080702@gmx.at> References: <4666BF5F.5030301@gmx.at> <46753850.2090708@gmx.at> <46778ACB.1000704@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1182681053 11094 80.91.229.12 (24 Jun 2007 10:30:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Jun 2007 10:30:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 24 12:30:52 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 1I2PMq-0004wm-07 for ged-emacs-devel@m.gmane.org; Sun, 24 Jun 2007 12:30:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2PMp-0005QN-9V for ged-emacs-devel@m.gmane.org; Sun, 24 Jun 2007 06:30:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2PMl-0005Q5-JD for emacs-devel@gnu.org; Sun, 24 Jun 2007 06:30:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2PMl-0005Pn-36 for emacs-devel@gnu.org; Sun, 24 Jun 2007 06:30:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2PMk-0005Pj-VM for emacs-devel@gnu.org; Sun, 24 Jun 2007 06:30:47 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1I2PMj-0004YR-8W for emacs-devel@gnu.org; Sun, 24 Jun 2007 06:30:46 -0400 Original-Received: (qmail invoked by alias); 24 Jun 2007 10:30:43 -0000 Original-Received: from N869P007.adsl.highway.telekom.at (EHLO [62.47.52.135]) [62.47.52.135] by mail.gmx.net (mp053) with SMTP; 24 Jun 2007 12:30:43 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18SiZldDuQSzah1VIOsah07SCF4i8yVAXOBJr2LUm 5UNjeaR6wMjp0s User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: X-Y-GMX-Trusted: 0 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:73746 Archived-At: > (1) The `format-decode' ("round-trip" as the new Elisp manual entry > calls them) based functions are Lisp functions, may change the buffer, > and may call the after-change functions for what they do. They precede, > within `insert-file-contents', the after-change-functions call. > > That sounds like a bug to me. I guess signal_after_change > should be done before `format-decode'. > > Does anyone disagree? `format-decode' is similar to character decoding and eol conversion. We don't run `after-change-functions' for decoding characters or converting line ends. > Can you test such a change? It would have to be tested against the `after-change-functions' of many major and minor modes (which holds for testing the present behavior as well). > (2) Calling `after-change-functions' from within `format-decode' or > `after-insert-file-functions' seems to me highly risky. Personally, I'd > never trust any of them if they don't use `inhibit-modification-hooks'. > > I won't say you are wrong, but I don't see why that would be so. > Can you explain? People who write after-change functions usually don't think in terms of raw text. They think in terms of fully decoded buffer text. > (3) Not calling `after-change-functions' after performing all functions > in `after-insert-file-functions' may mean, for example, not executing > `font-lock-after-change-function' after inserting the contents of some > file in the current buffer. > > No, because if `after-insert-file-functions' change the buffer, > the primitives they use will themselves call signal_after_change. Then we must tell people to not inhibit such hooks while running the primitives. An aside: `format-decode' has (let ((mod (buffer-modified-p)) ... ;; Don't record undo information for the decoding. ... (set-buffer-modified-p mod)) hence it does not change the buffer-modified state. It's somehow unnatural to run `after-change-functions' and keep the buffer-modified state unchanged at the same time. The comment about not recording undo information suggests that someone has been considering (but not implementing) this. If it's implemented it would probably have to be done as in `after-insert-file-set-coding' (very tedious). And we'd have to decide and document how `after-insert-file-functions' shall handle this. If it's not implemented, `undo' may reveal the raw file contents which seems worse.