[slime-devel] Strange behavior in edit-definition

Antonio Menezes Leitao aml at gia.ist.utl.pt
Mon Jun 13 22:58:21 UTC 2005


Hi,

Helmut Eller <heller at common-lisp.net> writes:

> Antonio Menezes Leitao <aml at gia.ist.utl.pt> writes:
>
>> and maybe it was that 'package' variable being referenced after
>> changing to a different buffer that was causing the problem.  An hard
>> to believe explanation, I'm sure, but just in case, I experimented
>> replacing that 'package' variable by another gensym, using:
>
> I can believe that.  The reason for problems like this are those 
> -*- package: ... -*- file variables.  This make package a buffer local
> variable in Emacs and interacts badly dynamic bindings.  E.g.:
>
> (progn
>   (make-variable-buffer-local 'my-var)
>   (setq my-var 1)
>   (message "%s" my-var)
>   (let ((my-var 2))
>     (message "%s" my-var)
>     (with-temp-buffer 
>       (message "%s" my-var))))
>
> my-var in the temp buffer is nil.  One would think that a simple rule
> like: first search let-bound variables, then buffer local variables
> and then global variables would avoid such problems but this is
> obviously not what Emacs does.
>
> It's probably a good idea to avoid the -*- package: ... -*- thing as
> the file has probably a in-package form already or a least rename it
> to Package.
>
> I committed you change.  Thanks.

Here's another one that is causing problems:

(defun slime-repl-set-package (package)
  "Set the package of the REPL buffer to PACKAGE."
  (interactive (list (slime-read-package-name "Package: " 
					      (slime-find-buffer-package))))
  (with-current-buffer (slime-output-buffer)
    (let ((unfinished-input (slime-repl-current-input)))
      (destructuring-bind (name prompt-string)
          (slime-eval `(swank:set-package ,package))
        (setf (slime-lisp-package) name)
        (setf (slime-lisp-package-prompt-string) prompt-string)
        (slime-repl-insert-prompt "" 0)
        (insert unfinished-input)))))

Again, using pkg in place of package solves the problem but, as you
explained, the problem seems to be on Emacs and not on Slime.

Thanks for the explanation.

António Leitão.



More information about the slime-devel mailing list