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: Mon, 03 Mar 2008 16:03:43 -0500 Message-ID: References: <47C70CFC.30203@gmx.at> <47C88A51.7020205@gmx.at> <47CAA13E.3040909@gmx.at> <47CB2498.1030405@gmx.at> <47CBC035.7030006@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204578238 7948 80.91.229.12 (3 Mar 2008 21:03:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Mar 2008 21:03:58 +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 22:04:24 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 1JWHpf-0005Z2-DW for ged-emacs-devel@m.gmane.org; Mon, 03 Mar 2008 22:04:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JWHp8-0005wY-6t for ged-emacs-devel@m.gmane.org; Mon, 03 Mar 2008 16:03:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JWHp4-0005wJ-RS for emacs-devel@gnu.org; Mon, 03 Mar 2008 16:03:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JWHp3-0005w7-B4 for emacs-devel@gnu.org; Mon, 03 Mar 2008 16:03:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JWHp3-0005w4-70 for emacs-devel@gnu.org; Mon, 03 Mar 2008 16:03:45 -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 1JWHp2-0003Er-VJ for emacs-devel@gnu.org; Mon, 03 Mar 2008 16:03:45 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAz3y0fO+LKX/2dsb2JhbACtcYEA X-IronPort-AV: E=Sophos;i="4.25,439,1199682000"; d="scan'208";a="15513531" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 03 Mar 2008 16:03:44 -0500 Original-Received: from pastel.home ([206.248.178.151]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id JYG08244; Mon, 03 Mar 2008 16:03:44 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id C4F058279; Mon, 3 Mar 2008 16:03:43 -0500 (EST) In-Reply-To: <47CBC035.7030006@gmx.at> (martin rudalics's message of "Mon, 03 Mar 2008 10:09:09 +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:91220 Archived-At: > I always wondered whether the REPLACE thingy could have been implemented > easier by comparing the region around `point' before and after the > replacement. Many routines apply such heuristics (bookmarks, etags, > diff related programs). See my wishlist item in the emacsbugs page ;-) >>> 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, > ... dancing with undo enabled? >> 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. > But _all_ we really need are the beginning and end of the inserted text. > We can get them easily with undo recording turned off during decoding - > once the problems with VISIT and REPLACE have been resolved. Good, point so we just turn off undo during the dance and then insert the single undo-element (this is only valid for non-REPLACE, of course). >> Or rather create a new insert-file-contents-1 which doesn't take any >> `visit' argument. > ... but a REPLACE argument, I suppose. See the example with BEG and > REALBEG above: Undo from BEG or REALBEG? The undo-list should record the finer description of the change. Stefan