* 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