This is perhaps really a problem with forward-sexp, not so much a slime issue, but I'll bring it up here anyway:
I recently played around with creating a reader macro for the #; combination. But then I found that trying for example
(foo #;bar)
then I would only get [input not complete] in the minibuffer. Perhaps forward-sexp should be taught that a semicolon after a sharpsign doesn't start a comment? This can get tricky if someone were to write #1#; of course. ...
- Harald
Harald Hanche-Olsen hanche@math.ntnu.no writes:
This is perhaps really a problem with forward-sexp, not so much a slime issue, but I'll bring it up here anyway:
I recently played around with creating a reader macro for the #; combination. But then I found that trying for example
(foo #;bar)
then I would only get [input not complete] in the minibuffer. Perhaps forward-sexp should be taught that a semicolon after a sharpsign doesn't start a comment? This can get tricky if someone were to write #1#; of course. ...
We have `slime-forward-sexp' which uses a somewhat more common-lisp'ey read syntax. This was written for looking up compiler notes but has since been superseded for that purpose. It has some note-lookup quirks (like skipping over forms that are reader-conditionalized out) but might make a useful basis for this kind of extension.
Harald Hanche-Olsen hanche@math.ntnu.no writes:
This is perhaps really a problem with forward-sexp, not so much a slime issue, but I'll bring it up here anyway:
I recently played around with creating a reader macro for the #; combination. But then I found that trying for example
(foo #;bar)
then I would only get [input not complete] in the minibuffer. Perhaps forward-sexp should be taught that a semicolon after a sharpsign doesn't start a comment? This can get tricky if someone were to write #1#; of course. ...
In theory you could use syntax properties for this. E.g.,
(setq font-lock-syntactic-keywords '(("\(#;\)" 1 "'"))) (setq parse-sexp-lookup-properties t)
tells emacs that #; should be treated like ' for parsing.
In practice this doesn't work so well because it relies on font-lock mode and the SLIME REPL doesn't use font-lock.
If this is very important, you could modify slime-repl-return so that it adds the syntax-table property to occurrences of #; before testing whether the expression is complete.
Helmut.
+ Helmut Eller heller@common-lisp.net:
| If this is very important, you could modify slime-repl-return so | that it adds the syntax-table property to occurrences of #; before | testing whether the expression is complete.
It is not terribly important to me, other than in the general sense that correctness is important. 8-)
I looked a bit into the implementation of forward-sexp and found that it relies on the emacs builtin scan-sexps, meaning it is perhaps a bit difficult to override in lisp. However, the variable parse-sexp-lookup-properties seems to offer some hope.
- Harald
-
Harald Hanche-Olsen -
Helmut Eller -
Luke Gorrie