From: phillip.lord@russet.org.uk (Phillip Lord)
To: Markus Triska <triska@metalevel.at>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 23906@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 [thread overview]
Message-ID: <87shvcfiox.fsf@russet.org.uk> (raw)
In-Reply-To: <87zipkzkge.fsf@metalevel.at> (Markus Triska's message of "Thu, 14 Jul 2016 10:34:57 +0200")
Markus Triska <triska@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
next prev parent reply other threads:[~2016-07-14 13:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 17:56 bug#23906: 25.0.95; Undo boundary after process output is not consistent Markus Triska
2016-07-06 18:38 ` Eli Zaretskii
2016-07-11 11:45 ` Phillip Lord
2016-07-11 13:54 ` Markus Triska
2016-07-12 16:29 ` Phillip Lord
2016-07-12 17:03 ` Stefan Monnier
2016-07-12 18:56 ` Markus Triska
2016-07-12 20:22 ` Stefan Monnier
2016-07-12 21:02 ` Markus Triska
2016-07-12 21:20 ` Stefan Monnier
2016-07-12 22:35 ` Markus Triska
2016-07-12 22:51 ` Stefan Monnier
2016-07-12 22:45 ` Markus Triska
2016-07-13 22:12 ` Phillip Lord
2016-07-14 8:34 ` Markus Triska
2016-07-14 13:33 ` Phillip Lord [this message]
2016-07-14 15:10 ` Markus Triska
2016-07-14 20:25 ` Phillip Lord
2016-07-14 22:12 ` Stefan Monnier
2016-07-18 4:18 ` Stefan Monnier
2016-07-18 19:03 ` Markus Triska
2016-07-19 0:41 ` Stefan Monnier
2016-07-19 1:05 ` Stefan Monnier
2016-07-24 15:45 ` Phillip Lord
2016-07-24 21:36 ` Stefan Monnier
2020-09-04 13:55 ` Lars Ingebrigtsen
2016-07-13 8:09 ` Phillip Lord
2016-07-13 14:29 ` Markus Triska
2016-07-13 22:23 ` 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=87shvcfiox.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=23906@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=triska@metalevel.at \
/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).