GNU bug report logs - #41984
28.0.50; term.el's select-window call interacts badly with modeline

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41984 in the body.
You can then email your comments to 41984 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Herman, Géza <geza.herman <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; term.el's select-window call interacts badly with modeline
Date: Sun, 21 Jun 2020 17:43:09 +0200

I noticed that the call "(select-window win)" in term.el (in 
term-emulate-terminal) interacts badly with doom modeline. This 
select-window call confuses the modeline which is the active window, and 
it causes the terminal's modeline displayed as active, as soon as the 
terminal receives output, no matter which is the actual active window. 
And the real active window is displayed with an inactive modeline.

I found if I modify this "(select-window win)" line to "(select-window 
win t)", the bug doesn't happen anymore (I'm not sure whether it's a 
correct fix in all regards or not).

Here's my full description of the issue, with screenshot: 
https://github.com/seagle0128/doom-modeline/issues/355

Describe: When one window has an ansi-term, which constantly outputs 
some text, and another window has the focus, then doom-modeline behaves 
strange: the mode line of the focused window loses activity, and part of 
ansi-term's mode line becomes active.

Use this init.el:

---------------------------------------------

(require 'package)
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/"))
(add-to-list 'package-archives '("melpa-stable" . 
"http://stable.melpa.org/packages/"))
(package-initialize)

(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package)
)

(setq use-package-always-ensure t)

(eval-when-compile (require 'use-package))

(use-package doom-modeline
  :hook (after-init . doom-modeline-mode)
)

---------------------------------------------

Here are the repro steps:

* start emacs
* split windows with split-window-vertically
* execute ansi-term in one window, and enter this command into the 
shell: while true ; do echo Ize ; sleep 2 ; done
* move the cursor to the other window
* notice that the other window's modeline get activity (colored as so, 
as it supposed to be), but as soon as the terminal window has output, it 
loses it (colored as inactive). And the terminal window will have a 
weird colored modeline (half of it is active, the other half is inactive)

Message #8 received at 41984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Herman <at> debbugs.gnu.org, Géza <geza.herman <at> gmail.com>
Cc: 41984 <at> debbugs.gnu.org
Subject: Re: bug#41984: 28.0.50;
 term.el's select-window call interacts badly with modeline
Date: Sun, 21 Jun 2020 19:02:26 +0300

> From: Herman <at> debbugs.gnu.org, Géza <geza.herman <at> gmail.com>
> Date: Sun, 21 Jun 2020 17:43:09 +0200
> 
> I noticed that the call "(select-window win)" in term.el (in 
> term-emulate-terminal) interacts badly with doom modeline. This 
> select-window call confuses the modeline which is the active window, and 
> it causes the terminal's modeline displayed as active, as soon as the 
> terminal receives output, no matter which is the actual active window. 
> And the real active window is displayed with an inactive modeline.
> 
> I found if I modify this "(select-window win)" line to "(select-window 
> win t)", the bug doesn't happen anymore (I'm not sure whether it's a 
> correct fix in all regards or not).
> 
> Here's my full description of the issue, with screenshot: 
> https://github.com/seagle0128/doom-modeline/issues/355
> 
> Describe: When one window has an ansi-term, which constantly outputs 
> some text, and another window has the focus, then doom-modeline behaves 
> strange: the mode line of the focused window loses activity, and part of 
> ansi-term's mode line becomes active.

Any reason why you decided this isn't a doom modeline bug?

Message #11 received at 41984 <at> debbugs.gnu.org (full text, mbox):

From: Herman, Géza <geza.herman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Herman <at> debbugs.gnu.org
Cc: 41984 <at> debbugs.gnu.org
Subject: Re: bug#41984: 28.0.50; term.el's select-window call interacts badly
 with modeline
Date: Sun, 21 Jun 2020 18:18:20 +0200

I don't have a strong opinion on this. I just felt that selecting a 
window because an output arrived is not a right thing to do. Any hooks 
which are called during this temporarily set selected-window will have 
the wrong idea which is the actual selected window (I'm not exactly 
sure, why the bug happens though, I just suppose this is the reason).

I've checked now, spaceline behaves exactly the same as doom modeline. 
But if you think that this is not a term.el bug, please tell the 
reasons, and I'll reopen my doom-modeline issue with these reasons.

On 6/21/20 6:02 PM, Eli Zaretskii wrote:
>> From: Herman <at> debbugs.gnu.org, Géza <geza.herman <at> gmail.com>
>> Date: Sun, 21 Jun 2020 17:43:09 +0200
>>
>> I noticed that the call "(select-window win)" in term.el (in
>> term-emulate-terminal) interacts badly with doom modeline. This
>> select-window call confuses the modeline which is the active window, and
>> it causes the terminal's modeline displayed as active, as soon as the
>> terminal receives output, no matter which is the actual active window.
>> And the real active window is displayed with an inactive modeline.
>>
>> I found if I modify this "(select-window win)" line to "(select-window
>> win t)", the bug doesn't happen anymore (I'm not sure whether it's a
>> correct fix in all regards or not).
>>
>> Here's my full description of the issue, with screenshot:
>> https://github.com/seagle0128/doom-modeline/issues/355
>>
>> Describe: When one window has an ansi-term, which constantly outputs
>> some text, and another window has the focus, then doom-modeline behaves
>> strange: the mode line of the focused window loses activity, and part of
>> ansi-term's mode line becomes active.
> Any reason why you decided this isn't a doom modeline bug?

Message #14 received at 41984 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Herman, Géza <geza.herman <at> gmail.com>
Cc: 41984 <at> debbugs.gnu.org
Subject: Re: bug#41984: 28.0.50; term.el's select-window call interacts badly
 with modeline
Date: Sun, 21 Jun 2020 19:30:22 +0300

> Cc: 41984 <at> debbugs.gnu.org
> From: Herman, Géza <geza.herman <at> gmail.com>
> Date: Sun, 21 Jun 2020 18:18:20 +0200
> 
> I don't have a strong opinion on this. I just felt that selecting a 
> window because an output arrived is not a right thing to do.

I don't see why this would not be a right thing to do.  Presumably,
term.el wants to attract the user's attention to the fact that new
input arrived.

> Any hooks 
> which are called during this temporarily set selected-window will have 
> the wrong idea which is the actual selected window (I'm not exactly 
> sure, why the bug happens though, I just suppose this is the reason).
> 
> I've checked now, spaceline behaves exactly the same as doom modeline. 
> But if you think that this is not a term.el bug, please tell the 
> reasons, and I'll reopen my doom-modeline issue with these reasons.

I think the hooks that do something with the modeline need to be able
to handle this situation, or, failing that, disable themselves when
the selected window displays a term.el buffer.

Message #17 received at 41984 <at> debbugs.gnu.org (full text, mbox):

From: Herman, Géza <geza.herman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41984 <at> debbugs.gnu.org
Subject: Re: bug#41984: 28.0.50; term.el's select-window call interacts badly
 with modeline
Date: Sun, 21 Jun 2020 20:18:31 +0200

On 6/21/20 6:30 PM, Eli Zaretskii wrote:
> I don't see why this would not be a right thing to do.  Presumably,
> term.el wants to attract the user's attention to the fact that new
> input arrived.
Okay, I don't understand emacs's internals nor elisp to judge this. As I 
see, it doesn't attract the user's attention. It does some scroll 
related stuff. Like keeping the last written line at the bottom, or so.

Anyways, as adding a "t" parameter to select-window seems to fix the 
issue for me, I'll just add it into my term.el. Feel free to close this 
issue if you think that's not a term.el bug.

Message #20 received at 41984 <at> debbugs.gnu.org (full text, mbox):

From: Herman, Géza <geza.herman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41984 <at> debbugs.gnu.org
Subject: Re: bug#41984: 28.0.50; term.el's select-window call interacts badly
 with modeline
Date: Sun, 21 Jun 2020 21:03:51 +0200

What is suspicious to me: term-emulate-terminal uses 
save-selected-window. And save-selected-window uses "(select-window (car 
state) 'norecord)", when it restores the state. Note the 'norecord 
parameter. So it is very logical to me that the "(select-window win)" 
call in term-emulate-terminal should also have 'norecord.

Also, here's the help for select-window:

"Note that applications and internal routines often select a window 
temporarily for
various purposes; mostly, to simplify coding.  As a rule, such
selections should be not recorded and therefore will not pollute
buffer-list-update-hook.  Selections that "really count" are those
causing a visible change in the next redisplay of WINDOW's frame and
should be always recorded."

So this issue definitely seems a bug in term.el to me.

Message #23 received at 41984 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Géza <geza.herman <at> gmail.com>,  41984 <at> debbugs.gnu.org
Subject: Re: bug#41984: 28.0.50; term.el's select-window call interacts
 badly with modeline
Date: Fri, 17 Sep 2021 18:38:48 +0200

Herman, Géza <geza.herman <at> gmail.com> writes:

> I found if I modify this "(select-window win)" line to "(select-window
> win t)", the bug doesn't happen anymore (I'm not sure whether it's a
> correct fix in all regards or not).

I think that sounds like the correct fix here (since we're just doing
this for internal reasons, we shouldn't record the window selection), so
I've pushed this change to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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