If output written to ansi-term, then activity of modeline behaves strange

[geza-herman]

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.

Steps and Expected
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 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)

Here's a screenshot of the problem (the cursor is in the bottom window. Look at the upper mode line, it's weird, and the bottom mode line, which supposed to be active, but it is colored inactive):

Note, that this bug doesn't happen with the default mode line.

Environment:

• OS and version: Debian Linux (unstable)
• Emacs Version: GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20) of 2020-05-17, modified by Debian
• Configuration: -
• Package version: 20200618.1712

[seagle0128]

I can reproduce it, but no idea how to fix it.
Seems the loop makes doom-modeline--active return nil always.

[seagle0128]

Update:

1. I found it's related to the theme. Change to doom-one theme, the issue disappears.
2. No issue with vterm.

[geza-herman]

Thanks for looking into this issue!

For me, it still happens with the doom-one theme. Exactly the same issue, just with different colors (the weird half active/half inactive modeline is harder to see, but it's there). The way I configured it: I appended the code snippet which is after the text "Here is a example configuration for doom-theme:" at https://github.com/hlissner/emacs-doom-themes.

But I can confirm, the issue does not happen with vterm. I'll check it out whether I can configure it to my needs, so I can switch to it.

[geza-herman]

Unfortunately I cannot switch to vterm, as it doesn't support lines longer than the window width properly.

I've analyzed this issue a little bit, and it seems that ansi-term changes selected window temporarily, when output arrives (it calls (select-window)). Presumably this is the time, when doom mode line gets updated, so doom mode line is misled which is the actual selected window.

I'm not sure why the issue doesn't happen with the default mode line.

[seagle0128]

I'm not sure why the issue doesn't happen with the default mode line.

Because default mode line doesn't refresh according to the active/inactive windows. It updates regularly, but doom-moeline updates according to the active/inactive windows for better performance.

[geza-herman]

I found that if I modify term.el:3103, change (select-window win) to (select-window win t), the bug disappears. I reported this to the emacs bug email list: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41984

[seagle0128]

Thanks for the update! You can make a workaround for now. I still prefer vterm.

[geza-herman]

Yes, vterm is better in almost all regards. It's much faster, and has a more complete emulation. But still, lacks a very important feature for me: how it handles long lines. It just breaks long lines into several lines. Hence I cannot copy a vterm buffer into a file properly. This is the issue, and it seems it's complicated to solve: neovim/neovim#2514

[seagle0128]

I don't know your case exactly, but I think you should try vterm-copy-mode.

[geza-herman]

Thanks for the suggestion, I use this for copying. The actual problem is not about copying, but how long lines end up in the buffer. Long lines are just broken into pieces, and the information that these pieces are actually from a single line is lost. So long lines end up as multiple, separate lines in the buffer.

There is a solution for this, setting vterm-min-window-width to a high number. But this messes other things up, so there is no real solution. ansi-term works perfectly in this regard.

[geza-herman]

Update: as it turned out, copying does work correctly. There was a recent PR for this feature: akermu/emacs-libvterm#274. Thanks for suggesting vterm, I may end up using it then!