mmontone
commented
3 years ago Sorry, yes, it needs more work!!
I've been working with SBCL exclusively so far.
Open informatimago opened 3 years ago
mmontone
commented
3 years ago Sorry, yes, it needs more work!!
I've been working with SBCL exclusively so far.
informatimago
commented
3 years ago We have to be careful with reader macros in the protocol between slime and swank.
ccl has a few additional dispatching reader macros on the default *readtable*.
30: (common-lisp:read-from-string "(:emacs-rex (esb:serialize-for-emacs (def-properties:function-properties '#:COM\\.INFORMA..I'll try to get the whole string next time.
informatimago
commented
3 years ago Here are better logs; I changed read-form in swank rpc.lisp:
(defun read-form (string package)
(with-standard-io-syntax
(let ((*package* package))
(if *validate-input*
(validating-read string)
(handler-case
(read-from-string string)
(error (err)
(format *terminal-io*
"~&Error while reading from the string: ~%~S~2%~A~%"
string err)
(finish-output *terminal-io*)
(if (typep err 'reader-error)
(error 'swank-reader-error
:packet string
:cause err)
(error 'swank-reader-error
:packet string))))))))We get this error reported:
Error while reading from the string:
"(:emacs-rex (esb:serialize-for-emacs (def-properties:function-properties '#:ALEXANDRIA::CIRCULAR-LIST t)) \"COMMON-LISP-USER\" t 12)
"
Reader error: Illegal symbol syntax.So it looks like a string designator for package name has been used blindly and generated the wrong syntax for a qualified symbol #:alexandria::circular-list.
mmontone
commented
3 years ago Odd thing is I've just tried it on Clozure CL and I'm able to navigate all alexandria package functions without any problems.
mmontone
commented
3 years ago One particular problem I'm having with Clozure is that SWANK classifies macros as functions :(
CL-USER> (swank::describe-symbol-for-emacs 'anaphora:aand)
(:FUNCTION "Like AND, except binds the first argument to IT (via LET) for the
scope of the rest of the arguments.")And I'm using that Swank function to determine the type of symbols.
informatimago
commented
3 years ago The error seems to be in esb:update-definition-buffer with the use of make-symbol:
(let* ((definition-properties (slime-eval `(esb:serialize-for-emacs (,definition-function ',(make-symbol (concat package "::" definition)) t))))(make-symbol (concat "FOO" "::" "BAR")) --> #:FOO::BAR
There's another occurence in esb:update-documentation-buffer.
You want to use intern here! And yes, it's a bummer that we have to intern a lot of qualified CL symbols in emacs lisp!
mmontone
commented
3 years ago Ohh. auch. Thanks for looking.
mmontone
commented
3 years ago 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).
mmontone
commented
3 years ago Shinmera's definitions library probably implements what I need, but I didn't go that path...
mmontone
commented
3 years ago I've replaced the make-symbol by intern in https://github.com/mmontone/lisp-system-browser/commit/eb9931cd0d6b9d0d0259bf0e108b1ea889167ae2
but don't expect a working version for CCL yet, until I can solve what I mention above.
informatimago
commented
3 years ago 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).
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.
informatimago
commented
3 years ago 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.
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.
mmontone
commented
3 years ago 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 :)
informatimago
commented
3 years ago 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!
mmontone
commented
3 years ago 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, (swank::describe-symbol-for-emacs 'anaphora:aand)
gives me
(:MACRO "Like AND, except binds the first argument to IT (via LET) for the scope of the rest of the arguments.")
and not :function
informatimago
commented
3 years ago 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:
(slime-eval
`(swank:eval-and-grab-output
,(format "(esb:serialize-for-emacs (%s '%s::%s t))"
definition-function package definition)))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.
mmontone
commented
3 years ago 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.
https://github.com/mmontone/lisp-system-browser/commit/4561f7d02d57d5fe1b4484f148641c6b809eefda
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!