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

[Phillip Lord]

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