syl20bnr/spacemacs

Automatic Switching of Layouts

Open

#12,935 opened on 2019年11月13日

GitHub で見る
 (8 comments) (1 reaction) (1 assignee)Emacs Lisp (17,754 stars) (4,381 forks)batch import
Feature requestHelp wantedSpacemacs Layouts

説明

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.

コントリビューターガイド