Dirvish in second frame keep flashing

[fakeGenuis]

I confirm that...

• [x] I have searched the issue tracker, documentation, FAQ, Discourse, and Google, in case this issue has already been reported/resolved.

• [x] I have read "How to Debug Issues", and will use it to provide as much information about this issue as possible.

• [x] The issue can be reproduced on the latest available commit of Doom.

• [x] The issue can be reproduced on a stable release of Emacs, such as 27, 28, 29, or 30. (Unstable versions end in .50, .60, or .9x)

Expected behavior

Open doom emacs, dirvish, and create new frame with make-frame, dirvish again. In both frame, dirvish should work smoothly without flash.

Current behavior

After create second frame and run dirvish, the dirvish in both frame flash when navigate to a directory. see the gif for details.

Steps to reproduce

1. open emacs
2. M-x dirvish
3. SPC o f to create new frame
4. M-x dirvish
5. navigate to a directory

System Information

https://pastebin.com/EN7qLqK2

[fakeGenuis]

Sorry for that gif not display well in the github page, please click into it for a complete view

[hlissner]

This seems more like an OS/DM level issue than an Emacs one. See if this helps:

;;; add to $DOOMDIR/config.el
(add-to-list 'default-frame-alist '(inhibit-double-buffering . t))

If not, try installing the emacs-pgtk build of Emacs instead. If you're on Wayland, emacs-pgtk is practically a requirement.

[fakeGenuis]

It doesn't work. But I notice that it didn't always flash, is just 2 or 3 times flash after create new frame or switch back from other windows. And it did not occupy high cpu usage. So it might be just fine for me.

I use X11 not Wayland, so I cannot switch to emacs-pgtk.

[hlissner]

emacs-pgtk should work on X11 too. Another possibility is a compositor. Do you use something like picom? If so, try disabling it.

[fakeGenuis]

I tried both emacs-pgtk and disable picom, didn't work :(

[hlissner]

Hmm. I haven't been able to reproduce it so far. Here are some more things to try:

1. Increase dirvish-input-debounce:

   ;;; add to $DOOMDIR/config.el
   (after! dirvish
     (setq dirvish-input-debounce 0.1))  ; default is 0.02
   

2. Update dirvish to a more recent commit:

   ;;; add to $DOOMDIR/packages.el
   (package! dirvish :pin "ecb7c42e20ce18f80d702eafb2e6add5b1e4d023")
   

   Then run doom sync and restart Emacs.

3. Run the profiler (C-h T to start it, C-h T again to stop it and produce a report). The report will contain a sample of the functions that were called in between the two calls. You can press TAB to expand entries in the report to dig deeper into the call stacks. I'm looking for any dirvish functions that it may have spent a lot of time in.

4. Comment out all your config in $DOOMDIR/config.el and $DOOMDIR/packages.el, run doom sync, then restart Emacs and see if you can still reproduce it.

[fakeGenuis]

Try 1, 2 and 4, still failed. With 3, only suspect function is dirvish-pre-redisplay-h, it seems related to redisplay after navigate change. Below figure is what I get with:

1. run dirvish
2. make-frame and C-h T
3. dirvish and wait it flash several times
4. C-h T

If I delay C-h T after dirvish in second frame, what I get is

Actually, the only way I get expected behavior of dirvish is in vanilla emacs, install it with package-install. (I also tried "vanilla Doom" and "vanilla emacs" with doom-sandbox, but don't know why dired/dirvish report no such file or directory, ls)

[sprig]

same issue - one frame works fine, second ine starts flashing when the cursor is on a directory (such that the right pane displays a file listing).

running vanilla emacs 30.1, dirvish 20250415.706 from melpa.

ran profiler for a few seconds, saw ~3k calls to dirvish-pre-display-h. Not sure whether directly related, but i also saw ~1k calls to helm functions stemming from dirvish, which, why??

Machine is offline right now so i cannot post the profile report directly - phone screenshot attached;

[hlissner]

running vanilla emacs 30.1, dirvish 20250415.706 from melpa.

This appears to be an upstream issue. Please report it to https://github.com/alexluigit/dirvish/issues as well.

ran profiler for a few seconds, saw ~3k calls to dirvish-pre-display-h. Not sure whether directly related, but i also saw ~1k calls to helm functions stemming from dirvish, which, why??

See if this helps:

;;; add to $DOOMDIR/config.el
(defadvice! +dired--debounce-dirvish-pre-redisplay-a (fn window)
  :around #'dirvish-pre-redisplay-h
  (unless (eq dirvish--selected-window (frame-selected-window))
    (funcall fn window)))

Should help to significantly rate-limit the number of times dirvish-pre-redisplay-h calls dirvish--redisplay. If it works, I'll push that (or similar) to our dired module until it's addressed upstream.

[sprig]

woops, i don’t know how i didn’t notice this - i thought i’m posting in the dirvish repo. this is definitely upstream - i do use doom modeline but not doom emacs generally, and, anyway, this happened even with the modeline disabled.

thanks for the debounce tip! however, im not sure i entirely understand the logic since AFAIR, i personally experienced this as happening in the second frame, whether it was active or not.

seemed like a bad interaction between the frames. this would definitely help in the case where none of the frames are active, but i suspect that less so when the blinker is focused, where, presumably it might cut the calls in half by filtering the other frame?

esp if my memory fails me and this only happened when the frame was focused, i think i would suggest/prefer to simply rate limit the calls - i would not perceive eg a 1ms lag in updating a file list. i’d post my suggested fix but im writing this on a phone rn

all that being said, i was about to test the fix anyway but cannot reproduce the issue at the moment.

i discovered it as i was experimenting with some config changes and did not make commits yet, so im probably not going to be able to bisect, but i will check if my previous commit suffered from this as well. my immediate suspects are changes i was making to display related config in both helm and more generally (ie display-buffer-alist and base-display-action, and similar).

@fakeGenuis, do you happen to use helm or have any display-buffer related customizations?

[fakeGenuis]

I'm not using helm. I tried vanilla emacs again with new installed dirvish, this time the cursor in middle buffer flash (one time) after change navigate (between position at first and second frame). The strange behavior may related to dirvish-pre-redisplay-h, so I believe this is an upstream issue.

[emenel]

i'm seeing this too. was it ever reported upstream? i don't see anything in the dirvish issues. if not, i'm happy to make an issue there.

[fakeGenuis]

no. you can report there.

[sprig]

For me the issue disappeared. I can no longer reproduce and thus would have a hard time reporting upstream. Please report if you can.