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

Previous Next

Full log

View this message in rfc822 format

From: miha <at> kamnitnik.top
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Robert Pluim <rpluim <at> gmail.com>, Khoa Vo <vodangkhoa873 <at> gmail.com>, 48399 <at> debbugs.gnu.org
Subject: bug#48399: 27.2; term-mode: After splitting window, newlines are inserted
Date: Tue, 12 Jul 2022 15:13:22 +0200

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Michael Heerdegen <michael_heerdegen <at> 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).

[signature.asc (application/pgp-signature, inline)]

Previous Next

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