unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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




  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).