ilisp-fallback-package is in the wrong format for lisp-buffer-package

   The easiest way to make lisp-buffer-package break in an obvious way
is to type the following to emacs:

    C-x C-f foo.lisp RET (in-package C-q SPC :no-such-package) RET (defun SPC

After you do this, the new foo.lisp buffer will look like this:

    +--------------------------------------------+
    |(in-package :no-such-package)		 |
    |(defun					 |
    +--------------------------------------------+

And the SPC will make ilisp-arglist-message-lisp-space blow its cookies;
an empty "ILISP Arglist Output" frame appears on the screen, and the
Lisp buffer appears with the message:

    "ILISP: 
    Error in function ILISP:ILISP-FIND-PACKAGE:  package :common-lisp-user not found"

displayed in it.  Since the package is not cached in this case, the
error is readily repeatable by rubbing out and retyping the SPC.
A little investigation shows that ILISP is doing the equivalent of
(find-package ":common-lisp-user"), not (find-package :common-lisp-user).

   I see three problems here:

   1.  The first problem is that the package default doesn't work.  The
immediate culprit seems to be that ilisp-check-package-advanced returns
":common-lisp-user" here, but if "(in-package :common-lisp-user)" were
present in the buffer instead, it would return "COMMON-LISP-USER", since
that's what PACKAGE-NAME in the Lisp returns, and that's the form the
rest of ILISP expects from lisp-buffer-package.

   The initialization of ilisp-fallback-package to ":common-lisp-user"
in defdialect common-lisp would seem to be at fault.  However, the
obvious change to the source at this point would break case-sensitive
Lisps.  The most robust thing might be to have the default be the string
"(in-package :common-lisp-user)" and then run THAT through the
ilisp-check-package-advanced magic; this amounts to a change in the
semantics of ilisp-fallback-package.  But the package init code seems
fairly convoluted; I'm not sure I want to touch it . . .

   2.  A second, related problem is this incongruous defvar at the top
of the ilisp-snd.el file:

    (defvar *ILISP-default-package* :common-lisp-user)

Since ilisp-in-package-command is "(in-package \"%s\")" (for CMUCL), so
it is equally broken.  It is only used by set-package-lisp-always,
though I can see no reason why it should not stick to the
ilisp-fallback-package protocol.

   As an aside, this immediate problem could be fixed by changing
ilisp-in-package-command to "(in-package %S)", since that allows both
emacs string and symbol values to be parsed as such in the Lisp.  But
this fix is harder to generalize for ilisp-fallback-package, since the
result is used in more places.  And it doesn't address the code
duplication issue.

   3.  Finally, we get to the fact that ilisp-arglist-message-lisp-space
is not very robust when lisp-buffer-package returns a bad package.  But,
on reflection, this is not surprising.  lisp-buffer-package tries very
hard to return something valid, despite the fact that the function
documentation states, "If there is none, return NIL."  So, presumably
the return convention has been changed, and
ilisp-arglist-message-lisp-space has come to rely on that.  Better to
fix the underlying problem (and the documentation), then.

   Anyone else want to have a go at this?  It's a nuisance, but only if
you mistype a package name, or start pouring code into a buffer before
loading the definition for its package.  Even then, it's not a very big
nuisance.  (I'm afraid I fall too easily into "report writing mode," and
then I type too much.)

					-- Bob Rogers
					   http://rgrjr.dyndns.org/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf