From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: disabling undo boundaries Date: Mon, 10 Aug 2015 22:21:41 +0100 Message-ID: <87wpx2q1p6.fsf@russet.org.uk> References: <87fv746rd5.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> <87pp2wmpxy.fsf@russet.org.uk> <878u9kcsot.fsf@newcastle.ac.uk> <87vbcnh4sp.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439241732 22858 80.91.229.3 (10 Aug 2015 21:22:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2015 21:22:12 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 10 23:22:05 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 1ZOuWB-0002wm-SN for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2015 23:22:04 +0200 Original-Received: from localhost ([::1]:60182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOuWB-0001yu-28 for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2015 17:22:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOuVy-0001x5-GL for emacs-devel@gnu.org; Mon, 10 Aug 2015 17:21:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOuVv-0005IE-AU for emacs-devel@gnu.org; Mon, 10 Aug 2015 17:21:50 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:53495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOuVv-0005GD-48 for emacs-devel@gnu.org; Mon, 10 Aug 2015 17:21:47 -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 1ZOuVr-0001zQ-Bb; Mon, 10 Aug 2015 22:21:43 +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 1ZOuVr-000828-Ai; Mon, 10 Aug 2015 22:21:43 +0100 In-Reply-To: <87vbcnh4sp.fsf@russet.org.uk> (Phillip Lord's message of "Mon, 10 Aug 2015 10:27:18 +0100") 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:188709 Archived-At: Phillip Lord writes: > Stefan Monnier writes: > >>>>> I'm struggling with understanding this also. I've tried tracing when the >>>>> code my patch removes actually runs and it is pretty rarely. >>>> When you're editing buffer FOO while some process is inserting data in >>>> buffer BAR. >>> Okay. So, buffer BAR should get undo-boundaries when a command runs in >>> FOO? And FOO should get an undo-boundary when the process adds something >>> to BAR? >> >> The general goal is: add undo-boundaries often enough so the undo-log >> doesn't grow too large, both in FOO and in BAR, and ideally in ways >> which are somewhat predictable for the user. >> >> If you ask my ideal: FOO would get an undo-boundary after each command, >> and BAR would get an undo boundary after each N bytes inserted, or after >> every N seconds. > > My own feeling is that undo-boundaries should be the task of the mode > author, with sensible default behaviour (like the current one) for > user-centric modes (i.e. non process buffers). My guess is that most > buffers connected to non-interactive processes have undo switched off. > > As an alternative, why not handle this at GC? So, change the current > logic to "iff buffer undo-log is too large, and you have no > undo-boundaries, GC to 50% of length regardless". This addresses your > concern (overly long undo-logs, i.e. memory leaks) within the memory > management system, rather than in as a heuristic in a user system (i.e. > undo). Okay, to answer my own question, this *is* already handled at GC, with the undo-outer-limit logic. Not handled ideally -- undo-outer-limit is two orders greater than normal and the compaction function is noisy. But it should stop Emacs from memory leaking to crash. Phil