GNU bug report logs - #60244
27.1; term-line-mode works poorly with git progress rewriting

Previous Next

Package: emacs;

Reported by: "Michael Hoffman" <emacs-hoffman <at> snkmail.com>

Date: Wed, 21 Dec 2022 20:38:02 UTC

Severity: normal

Found in version 27.1

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: <miha <at> kamnitnik.top>
Cc: emacs-hoffman <at> snkmail.com, 60244 <at> debbugs.gnu.org
Subject: bug#60244: 27.1; term-line-mode works poorly with git progress rewriting
Date: Sat, 24 Dec 2022 17:40:40 +0200
> From: <miha <at> kamnitnik.top>
> Cc: 60244 <at> 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.




This bug report was last modified 2 years and 162 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.