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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Herman
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)



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: [hidden email], Géza <[hidden email]>
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Herman
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: [hidden email], Géza <[hidden email]>
>> 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?




Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Cc: [hidden email]
> From: Herman, Géza <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Herman


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.



Reply | Threaded
Open this post in threaded view
|

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

Herman
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.