GNU bug report logs - #23906
25.0.95; Undo boundary after process output is not consistent

Previous Next

Full log

View this message in rfc822 format

From: phillip.lord <at> russet.org.uk (Phillip Lord)
To: Markus Triska <triska <at> metalevel.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 23906 <at> debbugs.gnu.org
Subject: bug#23906: 25.0.95; Undo boundary after process output is not consistent
Date: Thu, 14 Jul 2016 21:25:06 +0100

Markus Triska <triska <at> metalevel.at> writes:

> phillip.lord <at> russet.org.uk (Phillip Lord) writes:
>
>> It is sufficient though, to restore the old behaviour and fix the
>> regression you have, which is the point of this bug!
>
>> We can think about doing something better (and which would work for
>> viper also -- as Stefan says, the current solution has some issues). But
>> I am not sure what this would look like at the moment.
>
> Please let us use this opportunity to fix the more general case
> too. Stefan agreed that the following primitives would work:
>
>     -) undo-begin-transaction
>        Starts a new transaction.
>     -) undo-end-transaction
>        Ends the most recently started undo transaction.
>
> The effects of all commands between would be undone as a single unit.

Yep, but Stefan did say how to implement this! We could do the same
thing as viper, which works, but has the issues he pointed out. Off
hand, I do not see an easy solution.

It's also worth saying that that viper has two very well defined
modes -- insert and command -- which are core to its functionality. It
begins the transaction when it enters insert mode, then ends the
transaction when it leaves. I'm not seeing this with ediprolog. How are
you going to be sure that each "begin" is paired with an "end"?


> Introducing new variables that only change how the process timer works
> would be made completely obsolete by such a solution: It would simply
> fall out as one special case of such transactions, benefit ediprolog and
> (very likely) Viper, and also other programs. Personally, I would have
> no use case for only changing the process timer if such transactions
> were available, since this is only one special case for me, even though
> it is the one that is described in the very first post of this report.

My solution is simple and easy and fits within a let binding. The
solution you are looking for solves the much more complex case where you
want undo to behave one way up to a point in time, and then amalgamate
several undos post hoc.

> I hope this approach or an equivalent one is possible in Emacs, and I
> would be very grateful if you could look into this.

At the moment, I am interested in fixing the regressions that I've
caused by my changes to the undo system which I've nearly done -- you
have a workaround at least, and I'll put something easier onto master.

New undo functionality is not high on my list at the moment, am afraid.
Happy to provide feedback if you want to add this for yourself, though.

Phil

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.