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 14:33:18 +0100

Markus Triska <triska <at> metalevel.at> writes:
>> 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?

No. I cancelled the timer but forgot to remove it from the variable it's
stored in. Since the timer (even once cancelled) is non-nil, it's never
rescheduled.

My inclination is make the timer private to be honest.


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

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.

Phil

Previous Next

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