unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: phillip.lord@newcastle.ac.uk (Phillip Lord)
To: David Kastrup <dak@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	Emacs-Devel devel <emacs-devel@gnu.org>
Subject: Re: disabling undo boundaries
Date: Fri, 07 Aug 2015 22:10:00 +0100	[thread overview]
Message-ID: <87egjehkk7.fsf@newcastle.ac.uk> (raw)
In-Reply-To: <874mkbjj2u.fsf@fencepost.gnu.org> (David Kastrup's message of "Fri, 7 Aug 2015 15:59:05 +0200")

David Kastrup <dak@gnu.org> writes:

> phillip.lord@newcastle.ac.uk (Phillip Lord) writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> I think that the current undo-boundary behaviour wrt a single buffer
>>>> makes sense. It's the fact that inserting content into *that* buffer
>>>> forces an undo-boundary into *this* buffer.  I don't know why Emacs
>>>> does this.
>>>
>>> I think the reason is not very deep: for reasons of efficiency (back in
>>> the days when 8MB was a lot of memory), Emacs keeps track of a few
>>> undo-related pieces of information in global variables, so it can only
>>> handle a single buffer at a time.  If a command touches some other
>>> buffer, the C code has to choose between "just switch" and "push
>>> a boundary and then switch", and the choice it makes is to err on the
>>> "safe" side of adding a potentially unnecessary undo-boundary rather
>>> than risking to let the undo-log grow without intervening boundaries.
>>
>>
>> I meant "deep" in the sense of "deep in version control history" -- or
>> in this case, before the version control system. Still, I didn't know
>> this was the reason.
>
> 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. So, they
don't break the undo behaviour in the current-buffer.

If it were not, the current semantics of Emacs undo would have been
shown to be problematic a long time ago.

As it stands (as I think I mentioned a long time ago!), I've checked how
often undo-boundaries are added by the current logic and the answer is
hardly ever. The code is almost entirely benign AFAICT, in that it never
runs. It just makes undo.c more complex than necessary, and is a total
disaster for my use case.

As always, it depends on what you do with Emacs and I may be missing
something where it is the right thing. I can't tell.

Phil



  reply	other threads:[~2015-08-07 21:10 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-10 21:43 disabling undo boundaries Phillip Lord
2015-05-11  1:42 ` Stefan Monnier
2015-05-11 11:46   ` Phillip Lord
2015-05-11 14:45     ` Stefan Monnier
2015-05-11 16:31       ` Phillip Lord
2015-05-11 19:30         ` Stefan Monnier
2015-05-11 20:42           ` Phillip Lord
2015-05-11 22:23             ` Stefan Monnier
2015-05-12 11:52               ` Phillip Lord
2015-05-12 20:15                 ` Stefan Monnier
2015-05-12 20:59                   ` Phillip Lord
2015-05-13 12:32                     ` Stefan Monnier
2015-05-13 15:40                       ` Phillip Lord
2015-05-14 15:28                         ` Stefan Monnier
2015-05-15 12:27                           ` Phillip Lord
2015-05-15 18:08                             ` Stefan Monnier
2015-05-15 19:49                               ` Phillip Lord
2015-05-15 23:45                                 ` Stefan Monnier
2015-05-16 13:31                                   ` Phillip Lord
2015-05-19 11:59                                     ` Phillip Lord
2015-05-19 19:42                                       ` Stefan Monnier
2015-05-19 21:48                                         ` Phillip Lord
2015-05-20  2:00                                           ` Stefan Monnier
2015-05-20  7:45                                             ` Phillip Lord
2015-05-20 12:53                                               ` Stefan Monnier
2015-05-21 11:15                                                 ` Phillip Lord
2015-05-21 15:44                                                   ` Stefan Monnier
2015-05-21 17:03                                                     ` Phillip Lord
2015-05-27 11:46                                                       ` Phillip Lord
2015-06-29  0:46                                                         ` Stefan Monnier
2015-08-04 14:18                                                           ` Phillip Lord
2015-08-06 21:02                                                             ` Phillip Lord
2015-08-06 22:20                                                             ` Stefan Monnier
2015-08-07 13:40                                                               ` Phillip Lord
2015-08-07 13:59                                                                 ` David Kastrup
2015-08-07 21:10                                                                   ` Phillip Lord [this message]
2015-08-08  5:39                                                                     ` David Kastrup
2015-08-08  9:58                                                                       ` Phillip Lord
2015-08-07 17:10                                                                 ` Stefan Monnier
2015-08-08 21:28                                                                   ` Stefan Monnier
2015-08-09 15:39                                                                     ` Phillip Lord
2015-08-09 16:30                                                                       ` Stefan Monnier
2015-08-09 16:50                                                                         ` Phillip Lord
2015-08-09 17:40                                                                           ` Stefan Monnier
2015-08-10  9:27                                                                             ` Phillip Lord
2015-08-10 21:21                                                                               ` Phillip Lord
2015-08-12 21:15                                                                               ` Stefan Monnier
2015-08-12 22:34                                                                                 ` Phillip Lord
2015-08-13  2:23                                                                                   ` Stefan Monnier
2015-08-21  9:40                                                                                     ` Phillip Lord
2015-08-07 23:49                                                     ` Davis Herring
2015-08-08 10:01                                                       ` Phillip Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87egjehkk7.fsf@newcastle.ac.uk \
    --to=phillip.lord@newcastle.ac.uk \
    --cc=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).