Fork me on GitHub
#calva
<
2018-12-18
>
mseddon12:12:33

@pez the principle is now working, but I've lost a lot of my incrementality now, so I tanked perf. 🙂

mseddon12:12:44

I can see ways around it though

mseddon12:12:59

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.

mseddon13:12:06

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.

pez13:12:54

Relative offsets sounds like the way to go.

mseddon13:12:22

I think I have one better... more mutation 😉

mseddon13:12:16

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

mseddon13:12:35

hairy, but it should work quite well, and handle sibling pointers without too much horror.

mseddon13:12:10

I am still only considering this though, filling up a wastebasket with paper atm

pez13:12:19

Sounds like it will get harder to get over to cljs? 😀

mseddon13:12:25

exactly 😉

mseddon13:12:48

well- not totally, I can have a map of token 'id's and "mutate" that map to change mutable stuff

mseddon13:12:15

but that winds up more opaque to me personally in clj

mseddon13:12:05

it does seem offsets are equivalent, with the added bonus of not having to make such a mess.

mseddon13:12:53

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

mseddon13:12:16

(which in the case of a giant edn file with a single toplevel form is.. oh dear. the whole file again.)

mseddon13:12:45

so yeah, it seems definitely that in terms of bookkeeping pointers to mutable objects are better here

mseddon13:12:13

effectively this is (sort of) a bidirectional mutable tree mess.

mseddon18:12:29

bleh. long day. the restartable-formatter branch now has a slightly buggy grow selection command "calva-fmt.growSelection"

mseddon18:12:59

make a clojure file that is 25k lines, and time how long Paredit: Expand Selection takes vs my one. 🙂

mseddon18:12:12

(just. ignore the slight bugginess).

mseddon18:12:46

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.

mattly18:12:37

is calva-paredit supposed to guard against deleting closing parens such that things become unbalanced?

pez18:12:39

@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.

mattly18:12:34

auto-closing brackets?

pez18:12:41

No, I think it's named "strict".

pez18:12:14

Not by a computer, so can't check.

pez18:12:50

I'm pretty sure I added something in the readme about it.

mattly18:12:39

ah, default key map

cupello18:12:04

Hi folks! Is there a way to debug clojure with vscode?

pez18:12:44

@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.

pez19:12:33

@mattly, yeah, that. Probably we can make a much stabler version of this with @mseddon’s work, sometime soon. Then we can make it the default.

mattly19:12:23

I'm dipping my toes back in VSCode land today from my usual emacs+vim+parinfer setup, just to see where things are at

pez19:12:09

We haven’t moved all that far since you were in Calva land last time, but hopefully some ground has been covered.

mattly19:12:26

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

mattly19:12:20

you're doing great work though!

mattly19:12:26

i think i might just need to ditch VSCodeVim though

pez19:12:46

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.

mattly19:12:50

it's good, but not as good as Atom's, and falls down quite a lot with clojure indenting

pez19:12:14

How does it fall down with the indenting?

pez19:12:57

VS Code’s API is far from ideal for a VIM emulation.

mattly19:12:11

using o/O just kicks you to the beginning of the line

mattly19:12:36

you have to hit return in insert mode from the end of the above line to insert a line with the correct indent

pez19:12:46

Hmmm, maybe that can be fixed (the o/O thing).

mattly19:12:16

I'm using a hardware-programmable keyboard and have been working on a vim-like navigation "layer" for it

mattly19:12:46

it's mostly vim's operator-style combinations I find myself missing

pez19:12:20

Calva Formatter currently monitors \n in the onType handler…

pez19:12:53

@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.

mattly19:12:13

sure, I can give that a shot

pez19:12:33

I’ll pack a VSIX for you, with that command exposed.

pez19:12:21

@mattly, try installing this package. It exposes a command Indent Current Form.

mattly22:12:47

I'm not having any luck, though it's possible I set this up wrong:

mattly22:12:21

I have to hit o twice, and the second time it just does the insert line command

mattly22:12:19

if I run calva format: indent line from the command palette it also only indents to one space

mattly22:12:09

in non-clojure buffers, o works as expected, and puts the cursor at the right place

mattly22:12:27

maybe I just need to dig further into what it's doing