@pez I’m really enjoying Calva for vscode! One question. The code formatting you and your team have implemented for Calva that adheres to this guide: https://github.com/bbatsov/clojure-style-guide is excellent, but it differs in output from the clj-format library used by calva-format. Any plans long term to make calva-format use your custom code formatter?
Good to hear, @nick652! Can you give an example for where the output differs? It is not supposed to differ.
Sure, here’s one rule from that guide that Calva gets right, but calva-format (clj-format) gets wrong: https://github.com/bbatsov/clojure-style-guide#one-space-indent
(or this that)
clj-format doesn’t seem to have a concept of “single-space indented forms”
I’ve noticed a couple other discrepancies while writing code, but I didn’t write them down and I’m having some trouble recalling the specifics. Happy to add more detail as I encounter it. I figured I’d ask here before logging anything in github in case it’s as-designed (since calva-format intentionally uses a different lib).
Thanks for the quick response, by the way.
The whole thing is a bit confusing because different formatters are in play. The formatting done by Calva still (which is a leftover from when we moved the formatting from Calva to calva-fmt) is actually ”just” a way to try get the cursor at the right place when entering new lines. It’s a very naive implementation that (sometimes) fails when comments and strings have brackets. I was hoping we should be able to use the same module as calva-fmt uses for that task too, but maybe it is not one-indent form aware. Maybe @pedrorgirardi knows more about that.
Formatting is one of those things which seems incredibly simple, until you actually do it….2👍
great post! I really like Bob Nystrom’s writing.
Yeah, Bob is awesome.
@pez that makes sense. I haven’t encountered any discrepancies that are a huge deal. I mainly figured I’d ask about it here since I was surprised to see the great work of the Calva extension get tweaked when I run calva-format with cmd+shift+p > “Format Doc”
Thanks for alerting us to it. I really would like formatting to be fully automatic and as-you-type. But that might be a pipe dream. We will keep trying for Calva Formatter to be as helpful as possible.1👍
just to clarify, I’ve preferred the “as-you-type” output in every case, so it’s working great for me in that regard
@pez yeah, it’s great - it comes up on Hacker News from time to time, and generally has interesting comments too.
I am glad to hear! It gives me guidance when re-implementing the feature in Calva Formatter, where it will be done in clojurescript instead. Also, we will need to figure out if we can get cljfmt to not undo it, right @pedrorgirardi ?
@nick652 Also, note that the style guide is contentious in some areas, and particularly around 1-space indents: https://groups.google.com/d/topic/clojure/ihiEerO3trA/discussion
there was a big kerfluffle about indentation of
(-> ...) as well
See that discussion, and various linked issues, e.g: https://github.com/clojure-emacs/clojure-mode/issues/266, https://github.com/clojure-emacs/clojure-mode/issues/265, https://github.com/clojure-emacs/clojure-mode/issues/235
those are good reads
Yeah, that one is in there 🙂
my coworkers go back and forth whether arguments on the next line are aligned with the first argument or indented two spaces. lots of ways to argue about indentation
I tend to argue these things a lot, because it’s often the case that what people think of as “what lisp needs to do” often boils down to “that’s what emacs does, and it’s hard to change”
also, at some point your codebase looks like what it looks like. can't just go changing it whenever you open a file
i think the single comment
; is brutal in emacs. i think that is hard coded to go over to the right margin
Right. I’m actually totally in favour of prescribed language formatting these days ala gofmt
That ship has sailed for Clojure, but any new language should totally do that.
yeah starting with that is the ticket
i think elm is like that as well.
Oh yeah, I had that
; discussion recently too. Again, it started out as “Cursive is clearly wrong” and ended up as “Emacs is hard to change” 🙂
I’m going to have to support that just for mixed teams’ sanity.
well i hope your customers appreciate what you do for them. it is not particularly fun. but you sure do make a professional environment for them
Yeah, generally they’re very appreciative - I’m lucky!
Lots of Cursive is really fun to work on, but lots is not too, you’re right (leiningen, I’m looking at you)
A funny story about customer appreciation was when I finished the current lein integration, which was something like 3 months of blood sweat and tears. I think I closed 25 issues with that change. At the last moment, I also added the CLJS community icon for CLJS files, a change which literally took 5 minutes.
cljs was fast for you?
After the release, everyone was like: OMG! CLJS FILES NOW HAVE THE ICON!!!>!>!>!
There was something like a 30-tweet thread on twitter about it.
little polish can go a long way ha
i thought you meant you enabled cljs support and "it took 5 minutes" lol
I’m going to change an icon on every release 🙂
make it animated while the repl is processing
Haha, no, that was more blood sweat and tears
yeah. so many different ways things can work
I like that
Yeah, CLJS is tough, and it’s hard to keep up with
It’s really complex now.
i wish we could all standardize on one thing and that was what cljs looked like. like figwheel is blessed. that's what we use. or everyone only uses shadow-cljs and the compiler will always have a front end on it
Yeah, again more closed ecosystems like Elm get some wins there
@cfleming yeah there are
a lot probably a few things in that style guide where I might disagree if pressed for an opinion. But as for Calva, I was only wondering what the goal was for parity between the vscode features it provides: realtime formatting, and the “Format Document” implementation.