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

[Madhu]

* Marco Baringer <878x1zsji9.fsf at 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