From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: disabling undo boundaries Date: Sat, 08 Aug 2015 10:58:56 +0100 Message-ID: <87a8u25cf3.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <87siaxk4dl.fsf@newcastle.ac.uk> <87iobsr6m2.fsf@newcastle.ac.uk> <87oalgaicm.fsf@newcastle.ac.uk> <87y4kkkzlo.fsf@newcastle.ac.uk> <87mw0zk7yp.fsf@newcastle.ac.uk> <87617mgp1b.fsf@newcastle.ac.uk> <871ti9ammc.fsf@newcastle.ac.uk> <878ucaqm3g.fsf@newcastle.ac.uk> <87y4hrm911.fsf@newcastle.ac.uk> <87wpx79pz6.fsf@newcastle.ac.uk> <874mkbjj2u.fsf@fencepost.gnu.org> <87egjehkk7.fsf@newcastle.ac.uk> <87si7uibji.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439027960 10956 80.91.229.3 (8 Aug 2015 09:59:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Aug 2015 09:59:20 +0000 (UTC) Cc: Stefan Monnier , Emacs-Devel devel To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 08 11:59:10 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZO0uE-0003XN-2P for ged-emacs-devel@m.gmane.org; Sat, 08 Aug 2015 11:59:10 +0200 Original-Received: from localhost ([::1]:52412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO0uD-00043h-2U for ged-emacs-devel@m.gmane.org; Sat, 08 Aug 2015 05:59:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO0u9-00043b-MU for emacs-devel@gnu.org; Sat, 08 Aug 2015 05:59:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZO0u8-0004VO-DZ for emacs-devel@gnu.org; Sat, 08 Aug 2015 05:59:05 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:44472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO0u3-0004T0-Lm; Sat, 08 Aug 2015 05:58:59 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1ZO0u2-0000BM-AR; Sat, 08 Aug 2015 10:58:58 +0100 Original-Received: from cpc6-benw10-2-0-cust45.gate.cable.virginm.net ([92.238.179.46] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZO0u1-0001Jb-Ry; Sat, 08 Aug 2015 10:58:57 +0100 In-Reply-To: <87si7uibji.fsf@fencepost.gnu.org> (David Kastrup's message of "Sat, 8 Aug 2015 07:39:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188604 Archived-At: David Kastrup writes: > phillip.lord@newcastle.ac.uk (Phillip Lord) writes: > >> David Kastrup writes: >>> >>> The problem _I_ see is that it is in general not just "a command" which >>> may touch another buffer, but also compilation buffers, timer events, >>> font lock and a number of other background activities not immediately >>> caused by key presses. >> >> >> I don't think this is an issue, because Emacs is single-threaded. So, >> all of these events happen *between* commands which, in general, means >> that an undo-boundary has gone onto the current-buffer anyway. > > Not for self-insert-command. Not for stuff like shell-command-on-region > that has to wait for material to arrive. I thought shell-command-on-region still arrives between commands, but I have not looked at the code. You are more likely to be correct than I. My feeling is that my patch is likely to remove problems caused by asynchronicity rather than cause it. The logic is simpler and undo boundaries are not added based on something that has happened in the past. Phil