[slime-devel] propose changes to `slime-marcoexpand-again' with patch

[Stas Boukarev]

MON KEY <monkey at 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.

-- 
With best regards, Stas.