"Tobias C. Rittweiler" tcr@freebits.de writes:
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
The solution in the new version of READ-FORM-SPEC is not sufficient, because it does not handle symbols interned in nested forms. [(defmethod (tyy zzz) abcd ...]
Yeah, that was a bug.
In general the "destroy-and-repair" (here: "intern-and-unintern") method is not giving a clean implementation.
I agree that it's not very clean. But it seems to be an acceptable tradeoff to me:
I do not agree, see below.
The code now only hard-interns on very obscure occasions (or so I hope!), and should not do so any more than of before my changes on the same instances.
My old code worked perfectly, it never interned anything on autodoc.
This is an essential, non-negotiable requirement, as it is invoked automatically, on pretty arbitrary stuff from buffers that is gathered by some heuristic on the Emacs side.
I do not accept replacing this by something that works "most of the time".
You simply cannot control the interning behavior of READ. Look what happens when a reader error occurs somewhere. You have no control over what symbols it has already interned when the error is signalled.
I type:
(defmethod (foo #Q)
Now:
(find-symbol "FOO") FOO :INTERNAL
And the code does actually deal with `C-c C-s' -- which, as I mentioned already, interned everything previously.
If we can achieve that, it would be great; but C-c C-s is explicitly user-invoked, so interning safety is not essential.
And I personally use C-c C-s much more often than stumbling over one of those obscure occasions.
The problem is one cannot know when the obscure occasions occur.
What you need to do -- if you want to use your proposed protocol of sending forms to SWANK -- is implement a limited reader in
(I'm open for suggestions to improve the protocol. I just tried to keep it as simple and as flexible as possible.)
I designed the old protocol (which just gathers the required information for every supported operator in a safe way) specifically to avoid READ. You either implement something like this again, or as an alternative you employ a safe restricted reader.
READ-FORM-SPEC. It only needs to handle lists, numbers, strings, and symbols to be useful in this context. It should never intern symbols and gracefully handle what would be a reader error for READ. It should not be very hard to write; give it a try.
I've thought about that before, but how is this supposed to work with `slime-complete-form' without reimplementing a whole reader?
You use the safe reader for autodoc, where safety is essential.
For slime-complete-form, you offer two modes, controlled by a user variable. One safe variant that cannot handle everything. One less-safe variant (using READ) that can handle everything.
There's currently a bug I've tried the whole day to track down,
Sorry, I don't have time to work on it. Check whether the cache works and whether there are equality issues.
Matthias