bug#29118: 25.2.50; Undoing shell flush output results in weird state

[Allen Li]

On Thu, Nov 9, 2017 at 5:26 PM, Noam Postavsky
<npostavs@users.sourceforge.net> wrote:
> found 29118 26.0.90
> tags 29118 + confirmed
> quit
>
> Allen Li <vianchielfaura@gmail.com> writes:
>
>> Repro:
>>
>> 1. emacs -Q
>> 2. M-x shell RET
>> 3. echo hi RET
>> 4. C-c C-o
>> 5. C-/
>> 6. echo bye RET
>>
>> The shell buffer ends up in a weird state that's hard to describe.
>
> The process mark ends up in the wrong place.  That is,
>
>     (process-mark (get-buffer-process (current-buffer)))
>
> gives a different answer after step 3 vs after step 5.  Not really sure
> why, debugging undo-list stuff is kind of a pain.

Thanks.  A couple of followup observations:

1. As a workaround, to fix the shell buffer, you can use
comint-set-process-mark with point at where the end of the current
prompt is.
2. Changing the process-mark insertion type before undoing prevents the bug:

(set-marker-insertion-type (process-mark (get-buffer-process
(current-buffer))) t)

However, you need to set it back to nil after undoing or all user
input will get inserted before process-mark.

So one way to fix this would be to define a comint-undo that sets and
resets the process-mark insertion type.
That's probably not the most elegant solution.

I think undo in general does not behave well with markers. undo will
always rely on the insertion type of the markers,
whereas the text to re-insert may well have been on either side of the marker.

Perhaps undo should be improved to track which side of a marker
deleted text was at.  I think that might fix a whole class of
undo-related bugs.
However, this is very difficult to implement (I think, but I would be
glad to be proven wrong).