This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (62)
- # aws (5)
- # beginners (59)
- # calva (63)
- # cider (26)
- # cljdoc (1)
- # cljsrn (22)
- # clojure (99)
- # clojure-austin (1)
- # clojure-dev (19)
- # clojure-europe (4)
- # clojure-hamburg (2)
- # clojure-italy (3)
- # clojure-nl (23)
- # clojure-spec (2)
- # clojure-uk (85)
- # clojurescript (41)
- # core-async (17)
- # cursive (20)
- # data-science (11)
- # datascript (2)
- # datomic (31)
- # emacs (7)
- # figwheel (28)
- # figwheel-main (12)
- # graphql (2)
- # hyperfiddle (3)
- # juxt (1)
- # kaocha (2)
- # leiningen (5)
- # nrepl (13)
- # off-topic (45)
- # pathom (13)
- # pedestal (11)
- # re-frame (20)
- # reagent (10)
- # shadow-cljs (92)
- # spacemacs (9)
- # sql (39)
- # tools-deps (32)
- # unrepl (3)
@pez the principle is now working, but I've lost a lot of my incrementality now, so I tanked perf. 🙂
I was being pretty stupid- storing the line/character for the open par. So.. yeh. insert a newline and now the whole file below the edit is invalid and needs to be re-scanned. However if I use relative offsets in my state i shouldn't have to touch much at all again. Also I am needlessly re-lexing things currently since I don't differentiate between lexer state changes and paren state changes- and lexing is expensive.
And... to complicate matters I may need to worry about sibling relationships too. Again, I think incremental offsets will keep the amortized cost under control, but that requires careful management of the stack to ensure certain information is not stored, or again, we invalidate caches and throw everything through the analyser again.
so if I create a tangle of pointers to/from each paren, and re-use the object when I can... my change detection won't trigger and I can just mutate it
hairy, but it should work quite well, and handle sibling pointers without too much horror.
well- not totally, I can have a map of token 'id's and "mutate" that map to change mutable stuff
it does seem offsets are equivalent, with the added bonus of not having to make such a mess.
but there is slightly more work- because e.g. if I insert a line inside an expr, I have to tweak the relative offsets for every line within the expr
(which in the case of a giant edn file with a single toplevel form is.. oh dear. the whole file again.)
so yeah, it seems definitely that in terms of bookkeeping pointers to mutable objects are better here
bleh. long day. the
restartable-formatter branch now has a slightly buggy grow selection command "calva-fmt.growSelection"
make a clojure file that is 25k lines, and time how long Paredit: Expand Selection takes vs my one. 🙂
I dropped paren parsing globally for now, since it turns out to be faster in most realistic cases to search forward and backwards through the token stream currently, which is basically how most emacs editing things work, too.
is calva-paredit supposed to guard against deleting closing parens such that things become unbalanced?
@mattly there is a key binding in paredit settings that does this. It's a bit flaky and stops some valid deletes as well. But I use it anyway and just force delete (alt+backspace) when that happens.
@lucelios, I don’t think so. Calva does not support it (yet) and I heard something about that the extension that had this has stopped working.
I'm dipping my toes back in VSCode land today from my usual emacs+vim+parinfer setup, just to see where things are at
We haven’t moved all that far since you were in Calva land last time, but hopefully some ground has been covered.
sometimes I think I should go back to working in a language like Python just so I'm not tempted to chase the perfect setup
Thanks. Right now I think Calva work need to be focused some on quality before we can shift to more fun things again. And that’s quality of the code as well as the Ux. Especially for beginners I think the bar is still too high.
it's good, but not as good as Atom's, and falls down quite a lot with clojure indenting
you have to hit return in insert mode from the end of the above line to insert a line with the correct indent
I'm using a hardware-programmable keyboard and have been working on a vim-like navigation "layer" for it
@mattly, if I recall correctly the VSCodeVim allows you to string commands together. If that is the case, Calva Formatter could expose an Indent Current Form command and then you could tie the
o/O keys to first open a new line and then indent it. Let me know if you think this would work.
if I run
calva format: indent line from the command palette it also only indents to one space