* bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline
@ 2020-06-21 15:43 Herman, Géza
2020-06-21 16:02 ` Eli Zaretskii
2021-09-17 16:38 ` Lars Ingebrigtsen
0 siblings, 2 replies; 7+ messages in thread
From: Herman, Géza @ 2020-06-21 15:43 UTC (permalink / raw)
To: 41984
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)
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline
2020-06-21 15:43 bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline Herman, Géza
@ 2020-06-21 16:02 ` Eli Zaretskii
2020-06-21 16:18 ` Herman, Géza
2021-09-17 16:38 ` Lars Ingebrigtsen
1 sibling, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2020-06-21 16:02 UTC (permalink / raw)
To: Herman, Géza; +Cc: 41984
> 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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline
2020-06-21 16:02 ` Eli Zaretskii
@ 2020-06-21 16:18 ` Herman, Géza
2020-06-21 16:30 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Herman, Géza @ 2020-06-21 16:18 UTC (permalink / raw)
To: Eli Zaretskii, Herman; +Cc: 41984
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline
2020-06-21 16:18 ` Herman, Géza
@ 2020-06-21 16:30 ` Eli Zaretskii
2020-06-21 18:18 ` Herman, Géza
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2020-06-21 16:30 UTC (permalink / raw)
To: Herman, Géza; +Cc: 41984
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline
2020-06-21 16:30 ` Eli Zaretskii
@ 2020-06-21 18:18 ` Herman, Géza
2020-06-21 19:03 ` Herman, Géza
0 siblings, 1 reply; 7+ messages in thread
From: Herman, Géza @ 2020-06-21 18:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41984
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline
2020-06-21 18:18 ` Herman, Géza
@ 2020-06-21 19:03 ` Herman, Géza
0 siblings, 0 replies; 7+ messages in thread
From: Herman, Géza @ 2020-06-21 19:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41984
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline
2020-06-21 15:43 bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline Herman, Géza
2020-06-21 16:02 ` Eli Zaretskii
@ 2021-09-17 16:38 ` Lars Ingebrigtsen
1 sibling, 0 replies; 7+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-17 16:38 UTC (permalink / raw)
To: Géza, 41984
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-09-17 16:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-21 15:43 bug#41984: 28.0.50; term.el's select-window call interacts badly with modeline Herman, Géza
2020-06-21 16:02 ` Eli Zaretskii
2020-06-21 16:18 ` Herman, Géza
2020-06-21 16:30 ` Eli Zaretskii
2020-06-21 18:18 ` Herman, Géza
2020-06-21 19:03 ` Herman, Géza
2021-09-17 16:38 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).