unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>,
	Michael Hoffman <emacs-hoffman@snkmail.com>
Cc: 60244@debbugs.gnu.org
Subject: bug#60244: 27.1; term-line-mode works poorly with git progress rewriting
Date: Sat, 24 Dec 2022 16:02:01 +0100	[thread overview]
Message-ID: <87ili07sly.fsf@miha-pc> (raw)
In-Reply-To: <83cz8c9b7t.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  reply	other threads:[~2022-12-24 15:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-21 20:37 bug#60244: 27.1; term-line-mode works poorly with git progress rewriting Michael Hoffman
2022-12-21 21:58 ` Michael Hoffman
2022-12-22  6:57   ` Eli Zaretskii
2022-12-24 15:02     ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-12-24 15:40       ` Eli Zaretskii
2023-01-09 17:33       ` Michael Hoffman
2023-01-09 18:27         ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ili07sly.fsf@miha-pc \
    --to=bug-gnu-emacs@gnu.org \
    --cc=60244@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=emacs-hoffman@snkmail.com \
    --cc=miha@kamnitnik.top \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).