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

[Phillip Lord]

Markus Triska <triska@metalevel.at> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>>> about it, but what I think would work in this particular case is to
>>> record it as "Emacs, to undo this, you need to remove all text between X
>>> and Y", and Y simply increases as more text is inserted into the buffer.
>>> This would keep the length of the undo list constant throughout the
>>> whole interaction with the subprocess, at least in this concrete
>>> case. Can I do this in ediprolog myself? If so, then I will do it.
>>
>>
>> And what happens if the prolog process spams and never stops? Y, gets
>> longer and longer. Eventually, Emacs signals an error with a "this is
>> probably a bug" message.
>
> The way I imagine it, Y does not get "longer and longer", but is simply
> an integer that gets higher and higher when more output arrives. That
> would be one way to merge subsequent insertions in the undo list.

Sorry, I didn't put that well. My point was, simply, that if the prolog
output is too long, you have to put an boundary sooner or later, or
Emacs is going to complain.


>> I think you are doing two things -- one is telling the user that
>> something has happened and one is storing the result. I think that this
>> is the problem.
>>
>> My suggestion is add the %@ into the buffer when the result comes
>> through. If you want %@ to *appear* before this, then insert an overlay
>> with a display string.
>
> Please let us consider the more general issue of making *all*
> insertions, the first _and also subsequent ones_ that happen during the
> interaction with the Prolog process (and which can stem either from
> process output *or* from user input) *atomic* in the sense that they are
> all undone as a single unit. Please try out ediprolog to see what I
> mean. In my view, the transaction concept that Stefan has proposed is a
> very good solution for this and would benefit also other parts of Emacs.
> It is this general issue that I would like to address and solve with a
> suitable (likely: new) Emacs mechanism, not only the first %@.

Already replied to this, in my other response. It's easy to add.


> This seems completely normal and correct to me. Undo boundaries are
> currently inserted without my control over them. I understand that this
> is for efficiency reasons, to allow Emacs to trim the undo list.

Just to be clear; it's not for reasons of efficiency. Emacs has to trim
the undo list or Emacs has a memory leak. It currently has heuristic
checks in place, which make Emacs produce a user visible error when it
forcibly discards undo information.

> I would like to have more control over this, for example, by removing
> these undo boundaries when the whole interaction is over. At that
> point, we know that Emacs has not raised an error, so it should be
> very safe.

That's true, but only for a defined set of prolog output.

Still, I guess, hitting the undo limits is not a problem for ediprolog
in general use, or you would have hit it already (as I say, it's pretty
obvious when you do hit it!)

> Several other solutions would also fit this particular case, such as
> merging subsequent insertions in the undo list to keep its length
> constant. These solutions should not depend on the timing of
> insertions.
>
> We have found one case where I could prevent the undo boundary with
> special-case code (for the initial %@), but a more general solution
> would be much more welcome and work for all parts of the interaction.

No worries, I'll add to master.

Phil