From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: undo weirdness with insert-file-contents Date: Sun, 02 Mar 2008 21:15:27 -0500 Message-ID: References: <47C70CFC.30203@gmx.at> <47C88A51.7020205@gmx.at> <47CAA13E.3040909@gmx.at> <47CB2498.1030405@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204510629 8749 80.91.229.12 (3 Mar 2008 02:17:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Mar 2008 02:17:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 03 03:17:36 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 1JW0FA-0006Uw-26 for ged-emacs-devel@m.gmane.org; Mon, 03 Mar 2008 03:17:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JW0Ec-00040z-3V for ged-emacs-devel@m.gmane.org; Sun, 02 Mar 2008 21:16:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JW0DC-0002qE-NZ for emacs-devel@gnu.org; Sun, 02 Mar 2008 21:15:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JW0DA-0002ne-QK for emacs-devel@gnu.org; Sun, 02 Mar 2008 21:15:30 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JW0DA-0002nN-Ie for emacs-devel@gnu.org; Sun, 02 Mar 2008 21:15:28 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JW0DA-0007Am-9r for emacs-devel@gnu.org; Sun, 02 Mar 2008 21:15:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC/uykfO+LKX/2dsb2JhbACrQIEA X-IronPort-AV: E=Sophos;i="4.25,435,1199682000"; d="scan'208";a="15470256" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 02 Mar 2008 21:15:27 -0500 Original-Received: from pastel.home ([206.248.178.151]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id JFS45027; Sun, 02 Mar 2008 21:15:27 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 482668279; Sun, 2 Mar 2008 21:15:27 -0500 (EST) In-Reply-To: <47CB2498.1030405@gmx.at> (martin rudalics's message of "Sun, 02 Mar 2008 23:05:12 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) 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:91140 Archived-At: >> What does that mean? Are you going to mark the buffer as modified? > Where do I mark a buffer as modified? I don't know. I just got the impression that your code might cause this to happen. If it doesn't happen, that's great. > What I propose is to insert a "first change" element in the undo list. > Is it that what you mean? I'm only asking about the impact of your change, not the way it works. >> Normally record_first_change is called "automatically" elsewhere. >> So why is it needed here? > Because it's _not_ done elsewhere. Currently it's done at 3 places: record_property_change, record_point (both of them are in undo.c) and modify_region in insdel.c. And record_point is called from record_insert. So normally it all happens "automatically". >> 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. When visiting a file, insert-file-contents is called from some other piece of elisp which is the one that should take care of setting up the undo-list and the unmodified status. It shouldn't be insert-file-contents's job. > 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. I understand this part, but it seems there's got to be a simpler way. BTW, rather than use an undo-boundary, we could simply store the old undo-list in some local var, then set undo-list to nil, then do the dance, then nconc the new undo-list and the old undo-list. Setting the undo-list to nil temporarily hides the previous undo-list, thus preventing merging entries. >> 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. Or rather create a new insert-file-contents-1 which doesn't take any `visit' argument. Stefan