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: undo weirdness with insert-file-contents Date: Sun, 02 Mar 2008 23:05:12 +0100 Message-ID: <47CB2498.1030405@gmx.at> References: <47C70CFC.30203@gmx.at> <47C88A51.7020205@gmx.at> <47CAA13E.3040909@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1204495616 4094 80.91.229.12 (2 Mar 2008 22:06:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Mar 2008 22:06:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 02 23:07:22 2008 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 1JVwL1-0002P5-ES for ged-emacs-devel@m.gmane.org; Sun, 02 Mar 2008 23:07:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVwKU-0004m5-KB for ged-emacs-devel@m.gmane.org; Sun, 02 Mar 2008 17:06:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JVwKQ-0004kb-7T for emacs-devel@gnu.org; Sun, 02 Mar 2008 17:06:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JVwKO-0004jS-MF for emacs-devel@gnu.org; Sun, 02 Mar 2008 17:06:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVwKO-0004jH-IS for emacs-devel@gnu.org; Sun, 02 Mar 2008 17:06:40 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JVwKN-0004ym-Tp for emacs-devel@gnu.org; Sun, 02 Mar 2008 17:06:40 -0500 Original-Received: (qmail invoked by alias); 02 Mar 2008 22:06:37 -0000 Original-Received: from N937P009.adsl.highway.telekom.at (EHLO [62.47.61.9]) [62.47.61.9] by mail.gmx.net (mp023) with SMTP; 02 Mar 2008 23:06:37 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX198eNkwcE98IMW1DR42mgnQYHZCzLSVLQNbW9x1D4 cjRJRaYbXZYlf6 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: by monty-python.gnu.org: Genre and OS details not recognized. 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:91110 Archived-At: >>the empty_undo_list check at all. BTW, what is the semantics of >>`insert-file-contents' with VISIT nil and REPLACE non-nil? > > It seems obvious to me that it's similar to "delete + insert". > So I guess I don't understand the question quite right. I use this kind > of call to insert-file-contents in smerge-resolve, if you want to see > an example. I asked because from reading the code I sometimes got the impression that REPLACE => VISIT. >>>Also if the file is empty, is this going to mark the buffer as modified >>>even though nothing was changed? > >>I'm afraid I don't understand the question - do you mean the case where >>inserted equals zero? > > Yes. > >>I don't handle that. > > What does that mean? Are you going to mark the buffer as modified? Where do I mark a buffer as modified? What I propose is to insert a "first change" element in the undo list. Is it that what you mean? > Normally record_first_change is called "automatically" elsewhere. > So why is it needed here? Because it's _not_ done elsewhere. > The handling of the undo-list and modified-p status in > insert-file-contents is a real mess. The main reason for the "mess" is that `insert-file-contents' has to reconcile visiting a file and inserting the contents of some file into an existing buffer. In the first case the buffer should appear unmodified and the undo-list empty after the insertion. In the second case the buffer should appear modified and the change recorded in the undo list. A second reason stems from the various decoding steps. Ideally, decoding should run transparently and only the "final" insertion get recorded. For this purpose you have to temporarily switch off undo recording in the non-visiting case. Otherwise, undoing changes could reveal changes done by the decoding routine as can be observed with Emacs 22. Moreover, recording changes during decoding might be expensive. Finally, functions called by `insert-file-contents', for example, `decode_coding' and `adjust_after_insert', may modify `buffer-undo-list' in some way or the other. > It'd be good to take a step back > and think about how it *should* work. E.g. I don't think > insert-file-contents should mess with modified-p: it should behave just > like a normal `insert' in this respect. Its doc-string says "If second argument VISIT is non-nil, the buffer's visited filename and last save file modtime are set, and it is marked unmodified." hence we would have to change that first. Maybe we could resolve these issues by renaming `insert-file-contents' to `insert-file-contents-1' and having a new `insert-file-contents' handle the undo list and the buffer-modified state while calling `insert-file-contents-1' with undo disabled.