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

Bob Rogers <[email protected]>
Newsgroups gmane.lisp.ilisp.devel
Message-ID <[email protected]>
   From: Will Deakin <[email protected]>
   Date: Mon, 16 Sep 2002 10:18:14 +0100

   Bob Rogers wrote:
   > . . .
   > 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.

   I broke it so I'll try and fix it.

Great; thanks.

   >    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)
   > ...
   >    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.

   I think fixing the default package system is the right thing to do.

I agree.  But (and the paragraph above does not make this clear at all),
I think that changing ilisp-in-package-command to "(in-package %S)"
should *also* be done, as the package name arg should always be a
string, and %S will correctly escape backslashes and string quotes in
the package name (since CL and elisp string quoting syntax is the same),
if anyone is ever so foolish to name packages that way.

   This would also make many other occurrences of "\"%s\"" more robust
in ilisp-*-command format strings throughout the code -- but not all of
them, since there would be problems with passing non-strings this way.
But it's hardly urgent; the fact that nobody has reported/fixed this is
a measure of how eccentric such names are.

   In fact, speaking of %s vs. %S, it occurs to me that lisp-slashify is
entirely equivalent to the following:

    (defun lisp-slashify (string)
      "Put string in the *ilisp-send* buffer, backslashifying troublesome chars.
    I.e. put backslashes before quotes and backslashes and return the resulting
    string."
      (lisp-show-send string)	;; for side effect.
      (let ((result (prin1-to-string string)))
	(substring result 1 (1- (length result)))))

(The substring strips off the delimiting quotes, which would be
unnecessary if quotes are taken out of all format strings where this is
used to "prepare" the argument.)  Perhaps lisp-slashify is a historical
artifact, a product of older emacsen that didn't support %S?  Is it
still desirable to support these older versions?  If so, I probably
shouldn't be using %S at all . . .

   >    Anyone else want to have a go at this?

   Thanks for this. I will try. Any help you can give me would be
   appreciated.

   :)w

Thanks again.  My original post contains pretty much all I know; I
didn't try to hack on this at all.  But I'd be happy to read and test
patches, either before or after you commit.

					-- Bob


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.