Fork me on GitHub

Has anyone done any work converting between the format specs of :style/indent and cljfmt? I’m trying to figure out if the specs are roughly equivalent, or if there are things that one format supports that the other doesn’t.


Also, is there any way I can easily format some text using CIDER’s formatter, in a way that I can call from e.g. a Clojure program? Can I invoke Emacs on the command line to do this?


Failing that, are there any tests anywhere showing how the spec works in practice?


This has worked for me / a team setting over the years

(defn to-cljfmt-indent [{cider-indent :style/indent}]
  (or (and (number? cider-indent) [[:block
      (and (#{:defn} cider-indent) [[:inner 0]])
It doesn't cover everything, at the time I wasn't even sure that was possible because both have different conceptions, so perhaps a 1:1 mapping cannot be established Worst-case one can simply write the specs twice, once in cljfmt config and another as :style/indent metadata. In practice that very rarely happens - often it indicates an unidiomatic macro or such Hope it helps!


Great, thanks! I’m going to re-work the Cursive formatting and was keen to be able to test edge cases. I’ll probably choose one of the formats to allow users to specify, whichever maps best onto the final Cursive model.


I must admit that the cljfmt doc wasn’t especially clear on what the format means, so that helps - thanks.


> I’ll probably choose one of the formats to allow users to specify, whichever maps best onto the final Cursive model. My humble suggestion would be to favor :style/indent because it maps 1:1 to what clojure-mode can achieve, without even a CIDER connection. So one can get fast formatting in Emacs without a cider or lsp connection. And of course after getting such a connection it will work even better. It also means that one invites users to create simple specs, and accordingly, simple macros (source: I've contributed to cider and cljfmt alike, and also as mentioned I've bridged both in a particular tool. I'd love to see ecosystem complexity reduced with new tool developments!)


I definitely prefer the :style/indent spec, I think it’s much easier to understand. However it seems to me that cljfmt is what the community is settling on for a formatting solution for cross-editor teams, and it’s being used in things like commit hooks and the like. I’m worried about committing to a spec which expresses things that cljfmt can’t achieve.


I have the impression that :style/indent is a subset of what cljfmt can achieve, while cljfmt's spec is not a subset of :style/indent. So in terms of viability it would be no problem - you'd just make cljfmt use less of its potential. Don't quote me on that though :) it simply has been my experience briding both for 2+ years. But I might have a hole in my mental model, always good to understand the semantics of both approaches of course.

Drew Verlee04:02:43

I think it would be cool if there was a cider option to pick a key from a given map from the file via a UI generated list. like with your cursor as the * `(-&gt; {:hello :cat :goodby :dog} *)` when you use this hypothetical command it would move your cursor to a list with `:hello :cat` as options you could scroll through and when you picked one it inserted it. I would like input on the idea. If it seems like a good idea, ill make a github issue and then try my hand at building it. I have been learning a bit of elisp and i'm ready to fail trying to build something in another language :slightly_smiling_face:. My stand in for doing this is copying from either the printed keys or cider inspect, both work great, this would just be another option. Or hopefully, like most times when i ask a question about a new feature someone tells me it already exists.


Can you do this via paredit/lispy/etc?


i.e you slurp or barf *

Drew Verlee01:02:31

no you can't. those can slurp text that is around it. The tool i'm suggesting calls clojure.core/keys on the hash-map and then lists the outputs as options you can select from. I run into this situation quite frequently especially with a troublesomely long keyword, i don't even want to use autocomplete because usually there are a dozen like it. My currently solution is that i print the keys and copy them as needed.

Drew Verlee17:02:10

i guess what makes this idea to situational is the range of things you might want to do with the selected keywords is too large to warrant learning another keystroke in many cases. It would have to produce a lst of the keys and then you choose what you want to do with it. And thats very close to what we already have.


Is there an easy way to get the var name after cider-interactive-eval ? The returned value appears to be this:

(#[0 "\301\300!\207"
       ["[    ]" "[=   ]" "[==  ]" "[=== ]" "[====]" "[ ===]" "[  ==]" "[   =]"]
       -10 10
       [nil 25095 65080 200000 0.1 spinner--timer-function
	    nil 91298]
       nil #<buffer *cider-repl MYFILE:localhost:7002(clj)
       *> 1]


probably you're looking at an unrelated value you should get a "nrepl dict" (essentially a hashmap) and call nrepl-dict-get over it, which hopefully would have a key for the var name


Hmmm I checked again and it's really the cl-struct-spinner thingy that is returned.

(setq bbb (cider-interactive-eval (cider-defun-at-point)
				      (cider-defun-at-point 'bounds)


probably it accepts a callback as an argument which should handle the actual value most evaluation apis are async, sync ones are have a -sync suffix or such


Ahh yes I see


Thank you very much

cider 1

I quickly browsed the code, but it looks like everything is expecting a handler or a buffer. 😕


Looks like cider-test-run-test doesn't work on inline tests (those defined inside the :test metadata). A simple fix could be to remove (member deftype cider-test-defining-forms).


Note that cider-test-defining-forms is a defcustom, so you can try expanding it to also include defn If you can confirm it works for you, surely a PR is welcome to expand this default value.


Indeed it works. :thumbsup: However it means mean one would have to update it for every different defnX macro. Is this check really worth it?


Tho at this point it's probably an edge case... not many people use inline tests.


I have no idea, I didn't author that code :) I sympathize with removing the check, cider's philosophy is to avoid heuristics - normally the Clojure runtime gives us all we need. A conservative PR would simply expand cider-test-defining-forms , you can also discuss the alternative concurrently as a GH issue