[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29118: 25.2.50; Undoing shell flush output results in weird state
From: |
Allen Li |
Subject: |
bug#29118: 25.2.50; Undoing shell flush output results in weird state |
Date: |
Fri, 10 Nov 2017 23:20:36 -0800 |
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).