From: phillip.lord@newcastle.ac.uk (Phillip Lord)
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Emacs-Devel devel <emacs-devel@gnu.org>
Subject: Re: disabling undo boundaries
Date: Thu, 06 Aug 2015 22:02:59 +0100 [thread overview]
Message-ID: <8737zwyvss.fsf@newcastle.ac.uk> (raw)
In-Reply-To: <87y4hrm911.fsf@newcastle.ac.uk> (Phillip Lord's message of "Tue, 4 Aug 2015 15:18:50 +0100")
Phillip Lord <phillip.lord@newcastle.ac.uk> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Actually, I have been thinking about this. What I worry about with this
>>> is that we may be adding the same form of heuristic into undo.c as the
>>> "insert an undo-boundary if the buffer has changed".
>>
>> Yes, because we do want this to happen, pretty much always (having
>> changes accumulate without intervening boundary is actually a problem
>> that can lead to nasty behaviors).
>>
>> There are exceptions, but they're rare.
>
>
> Sorry for late reply -- been travelling.
>
> The heuristic I was refering to is the "insert an undo-boundary if the
> current-buffer has changed". Or, rather, insert an undo-boundary if some
> *other* buffer has changed.
>
> 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. In most cases, this is irrelevant and doesn't happen anyway, and
> where you have a p-c-h or a-c-f it changes undo behaviour. I worry that
> I am missing a good reason for this behaviour, but I have thought about
> it and failed to come up with a reason; negative conclusions are always
> worrisome, but what else can you do?
>
> I'll write a patch to trunk and send it in, once my life has caught up,
> then I can happily pass the buck of making the final decision to you:-)
I have added the change that I am suggesting to:
fix/no-undo-boundary-on-secondary-buffer-change
The change simplifies undo.c somewhat. I can see no reason for the
existing logic, and it is has extremely counter-intuitive consequences
when using as discussed when using post-c-h or a-c-f.
But clearly it also changes some deep (and old!) logic in undo.c. So,
making this my first commit to trunk would clearly be reckless.
Let me know what you think. If you are unhappy, I will drop the idea
entirely and delete the branch. If you are happy, I will leave you to
merge/rebase as you choose. If you don't like my commit message grammar,
I can fix and squash on a branch!
Cheers
Phil
next prev parent reply other threads:[~2015-08-06 21:02 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 [this message]
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
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=8737zwyvss.fsf@newcastle.ac.uk \
--to=phillip.lord@newcastle.ac.uk \
--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).