MON KEY monkey@sandpframing.com writes:
Apropos the bug report here: https://bugs.launchpad.net/slime/+bug/777405
I'd like to propose the following changes to slime.el's macroexpansion functions: `slime-macroexpand-again' `slime-initialize-macroexpansion-buffer' `slime-create-macroexpansion-buffer'
These changes make explicit which buffer should be current during calls to `slime-macroexpand-again' and are IMO in keeping with the intent of the command.
The changes to `slime-initialize-macroexpansion-buffer' are w/r/t its optional arg BUFFER and provide additional checks to prevent `erase-buffer' and setting `buffer-undo-list' to nil when current-buffer is not "*slime-macroexpansion*".
I've included the proposed changes in full below as well as a diff of slime.el from quicklisp 20110320 with slime.el from CVS 1.1364
To reiterate what I said on launchpad. The aforementioned scenario doesn't come up in any normal usage. If you do this accidentally, learn your lesson and don't do that again. Doing M-x slime-thread-control-mode will discard undo history as well, but I don't see you complaining about it.
I don't feel that the goal of slime is to provide an idiot-proof interface. Especially that there are many other parts of emacs which are easily accessible to the user and which can be potentially harmful.
Considering this, I see no point in fixing what isn't broken.