Comment 4 for bug 777405

On Sun, May 8, 2011 at 7:12 AM, Stas Boukarev <email address hidden> wrote:
> Why do you run slime-macroexpand-again not in a slime-macroexpansion
> buffer?
>

On Sun, May 8, 2011 at 7:12 AM, Stas Boukarev <email address hidden> wrote:
> Why do you run slime-macroexpand-again not in a slime-macroexpansion
> buffer?
>

As indicated earlier, an invocation of `slime-macroexpand-again' in
the wrong buffer is most often by accident:

,----
| This happens easily when one uses values of `minibuffer-history' for
| M-x command completion esp. b/c `slime-macroexpand-*' is a prefix
| for at least seven different interactive macro-expansion related
| commands including:
|
| slime-macroexpand-1
| slime-macroexpand-1-inplace
| slime-macroexpand-again
| slime-macroexpand-all
| slime-macroexpand-all-inplace
| slime-macroexpand-undo
| slime-macroexpansion-minor-mode
|
`----

Regardless, I don't see any reason why the proposed modification of
`slime-macroexpand-again' shouldn't slime-rcurry (slime-buffer-name
:macroexpansion) instead of (current-buffer) e.g.:

(defun slime-macroexpand-again ()
 "Reperform the last macroexpansion."
 (interactive)
 (slime-eval-async slime-eval-macroexpand-expression
   (slime-rcurry #'slime-initialize-macroexpansion-buffer
                ;; :WAS (current-buffer)
                 (slime-buffer-name :macroexpansion))))

Do you know of some reason why the above proposal would constitute a
breaking change?

--
/s_P\