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

[Stefan Monnier]

> with the Prolog program itself. For this reason, text properties would
> not be a good fit for this use case: Users often want to store the query
> results together with the source code, and using %@ allows that.

I think he meant to use text-properties (actually, I think it would
probably be an overlay) to *display* the special initial "%@" (which you
currently insert manually "to give an indication that the query has been
sent to the process") without actually inserting it in the buffer
(e.g. with an after-string or some such).

>    1- just let the user hit undo an extra time when that happens.
> That is the current state that I consider a bit unsatisfying, so I would
> like to choose between 2, 3 and 4.

Could you explain a bit why this is unsatisfying in ediprolog's case?

In my shell buffers, I sometimes use undo and am generally happier with
undo steps that are too fine grained than with undo steps which are too
coarse because it's easier to just repeat C-/ than to try and recreate
a missing intermediate point in the middle of an undo step.  So I'm
wondering to what extent your unsatisfaction is specific to ediprolog's
interaction or whether it's more a matter of user preference.
IOW, maybe we should we aim to provide that behavior not just in
ediprolog.el but also in comint, based on some user config.

>    3- Have Ediprolog use the same trick used in Viper where we wipe out
>       intermediate boundaries after the fact.
> This sounds like a great option. Could you please tell me a bit more?

In Viper, when you do an insertion (e.g. via the "i" key) here's what
happens: while performing the insertion, the undo list is handled
normally, with boundaries inserted automatically so that you can undo
parts of what you're in the process of inserting; but when you finally
exit with ESC Viper goes back through the buffer-undo-list and throws
away all the boundaries that were added during the insertion, so that an
undo gets rid of the whole insertion (i.e. all the steps that made up
the insertion end up amalgamated into a single undo step).

> The specific use case for me is: I have a process filter that
> continuously (upon process output or user input) inserts text into the
> buffer. I just want *all* this text gone when pressing C-/. If possible,
> I hope that this can be done without the undo list growing too long.

Using Viper's approach, you could for example throw away the
undo-boundaries added since the last process-send-string.  I'd expect
you'd do it right when you see Prolog's prompt.  So if you undo while
Prolog is still in the middle of responding you might only undo parts of
the current response (like now), but once a response is complete it will
always be undone as an indivisible step.

If the "undo parts of the current response" behavior doesn't suit you,
you could try to be more aggressive about getting rid of undo boundaries
and (for example) remove them whenever new data is received from the process.

>    4- Add the kind of "do it manually" option you had added earlier, such
>       that Ediprolog could request that Emacs refrain from auto-adding any
>       undo-boundaries in its buffer.
>
> To me, this sounds at least as great as (3) and maybe could be used by
> both Viper and ediprolog if it were available?

That's what we first used for Viper, but it turned out undesirable,
because it prevents the user from undoing fine grained steps of the
current insertion.

> Ideally, only the output that stems from the interaction with the
> Prolog process and user input during the interaction should be treated
> as a single unit. This separation (i.e., treat insertions as a unit in
> some parts of a buffer while applying the normal undo behaviour in other
> parts) may of course be very hard to achieve, and I would already be
> very satisfied if there is a way to make it work in the regular case. I
> only mention for completeness that conceptually, I regard the text that
> stems from the Prolog interaction different from editing operations.

Getting it "right" in all cases may indeed be difficult (if for no other
reason than because it's difficult to formally define what we mean by
"right" in the general case).


        Stefan