bug#60244: 27.1; term-line-mode works poorly with git progress rewriting

[Eli Zaretskii <eliz@gnu.org>]

> From: <miha@kamnitnik.top>
> Cc: 60244@debbugs.gnu.org
> Date: Sat, 24 Dec 2022 16:02:01 +0100
> 
> A more reliable example would be this bash line:
> 
>     printf 'foo \015'; sleep 2; printf 'bar'
> 
> In char mode, it writes foo and overwrites it with bar, which is
> expected. But in line mode, it pushes foo after the process mark. I
> could reproduce the issue in both M-x term and M-x ansi-term. The issue
> happens due this code in function term-emulate-terminal:
> 
>     ;; If the buffer is in line mode, and there is a partial
>     ;; input line, save the line (by narrowing to leave it
>     ;; outside the restriction ) until we're done with output.
>     (when (and (> (point-max) (process-mark proc))
>            (term-in-line-mode))
>       (narrow-to-region (point-min) (process-mark proc)))
> 
> The idea is to let the user edit his partial input during a long-running
> command. But term.el assumes that, in line mode, all text after process
> mark is user input, it doesn't distinguish between actual user input and
> process output that happens to be behind process mark.
> 
> This is also the reason why a lot of full-screen TUI programs such as
> "htop" don't work correctly in line mode even if they do in char mode.
> 
> Two possible ideas to solve this:
> 
> - Introduce a new marker to separate user input from process output.
> 
> - Use text properties to distinguish user input from process output.
>   This is what comint.el does, it marks process output with 'field' =
>   'output'.
> 
> Hope this helps. Unfortunately I can't promise to be able work on any
> solution at the moment.

Thanks for the analysis.  This is AFAIU an old issue, so fixing it is
not urgent.  I hope Someone(TM) will implement one of your solutions
at some point.