bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23906: 25.0.95; Undo boundary after process output is not consistent


From: Markus Triska
Subject: bug#23906: 25.0.95; Undo boundary after process output is not consistent
Date: Thu, 14 Jul 2016 10:34:57 +0200
User-agent: Emacs/24.4

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Emacs undo is already transactional in the sense that it inserts undo's
> between commands. If Emacs is doing stuff, running functions, and so
> forth, it will not add an undo boundary unless you tell it to. This is
> even true for the timer based boundaries, IIRC. Timers can only run in
> one point of the command loop.

In the case I posted, these atomic operations are too finely grained for
undo to revert all of them at once. I would like to state a transaction
over all commands that happen during the interaction with the process.

> This generalises the problem -- in this case, you are pretty much
> guaranteed to get an undo-boundary between "Sleeping..." and "Awake!"
> which you presumably want together.

Yes, exactly! These should be together.

> You can actually get this behaviour -- this patch achieves it.

Thank you for looking into this!

> Of course, this is pretty clunky and has global effect for the duration
> of the let binding. Also easy to get wrong (as I did first time I tried
> it).

I suppose in the first try, you forgot to cancel the scheduled timer in
addition to disabling its further invocation? As you mention, one
drawback of this is the global effect. And there's also another
drawback, which your example does not show: Please note that user input
can also happen during the interaction, for example, please try:

?- read(T).

and when asked, enter "test.":

?- read(T).
%@ |: test.
%@ 
%@ T = test.

Again, I want the whole interaction to be undone when pressing C-/, not
just up to the point the user was queried, i.e., after "|: ".

> But, if this is the behaviour you want, I think it can be added. I'll
> just add a new buffer-local variable to disable the effect of the timer
> (rather than the timer itself, as I have done here).

That's not sufficient to implement transactions in the way I need
them. I hope the example above shows why: I really need them to span all
buffer operations between two well defined points in time, not just text
that is inserted by process filters.

Thank you and all the best!
Markus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]