[slime-devel] Re: Broken readtables

[Helmut Eller]

Luke Gorrie <luke at bluetail.com> writes:

> Nobody sets it for definition-finding. That's reasonable in swank.lisp
> since it doesn't know what package the definition will be in. Perhaps
> ideal would be for dspec-stream-position to set the right readtable
> (from *readtable-alist*) when it sees IN-PACKAGE. I'm not sure if the
> other backends can/should do this too. We'd have to move
> *readtable-alist* into swank-backend.lisp.

For CMUCL/SBCL, at least, we don't look at the IN-PACKAGE forms.
*read-suppress* is T most of the time and we only look at the "shape"
of the expression.

> But I suspect the main issue right now is to make sure that a
> custom-hacked readtable that one installs globally as *READTABLE* will
> be used by `M-.'. That's how I do my readtable'ery, at least.

Yeah, and it's probably what 99% of the users do.  People who use
multiple readtables deserve to loose :-)

> P.S., Helmut, I think I was sleeping when *readtable-alist* when
> in. Could you post a snippet of how it's supposed to be used?

It went in with the other SBCL reader stuff.  Say you have a package
foo and readtable *bar* then you could use it like:

  (push (cons (package-name :foo) *bar*) swank::*readtable-alist*)

swank::eval-for-emacs uses this to bind *buffer-readtable*; the
current readtable will be used if there's no entry in the
*readtable-alist*.  

`with-buffer-syntax' can then be used to actually bind *readtable* to
*buffer-readtable*.  I replaced most uses of

  (let ((*package* *buffer-package*)) ...) 

with the idiom:

  (defslimefun <foo> (...)
    (with-buffer-syntax () ...))

All this is currently only used for SBCL and I don't know if
*readtable-alist* is very useful for users.  I assumed it is more
convenient to associate readtables with packages than to use
Emacs-style file variables, ala -*- readtable: ... -*-.  OTOH, file
variables would be handy when find-definitions opens an arbitrary
file; we could just look at the first line.

Helmut.