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

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

[Herman, Géza]

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)

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

[Eli Zaretskii]

> From: Herman@debbugs.gnu.org, Géza <geza.herman@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?

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

[Herman, Géza]

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@debbugs.gnu.org, Géza <geza.herman@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?

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

[Eli Zaretskii]

> Cc: 41984@debbugs.gnu.org
> From: Herman, Géza <geza.herman@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.

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

[Herman, Géza]

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.

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

[Herman, Géza]

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.

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

[Lars Ingebrigtsen]

Herman, Géza <geza.herman@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