[slime-devel] Re: slime-repl-set-package should not default the current package when calling slime-read-package-name

[Marco Baringer]

Madhu <enometh at meer.net> writes:

> * Marco Baringer <87fxw7c08k.fsf at arsenic.bese.it> :
> Wrote on Tue, 05 Feb 2008 08:48:27 +0100:
>
> | Michael Weber <michaelw+slime at foldr.org> writes:
> |
> |> I do this all the time.  How about checking whether the current REPL
> |> package is the same as the default argument, in which case the default
> |> will be empty?
> |
> | that's an excellent idea.
>
> 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.

> [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. 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). slime-pretty-find-buffer-package, so therefore
slime-repl-set-package, knows how to deal with multiple in-package
forms.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen