Treemacs: Incompatible with evil-window-move-far-*

[kenkangxgwe]

I encountered this with Spacemacs on windows 10. To reproduce the problem:

1. Open a treemacs window with two other paralleled windows,
   so it looks like | treemacs | windows1 | windows2|
2. Move the left window (aka window1) to far right using (evil-window-move-far-right).
   Then the frame becomes | treemacs | treemacs | windows2 | windows1 |
3. Try closing any window and it will complain that
   [Treemacs] Window width has been unlocked. Window #<window 17 on *Treemacs-Framebuffer-1*> has same side left as window #<window 25 on *Treemacs-Framebuffer-1*> but no common parent Error in pre-command-hook (which-key--hide-popup): (error "Window #<window 17 on *Treemacs-Framebuffer-1*> has same side left as window #<window 25 on *Treemacs-Framebuffer-1*> but no common parent")

[Alexander-Miller]

Does the problem remain using the following code instead of treemacs? If yes, the problem is on evil, and how it reacts to dedicated and/or side-windows.

(with-selected-window (display-buffer-in-side-window
                       (get-buffer-create "TEST")
                       '((side . left)))
  (set-window-dedicated-p (selected-window) t))

[kenkangxgwe]

Your code works fine on my computer.

[Alexander-Miller]

What's your config look like?

[kenkangxgwe]

I use the default config of spacemacs

[duianto]

Confirmed, the same issue occurs here.

To get Spacemacs to a working state I had to restart without resuming layouts SPC q R

System Info :computer:

• OS: windows-nt
• Emacs: 26.1
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. 95422ae5d)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(autohotkey colors emacs-lisp git helm html markdown multiple-cursors org spell-checking treemacs version-control)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS THREADS LCMS2

[Alexander-Miller]

Did more digging. Looks like it's a problem with both sides. You can see it with the following example code:

(with-selected-window (display-buffer-in-side-window
                       (get-buffer-create "TEST")
                       '((side . left)))
  (set-window-dedicated-p (selected-window) t)
  (set-window-parameter (selected-window) 'no-delete-other-windows t))

Treemacs uses the 'no-delete-other-windows parameter if your treemacs-no-delete-other-windows is non-nil. It prevents a window from being deleted when calling something like delete-other-windows or a fullscreen version of magit-status. Evil likewise calls delete-other-windows, expecting all other windows to be deleted, but the treemacs windows stays, so when evil restores the previous window state after its move there's suddenly 2 treemacs windows around.

The whole thing is then compounded by treemacs, which hooks into window-configuration-change-hook to restore its 'window-side parameter. This is necessary as this parameter is not permanent and window-config changing packages like eyebrowse (and evil) would lose it. I guess that the hook catches the wrong window leading to the mess that you are finally seeing.

I will raise this issue with evil. In the short-term I will try advising evil's move functions to make sure treemacs isn't around while the move is happening.

[Alexander-Miller]

https://github.com/emacs-evil/evil/issues/1129

[Jasu]

I figured out a workaround, temporarily close Treemacs when moving windows around:

(defun config/fix-evil-window-move (orig-fun &rest args)
  "Close Treemacs while moving windows around."
  (let* ((treemacs-window (treemacs-get-local-window))
         (is-active (and treemacs-window (window-live-p treemacs-window))))
    (when is-active (treemacs))
    (apply orig-fun args)
    (when is-active
      (save-selected-window
        (treemacs)))))

  (dolist (func '(evil-window-move-far-left evil-window-move-far-right evil-window-move-very-top evil-window-move-very-bottom))
    (advice-add func :around #'config/fix-evil-window-move))

[Alexander-Miller]

Yeah, that would've been my idea for a workaround as well. Thanks for reminding me.