bug#48399: 27.2; term-mode: After splitting window, newlines are inserted

[miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Happens even without C-n:
>>
>> M-x term
>> C-c C-j
>> ls
>> C-x 2     ;; a linefeed between prompt and "ls" in inserted
>> C-x 1     ;; another one is inserted
>
> Thanks.  I've had a brief look at term.el to see what could be causing
> this -- I wondered whether it might be a window change hook or
> something, but that doesn't seem to be the case.
>
> It seems to be happening non-synchronously -- sometimes the extra
> newline isn't added until half a second passes, so perhaps it's
> something that happens during communication between the shell and Emacs.
>
> I'm pretty unfamiliar with the term.el code.  Anybody know where to
> start poking?

When a term.el window is resized, emacs sends a SIGWINCH to it's
process. Bash seems to output some spaces newlines upon receiving a
SIGWINCH. In an ordinary terminal emulator, these spaces have the effect
of clearing bash's readline display and they aren't really visible to
the user. In term.el, however, they are inserted before the "ls" that
the user has input (this "ls" is input in term-line-mode, which means
that bash isn't aware of it yet, until the user presses RET).

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