Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 21 Dec 2022 21:58:40 +0000
>> From: "Michael Hoffman" <emacs-hoffman@snkmail.com>
>> 
>> This line of bash is a better minimum example for this that doesn't require going over the network:
>> 
>> printf "line %d" 0; for i in {1..500}; do tput cr; printf "line %d" "$i"; done
>
> Funny thing is, "M-x term" does produce the expected results, and I
> cannot find what makes "M-x ansi-term" behave differently, as it's
> supposed to be almist the same as "M-x term".
>
> Miha, could you perhaps look into this issue?

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.

Best regards.