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

Automatic Switching of Layouts #12935

Open
dbankmann opened this issue Nov 13, 2019 · 8 comments
Open

Automatic Switching of Layouts #12935

dbankmann opened this issue Nov 13, 2019 · 8 comments

Comments

@dbankmann
Copy link
Contributor

dbankmann commented Nov 13, 2019

First of all, I'm not sure, whether I fully understood the concept of layouts. So, I'm just gonna explain how I want to use it. Comments, whether this is intended behavior are very welcome.

I'm mostly using the standard layouts shipped with some of the layers, i.e., @Spacemacs, @Mu4e and @Org layer.
Buffer separation within the layouts works fine as long as I stay in one regime (i.e., just edit my org files or acting on mails).
However, as soon as I 'connect' two layouts I'm getting in trouble.

For instance, I occasionally capture some mails as todo task in my org files. Then, at some point I want to return to that mail by following the link in the corresponding org entry. Of course, at that time, I'm in the @Org layout.
Unfortunately, after following the link, the *mu4e-view* and *mu4e-headers* buffers show up (as expected) while staying in the @Org layout.

This leads to several strange behavior:

  • after closing the *mu4e-view* buffer again, I'm asked whether I want to kill the current buffer even though it's not part of the currently active layout @Org.
  • Even after accepting to kill the buffer or close the window. The buffer that becomes visible is just the next buffer of the @Mu4e layout buffer list (and not just my org file). So, in both cases, I have to press something like SPC l <Number of Org layout> to recover the original @Org layout structure.
  • When replying to that mail a compose buffer replaces the *mu4e-view* buffer. After closing that buffer my window layout stays split with the upper window being the *mu4e-headers* buffer and the lower window just contains the original org file. Another SPC w 1 is required to restore the state before following the mail link.
@nixmaniack
Copy link
Contributor

I agree that the behaviour of layouts when accessing the buffers from other layouts is not well defined and not very intuitive.

To suppress the prompt that you mentioned in point # 1, I had set (setq persp-kill-foreign-buffer-behaviour 'kill) based on this.

@practicalli-johnny
Copy link
Contributor

@dbankmann I am unsure if this helps, but the spacemacs-layouts documentation has been updated in develop and included examples of restricting functions to the current layout.

https://github.com/syl20bnr/spacemacs/tree/develop/layers/+spacemacs/spacemacs-layouts

@dbankmann
Copy link
Contributor Author

@jr0cket Thanks, but I don't think, this really helps, because I actually intentionally want to access a buffer that is outside the current layout.

@github-actions
Copy link

github-actions bot commented Jan 3, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Jan 3, 2021
@dbankmann
Copy link
Contributor Author

It is still valid.

@duianto duianto removed the stale marked as a stale issue/pr (usually by a bot) label Jan 3, 2021
@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Jan 27, 2022
@lebensterben lebensterben added Feature request Help wanted and removed stale marked as a stale issue/pr (usually by a bot) - Mailling list - labels Jan 29, 2022
Copy link

github-actions bot commented May 1, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label May 1, 2024
@fnussbaum
Copy link
Contributor

I think it would be nice to address this in some way, and I have some work in progress on that.

@github-actions github-actions bot removed the stale marked as a stale issue/pr (usually by a bot) label Jun 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants