Luke Gorrie luke@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.