* Marco Baringer 878x1zsji9.fsf@arsenic.bese.it : Wrote on Tue, 05 Feb 2008 12:57:50 +0100: |> If you are going to change this function, you should note that currently |> `slime-repl-set-package' ends up calling `slime-search-buffer-package' |> to fill in the default, which would be the wrong function to call if |> `slime-repl-set-package' is invoked in the REPL, as it would always |> return `nil' -- thereby leaving an empty default. | | right, that's why it'd be smart to use slime-current-package.
I decided not to update now so I won't see what you have done. However if you followed the call chain:
slime-pretty-find-buffer-package -> slime-find-buffer-package
it should have been clear that what ought to have changed is the value of the variable `slime-find-buffer-package-function' which was already factored out for customization.
|> [Also, the behaviour of `slime-search-buffer-package' is what makes it |> useful in invoking `slime-repl-set-package' in a file looking at a lisp |> buffer, and is dependent on where the cursor is -- so a repl shortcut |> would probably not cut it. My *slime-scratch* file for instance has |> several cl:in-package forms] | | i have no idea what you're talking about here.
This was in response to another suggestion from Nikodemus in this thread http://permalink.gmane.org/gmane.lisp.slime.devel/7021
About why the proposed `R' repl shortcut may not work very well.
| slime-repl-set-package, which is also a shortcut function, uses | slime-pretty-find-buffer-package (it won't for much langer but the | functionality remains the same).
Again, this would have been unnecessary if you had followed the call chain above.
| slime-pretty-find-buffer-package, so | therefore slime-repl-set-package, knows how to deal with multiple | in-package forms.
-- Madhu