This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (76)
- # announcements (6)
- # beginners (103)
- # boot (28)
- # calva (128)
- # cider (48)
- # cljs-dev (40)
- # clojure (268)
- # clojure-austin (2)
- # clojure-dev (2)
- # clojure-europe (47)
- # clojure-italy (10)
- # clojure-nl (17)
- # clojure-spec (2)
- # clojure-uk (15)
- # clojurescript (45)
- # code-reviews (14)
- # cursive (5)
- # data-science (2)
- # datascript (1)
- # datomic (52)
- # duct (4)
- # emacs (2)
- # figwheel (1)
- # figwheel-main (4)
- # fulcro (13)
- # hyperfiddle (51)
- # leiningen (19)
- # nrepl (40)
- # off-topic (45)
- # pathom (3)
- # pedestal (28)
- # portkey (7)
- # re-frame (25)
- # reagent (76)
- # reitit (7)
- # shadow-cljs (92)
- # slack-help (3)
- # specter (5)
- # timbre (2)
- # tools-deps (39)
- # unrepl (1)
- # vim (13)
https://github.com/mseddon/calva-fmt/tree/restartable-formatter so this is now still a bit too eager, but is incrementally lexically analysing the entire source file correctly.
need to optimize it a little bit more- since e.g. if you type " in a file, now you have inverted the ENTIRE document's state as inside and outside a string. So this needs to be lazily computed when necessary rather than rescanning everything below the line that changed.
still, once this is handled, we should be able to amortize everything really nicely, and have a very fast way to find the enclosing sexpr at any part of the file
I will be tracking the enclosing sexpr, the indentation rules for that sexpr based on the start symbol + a table, as well as the index this expr is in it's parent, which should be enough to recreate cljfmt
but then- finding the required indent will be O(1) for extremely small 1, so everything should indent instantly like it does with e.g. typescript
it will also allow us to grab exactly the lines required to pass to cljfmt and parinfer
We will need to be able to feed it custom cljfmt configs, but from what I hear that is not a problem, right?
some more advanced settings- i am not sure how they work yet, but we can address those later 🙂
I use a js edn reader for Calva today, but found that it is to flaky, will switch to doing it via calva-lib, since now Calva has that in reach.
hi guys I see there has been a lot of chat since I visited this channel last time. Recently I heard of Tree-Sitter API added to Atom for source code parsing. Is it going to be added to code? Any idea if Calva can use it?
if a source file has errors in it, and if I evaluate the file, I am not seeing the stack trace
regarding tree-sitter- I am implementing a similar thing but specifically for calva/clojure
oh okay. why not just take the Tree-Sitter bindings. The reason is we can get all the future bug fixes for free
it is interesting, since it's fairly easy to write an incremental parser for lisp, but they are using some far more complex research to handle lalr languages
Tree-Sitter is probably not coming to VS Code. They are considering adding it temporarily until they get the parser ported from Visual Studio.
But we need only parse clojure code, which is less complex than the task Tree Sitter has to perform.
but the nice thing is I can build incremental edits to sync that up further down the line
just curious, have you seen the source code of emacs packages that do code parsing?
really it doesn't do much 'parsing', but it tracks lexical state across lines so e.g. it doesn't get confused by an opening '(' inside a string while looking back
for the bulk of the work, we just need to know at any position in the file what the extent of the sexpr is, and the formatting rules that apply
so this incrementally lexes the lines as you type, and marks lines as 'dirty' if some change has caused us to e.g. move into a multiline string, which is very cheap
yep. so in addition to the state 'are we in a string?' we store the stack of parenthesis types, along with their opening symbol and indent
but this lets me VERY quickly determine what the indent should be when you press return, so we will lose that delay before everything lines up correctly
currently I have similar issues with my lexer, although hopefully it won't be too terrible. But if you try creating a file currently with say 25k lines of clojure
and then press 'enter' in it, you'll see we have a terrible delay before the indent happens
will writing the parser in rust and generating wasm bindings help with the performance?
I started working on Rust wasm generation sometime back when I heard of wasm and webcomponents
so since this is relatively simple to write, I will start here and then port it over to something faster if we need it
it doesn't do anything to the editing experience yet, but it's mirroring the state of the lexical analyser inside the calva-fmt/docmirror directory
oh, it's now also not updating the lexical information for lines that weren't directly edited unless
flushChanges is called, which should bring everything back to consistency again.
oh okay. I don't know how to test vs-code plugins yet.. a bit behind on the learning curve
In the case of this- you should be able to check out that branch,
npm i the dependencies, and start ts compiling with
npm run watch-ts.
Then press F5 and you'll launch a vscode debug instance. It'll warn that
calva-fmt has been replaced (but that's expected, since.. it has been swapped out for the new version here)
you can then stick breakpoints in etc and poke around and see what is happening, although other than maintaining that data structure, there is no user-visible behaviour yet
I am hoping to have it working somewhat at the end of the week though, and it would be great to have some early testers on it to flush out all my bugs 😄
desperately trying to get calva there. I am sick of having to switch to emacs whenever I use clojure 🙂
I have high hopes for the project though, the issues primarily are due to lack of time and other contributors.
I can understand that. It's a pain all over the clojure community. So many developers for JS but too few in CLJS
About the stack trace, @manas.marthi, I am aware of that those are often swallowed by Calva, but I would appreciate an issue filed so that I get reminded about it, preferably with some small repro.
huh. with a 25k line file even reconciling the lexer for the entire file is fast for me. 🙂
I need some aggressive tests, and I realised I can be even lazier with reconciliation, because I can ask "I need everything from this position up to the next N close parens", so it can bail early there, too
basically at the moment I can instantly get the parenthesis stack and the source locations of them for the start of any line in the file. so that's nice.
(I can also immediately detect mismatched close parens, but I don't do anything about that atm)
And if that close paren is a few lines down and we are deeply nested inside expressions i only have to reconcile up to the first ) in that case
Cool. Maybe it's time to replace paredit.js, at least for when we use it to figure out the current form. There are a few evaluation commands in Calva that use that.
Yeah. It's probably not too hard to do lexical slurping and barfing with this, actually
Oh, they are those little bits along the top of the editor. Currently you have the directory path but we can show the heads of each expression, too.
Of course that can be done via nrepl, but seems to be a perfect match for static analyze.
I have an interesting edge-case. I have the following in my editor:
When I have my cursor on the second line, in column 0, before the opening paren (the editor highlights the matching parens around
;(clojure.test/test-vars [#'get-namespace-works]) (clojure.test/run-tests)
(clojure.test/run-tests)), and I hit “Evaluate current top level form”, it evaluates the common on the first line:
Evaluating: ;(clojure.test/test-vars [#'get-namespace-works]) Evaluation failed for unknown reasons. Sometimes it helps evaluating the file first.