[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: |
Phillip Lord |
Subject: |
bug#23906: 25.0.95; Undo boundary after process output is not consistent |
Date: |
Mon, 11 Jul 2016 12:45:42 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Markus Triska <triska@metalevel.at>
>> Date: Wed, 06 Jul 2016 19:56:30 +0200
>>
>> 7) Now the point: *Most* of the time, after undo, the buffer is exactly
>> as it was before. But sometimes, about 1 out of 7 times, after undo
>> is pressed, the characters "%@ " remain at the end of the buffer:
>>
>> %?- time(ceiled_square_root(2^10000, R)).
>> %@
>>
>> These three characters ("%@ ") are inserted by ediprolog before
>> receiving process output, and in most cases removed after the undo.
>>
>> The issue in this case is not so much that the %@ appears in the buffer,
>> but that it is not handled consistently. Most often (and preferably), a
>> single undo removes both the process output _and_ the %@, but sometimes
>> a single undo removes *only* the process output, and the %@ remains. The
>> behaviour I desire is that C-/ consistently removes everything that was
>> inserted in direct sequence, both the "%@ " _and_ the process output.
>
> Given the fact that (AFAIU) undo for subprocesses is caught by code
> that runs off a timer, isn't the above expected? Phillip?
Assuming that ceiled_square_root takes a significant length of time
(10/7 seconds in this case!), yes, I think this is the case.
I assume that the %@ is inserted first before the process is started,
then the results put in after the results come back? This would mean
that after the insertion of %@ there would be no undo-boundary.
You could check by adding %@ immediately before you insert data from
prolog, rather than after you send data to it. To me, this makes more
sense -- you are adding text over an elongated period (i.e. during the
evaluation) without the expectation of an undo boundary. Likewise,
forcing an undo-boundary immediately after %@ would give you consistent
behaviour (although different).
There are a number of fixes we could make for this in the undo system.
I could check for the size of the last undo, before forcing an
undo-boundary. Or, we could add an option to suppress the timer in a
specific buffer; although, this would add the possibility of
out-of-memory if it's not turned on again.
In this case, though, I am inclined toward suggesting changing
ediprolog.el.
Phil
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Markus Triska, 2016/07/06
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Eli Zaretskii, 2016/07/06
- bug#23906: 25.0.95; Undo boundary after process output is not consistent,
Phillip Lord <=
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Markus Triska, 2016/07/11
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Phillip Lord, 2016/07/12
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Stefan Monnier, 2016/07/12
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Markus Triska, 2016/07/12
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Stefan Monnier, 2016/07/12
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Markus Triska, 2016/07/12
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Stefan Monnier, 2016/07/12
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Markus Triska, 2016/07/12
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Stefan Monnier, 2016/07/12
- bug#23906: 25.0.95; Undo boundary after process output is not consistent, Markus Triska, 2016/07/12