I don't think VSCode eats that much cpu for that purpose 🙂

Good news. I got help from a real programmer to climb up out of the hole I had dug myself down in when it comes to the nrepl socket connection. So now the nrepl client code looks like so: https://github.com/BetterThanTomorrow/calva-lib/blob/talky-socket/src/calva/repl/client.cljs I have kept the API towards the Calva extension and only removed all the opening and closing of the sockets that previously embedded every message sent. That's in this branch: https://github.com/BetterThanTomorrow/calva/tree/keep-socket-open

Thanks, @pedrorgirardi! ❤️

nice!

There are still two issues, one which makes me hesitate to merge this into the main branches.

(Two issues that I am aware of and that bothers me enough to mention them, that is. I am sure there are still tons of issues hiding in there. 😄 )

"It's only 93 lines, how many bugs could there possibly be?" 🙂

Haha!

For all the bugs and issues that were there with the previous implementation it is surprising how solid the nrepl messaging was. But there is a change that the issue with people's terminals hanging could have been one of them. I certainly hope so, but I know it could be a vain hope.

Anyway, the ”sort of stopper” is that I can see that I sometimes build up cruft in the atom keeping track of which response goes with witch request. This is not enough to tidy out all that needs to be tidied out: https://github.com/BetterThanTomorrow/calva-lib/blob/talky-socket/src/calva/repl/client.cljs#L61

huh, yeah. that will ruin all the things

I need to learn a bit more about nrepl to know what to do with :status ["state"] messages for one. Calva has never used them, so just disregarding them might be the way to go.

the answer may lie in https://github.com/clojure-emacs/cider/blob/master/cider-connection.el

I guess to get this thing out of the door, avoiding that perfect gets in the way for better, is to keep track of which messages we consider handled and never accumulate them again in the *results atom. Then have it on the TODO to handle things properly.

The other, less pressing, issue is that I currently have kept the super-naive bencode decoding strategy. Which might have bugs in it, even. A moment after the connection is established I get quite a lot of decoding errors. nrepl seems to send a LOT of things to me, none of which I see the relevance in (probably because of my lack of understanding, but anyway).

Shipping this new socket handling would in this respect keep this bencoding decode quality at the same low level. 😃

🙂

yeah, I think the next big thing on the list after I get this formatter sane is to look at exactly how nrepl is used by cider

stepping through their implementation on real sessions

Re: bencode, I think the time is better spent shifting to use EDN transport. Or at least add that too the ways Calva can communicate.

it would be easier to debug edn and then backport to bencode later.

I am not sure how much benefit bencode gives you over a local connection anyway

None, probably. And there is transit transport as well.

hmm, am I calling this correctly? (reformat-string "(foo\nz\na\nb\nc)" {:alias-map '{foo [[:inner 2]]}})

can't seem to alter the formatting for foo

oh, doh. :indents not :alias-map

so, on return I now walk up the tree, working out what argument position we're at, the head of the current list, and collect the indent rules along the backbone of the whole expression tree

but this is carefully limited so we don't tank performance with large files- so you can configure it to only look up so many lines, and only up so much depth, and it will fall back to heuristic indentation in that case

also currently this is purely for indentation only, although I can obviously correct whitespace issues too later.

To me it makes sense to do the indenting with your stuff there and do formatting with cljfmt and zprint. What do you think about that?

Yeah, I think so. emacs' reformat commands are more precise than the much simpler format on type stuff

in fact, though emac's formatting rules are far simpler anyway- they don't nest deeply like cljfmts, so they have it even easier 😉

(and I am perfectly happy with just those, in my day to day coding, personally)

right, I am out for a bit, but hopefully I will have a demo up later tonight

Although currently you can see the function collectIndentState, which is working correctly to retrieve all the information required to compute the next indent.

https://github.com/mseddon/calva-fmt/blob/restartable-formatter/calva-fmt/docmirror/index.ts#L589 with the emacs-based navigation commands it's actually pretty trivial.

Okay! Have at it! the restartable-formatter branch has a prototype working implementation!

it'll do stupid stuff if its search bails at this point probably, but in general it should indent the same as cljfmt so long as its search covers enough!

so yeah, need some simple 'indent to same as last sibling expression' sort of heuristic for when that happens.

I will probably also treat any parent list on column 0 as the start, to prevent scouring too far above. I assume your code is mostly correctly formatted... otherwise you should use the proper reformatting tools

incremental calva-fmt indentation, in typescript, in 70 lines total (except for the rules of course).

paredit can be ported over to use this, too.

Yay! Can't wait to test this. (But I'll have to. On my way to a glögg-party with my family.)

If someone has some time to put my latest talky-socket for a spin, I'd be most happy. (You'll have to build it yourself from the branches mentioned above. But that's quickly done.)

@pez yeah it's a bit hectic my end for now, so I'll have to take a look later, too 😉