I would request that all the slime window-configuration/restoration code be moved to a contrib module.
By default slime could have a simple `bury-buffer on q' mechanism to get rid of all windows. The fancy window configuration/restoration should work only if the contrib is loaded.
Emacs has many window and frame related variables that one can customize, and display-functions that one can advise to make it work the way one wants. The current code (I suspect) makes particular assumptions that are no doubt valid for the developers but these are invalid in general.
I won't waste my breath on scenarios any more but slime always always gets it wrong: getting back to the buffer I want usually takes 2-3 window/buffer rearrange commands.
Moving the window configuration stuff out of slime would also be a step towards making much touted `simplicity' goals of slime a reality in the code rather the "mailing list concept"
-- Madhu
On Thu, Sep 25, 2008 at 5:10 AM, Madhu enometh@meer.net wrote:
I would request that all the slime window-configuration/restoration code be moved to a contrib module.
By default slime could have a simple `bury-buffer on q' mechanism to get rid of all windows. The fancy window configuration/restoration should work only if the contrib is loaded.
I second that. The attempts to use fancy window configuration tricks (not just those used by SLIME, also other Emacs applications) always tend to get into my way of using Emacs.
(I won't have time to work on it, though.)
Matthias -- Matthias Koeppe -- http://www.math.ucdavis.edu/~mkoeppe
Madhu enometh@meer.net writes:
Moving the window configuration stuff out of slime would also be a step towards making much touted `simplicity' goals of slime a reality in the code rather the "mailing list concept"
Michael Weber once told me Slime probably should get rid of the window-configuration restoration, and instead point users to Emacs' `winner.el' mode which now also comes with the Emacs distribution itself.
This seems like a viable solution to me.
-T.