Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

display-buffer-alist not respecting window settings #16507

Closed
88-percent opened this issue Jul 25, 2024 · 2 comments
Closed

display-buffer-alist not respecting window settings #16507

88-percent opened this issue Jul 25, 2024 · 2 comments

Comments

@88-percent
Copy link

88-percent commented Jul 25, 2024

In mu4e displaying the main-view removes all windows in the frame by calling delete-other-windows. This is apparently a feature not a bug. I'm trying to get the mu4e main view to open in the window it is called.

The dev helpfully suggests updating display-buffer-alist to disable this behavior with the following elisp:

(add-to-list 'display-buffer-alist
             `(,(regexp-quote mu4e-main-buffer-name)
               display-buffer-same-window))

While this seems to be allowing most users to keep their window setup, it isn't working for me. This leads me to believe it may be an issue with how Spacemacs deals with display-buffer-alist.

I can see I've successfully stored the mu4e main buffer to the buffer alist because describing the variable returns:

display-buffer-alist is a variable defined in ‘window.el’.

Its value is
(("\\*mu4e-main\\*" display-buffer-same-window)
 ("^ \\*org-contact\\*" display-buffer-below-selected)
 ("^\\*Ilist\\*$" imenu-list-display-buffer))
Original value was nil

Because this wasn't working for me I tried updating the Spacemacs-specific buffer alist.

  (add-to-list 'spacemacs-display-buffer-alist
               `(,(regexp-quote mu4e-main-buffer-name)
                 display-buffer-same-window))

I noticed it needed the value stored to both variables to stick, but it looks like I've managed to store it appropriately:

spacemacs-display-buffer-alist is a variable defined in ‘../../config.el’.

Its value is
(("\\*mu4e-main\\*" display-buffer-same-window)
 ("^ \\*org-contact\\*" display-buffer-below-selected)
 ("^\\*Ilist\\*$" imenu-list-display-buffer))

Not documented as a variable.

Even with these changes, every time mu4e's main view is displayed it wipes all my windows in the same frame.

Why can't I get the main window displayed in the same window as called?

OS: Pop!OS 22.04
Emacs: 29.4
Spacemacs: latest develop
mu4e: 1.12.5

@88-percent
Copy link
Author

I've been able to get the functionality working (more or less).

It seems there's nothing wrong with the above elisp, but that mu4e doesn't respect the settings on first launch.

For anyone else having this issue I got mu4e working within the window called in Spacemacs with the following 2 steps:

  1. add the following elisp to dotspacemacs/user-config
  ;; stop mu4e decimating windows on launch
  (add-to-list 'display-buffer-alist
               `(,(regexp-quote mu4e-main-buffer-name)
                 display-buffer-same-window))
  (add-to-list 'spacemacs-display-buffer-alist
               `(,(regexp-quote mu4e-main-buffer-name)
                 display-buffer-same-window))
  1. never quit mu4e. This can be done my simply switching from the main-view buffer instead of hitting q or alternatively using space u q to bury the main-view buffer.

note: running mu4e the 1st time in each session will still wipe all windows in the frame.

@fnussbaum
Copy link
Collaborator

I don't use the spacemacs-purpose layer myself but can reproduce the problem on a default installation. purpose-mode seems to ignore display-buffer-alist, see for example bmag/emacs-purpose#191 and bmag/emacs-purpose#82. The following might help:

(add-to-list 'purpose-action-function-ignore-buffer-names (regexp-quote mu4e-main-buffer-name))

I think the variable spacemacs-display-buffer-alist is not supposed to be changed manually, it seems to be an implementation detail of the Helm layer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants