Crash when clicking on a function name in the browser (with ccl). #3
Comments
|
Sorry, yes, it needs more work!! I've been working with SBCL exclusively so far. |
|
We have to be careful with reader macros in the protocol between slime and swank. I'll try to get the whole string next time. |
|
Here are better logs; I changed read-form in swank We get this error reported: So it looks like a string designator for package name has been used blindly and generated the wrong syntax for a qualified symbol |
|
Odd thing is I've just tried it on Clozure CL and I'm able to navigate all alexandria package functions without any problems. |
|
One particular problem I'm having with Clozure is that SWANK classifies macros as functions :( And I'm using that Swank function to determine the type of symbols. |
|
The error seems to be in
There's another occurence in You want to use |
|
Ohh. auch. Thanks for looking. |
|
I can fix that (and I will), but CCL support will remain lacking unfortunately, unless I find a straightforward and portable way of getting the source location of definitions, and I can also fix the problem I mention above (macros are given type 'function' by swank). |
|
Shinmera's |
|
I've replaced the make-symbol by intern in eb9931c but don't expect a working version for CCL yet, until I can solve what I mention above. |
Well, notice how this is a problem in the emacs lisp code, so independent of ccl. It's only that it looks like sbcl accepts 3 colons in symbol names and does something with them. (Well, more precisely "#:foo::bar" seems to be read in sbcl). But it would break in any strictly conforming implementation. Otherwise, of course you can rely on swank, and if a swank backend is missing, too bad, we'll have to post issues and patches to slime/swank. |
Once you've tested that it's corrected (perhaps you'd write unit tests? there are nice CI on github and gitlab ;-) ), you can Close the issue. |
|
You'll have to test it because for my configuration it already worked before my change, so I cannot tell whether it made a difference or not. No, I don't have tests or CI :) |
Ok, I'll pull the new version and test it tomorrow. For now, good night and thanks for this lisp browser, it'll be great! |
|
For the record, I need this patch in SWANK/CCL: (defimplementation describe-symbol-for-emacs (symbol)
(let ((result '()))
(flet ((doc (kind &optional (sym symbol))
(or (documentation sym kind) :not-documented))
(maybe-push (property value)
(when value
(setf result (list* property value result)))))
(maybe-push
:variable (when (boundp symbol)
(doc 'variable)))
(maybe-push
:macro (when (macro-function symbol)
(doc 'function)))
(maybe-push
:function (if (and (not (macro-function symbol)) (fboundp symbol))
(doc 'function)))
(maybe-push
:setf (let ((setf-function-name (ccl:setf-function-spec-name
`(setf ,symbol))))
(when (fboundp setf-function-name)
(doc 'function setf-function-name))))
(maybe-push
:type (when (ccl:type-specifier-p symbol)
(doc 'type)))
result)))So that,
and not :function |
|
I will also report an issue to swank about the disconnection upon receiving unparsable "user" message ("#:foo::bar"). We must expect some sturdiness in slime/swank when "user-level" expressions are passed over. Now, for the lisp browser, as I mentioned, the current patch makes internalise in emacs-lisp the CL symbols that are processed. This is not too good. A better solution would be to generate the CL expression as an emacs lisp string, and let swank read and evaluate it: This way, only O(1) CL symbols are interned in emacs lisp (the definition-function, and you could even use strings instead of symbols for them), and swank:eval-and-grab-output. |
|
I'm interning symbols on Common Lisp side now. Isn't it better like that? It is working on both SBCL and CCL for me. |
Apparently, an error in the reader on swank messages when browsing (clicking on a function name).
Otherwise, congrats, it looks really nice, I can't wait to be able to use it all the time. Thanks!
The text was updated successfully, but these errors were encountered: