I'm having trouble restoring my window configuration after SLIME changes it. I use winner-mode, but for some reason winner-undo doesn't work for the changes that SLIME makes. The following screenshots demonstrate the problem.
1. http://i.imgur.com/2EoKK.png
This is my initial window configuration. I've entered a bit of invalid source code ("asdf") into a Common Lisp file to get SLIME to pop up an error window upon compilation.
2. http://i.imgur.com/EB8JT.png
This is the window configuration after C-c C-k'ing the invalid source code. As expected, SLIME has popped up an error window.
3. http://i.imgur.com/T3TrJ.png
This is the window configuration after calling winner-undo. I'd expect it to match the initial window configuration, but instead the pop up window stays up and shows a random buffer.
4. http://i.imgur.com/qp6cn.png
For some reason calling winner-redo restored the initial window configuration. This is the result that I expected when calling winner-undo. However, it's not always the undo-redo combination that restores the original window configuration, e.g. sometimes I have to undo twice to get the windows back the way they were.
I use winner-mode all the time, and it only has trouble with the changes that SLIME makes, which suggests that there's something peculiar about the way that SLIME shows its pop ups. Is there something that can be done to make SLIME work the way winner-mode expects (which seems to be the way the rest of Emacs works)?
* Timo Mihaljov [2012-01-19 22:27] writes:
I use winner-mode all the time, and it only has trouble with the changes that SLIME makes, which suggests that there's something peculiar about the way that SLIME shows its pop ups. Is there something that can be done to make SLIME work the way winner-mode expects (which seems to be the way the rest of Emacs works)?
winner-mode seems to use a post-command-hook. SLIME can display new windows "asynchronously" i.e. in a process filter as opposed from a command. Maybe that's the problem.
Helmut
-
Helmut Eller -
Timo Mihaljov