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, 21 May 2015 18:03:55 +0100 [thread overview]
Message-ID: <871ti9ammc.fsf@newcastle.ac.uk> (raw)
In-Reply-To: <jwvlhgigd97.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 21 May 2015 11:44:47 -0400")
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Yes, you are right, the second buffer is an issue, although I am not
>> convinced that the behaviour is worse.
>
> Worse than the ideal or worse than the current one?
The current situation.
> Right now, I'm trying to understand what the ideal behavior should be.
I don't have a clear handle on this either.
For my two use cases, with noisy-change-log, I think the answer is, I
don't really care. I don't need undo in a log buffer, and if I had
thought about it, I would have switched it off.
For lentic, I would like the undo-boundaries to be what they would have
been if the commands had been typed manually.
> After that, we can try to figure out how to get this ideal behavior, or
> how close we can get to it, and which part of the work can be made
> generic in undo.c and which part of the work has to be done manually by
> each and every particular command/package.
That would be good.
Another package worth looking at would be gnus, which AFAICT,
reimplements undo all for itself, to cope with the fact that it's a
multi buffer sort of package.
>> ** Conclusion
>> All of the insertion events have been amalgamated, so the undo is much
>> too "lumpy". Again, I can add this logic in, but I have to duplicate
>> the "add an undo-boundary after a command" logic from the
>> command loop.
>
> [ You only used self-insert-command in your examples, which gives
> a slightly twisted view of what's going on in general. ]
>
> But ideally, we could have undo.c do most of that for you.
> E.g. instead of adding a boundary every time we switch buffer, undo.c
> could simply keep track of which buffers have seen changes during the
> current command, and then push undo-boundaries on all of them at the end
> of the command.
Yeah, thought about that and that would get me most of the way there.
I think that should not affect *shell* buffers or equivalent right? They
actually only update outside of the command loop, so can't have changed
in the middle?
> Except for self-insert-command, I think this would give you the ideal
> behavior (without any manual work on your side) *and* it would mostly
> preserve the existing behavior.
>
> For self-insert-command, it's more tricky, and you'd probably need to do
> the extra manual work. E.g. add a post-self-insert-hook which checks if
> this self-insert-command removed the previous undo-boundary and then
> remove it as well in the sibling buffer. I can't see how undo.c could
> do that for you magically, since it doesn't know that the insertions in
> the sibling buffer are "clones" of the insertions in the main buffer,
> nor that it's done by self-insert-command.
I'd agree with this. One possibility would be to have an undo-boundary
command which is implements the same sort of "20 steps" logic as
self-insert-command. But, even that is going to be hard, since there can
be more changes in *that* buffer than in *this* (the two are not
necessarily exactly the same).
I think this would all be a little easier if buffer-undo-list didn't use
"nil" but allowed the developer to differentiate between different kinds
of boundary.
> Another approach would be for you to arrange such that your a-f-c uses
> self-insert-command rather than `insert' when cloning the insertion
> from a self-insert-command, but that's probably just as hard if not
> harder.
That doesn't sound great to me either, as I have to behave quite
differently depending on the last-command.
It seems to me, that you are not adverse to the idea of changing undo.c
to stop it putting boundaries in. Can I suggest a way forward? I will
carry on with my hacked Emacs with removed undo-boundaries in undo.c. I
can add the "undo-boundary to all changed buffers" using
post-command-hook. This will let me test everything makes sense and
works as expected, and I don't mind spending the effort, if emacs will
support it later.
If you are prepared to implement the "add an undo-boundary to every
buffer thats changed" logic into undo.c/cmd.c, then we can do that once
the logic works. I would be willing to help with that, but my C
programming is very poor, and in practice, I'm likely to learn more than
I actually help.
Phil
next prev parent reply other threads:[~2015-05-21 17:03 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871ti9ammc.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.