Get flycheck working with CIDER?
Closed this issue · 18 comments
I recently checked out the competition by looking at the cursive presentation from the conj and as an IDE the syntax checker / linter is something that CIDER is missing atm. Any thoughts on how hard this would be? Could we get some quick wins by adding the following functionality?
- Highlighting of wrong-arity calls
- Unused locals
One sufficiently motivated could probably hook up jonase/eastwood with some after-save hooks to trigger re-linting of saved files and a compile mode to process output.
attempting to implement a linter inside of CIDER is, I would argue, a total waste of time when we have a perfectly good one sitting right over there.
Flycheck hooks into various backends which do the actual linting and will handle everything else. I suppose I should have worded my question a bit differently: Do we have a suitable backend for flycheck?
Looking at jonase/eastwood it seems to do everything we'd want, and more.
We're essentially waiting for flycheck/flycheck#524 to close, which provides a new API for more generic checkers.
@magnars Is this something you've already been prototyping, or was that just for kibit?
The caveats about running eastwood in a repl makes it sound like we might want to run this linter in another subprocess. Is that something you considered?
I made a plugin to flycheck that ran kibit, but it was horribly slow since it shelled out to lein instead of using nrepl. I've put my efforts on hold, waiting for 524. This time around I was planning on using eastwood, but I haven't looked much into it yet.
Any seen this? https://github.com/pnf/squiggly-clojure @pnf
This looks cool. Still think something like this should be part of cider itself.
Isn't cider itself quite large enough already? Include it under clojure-emacs, for sure.
The latter is definitely happening, but I think there's a good argument for either this or something similar being part of core cider. A choice of IDEs with non-intrusive, background code inspection is a significant driver of the popularity of Java, and the corresponding lack is an impediment to the adoption of Clojure (or at any rate is used as an argument against adopting it).
I'm an emacs power-user so I'm quite used to installing 100 small packages and configuring them, but when someone new to clojure is told "emacs is the best environment for lisp development" I can imagine the pain of getting started. Not only do you have to learn a new tool, but you also have to track down tons of packages just to get functionality you get for free in other editors. After that comes the configuration in elisp.
All users have the burden of keeping their config up to date as well. For projects like cider, squiggly-clojure and clj-refactor I have to update both my .emacs and my profiles.clj in order to get new functionality.
We're all striving for simple things in the clojure community, but sometimes--especially in the context of tooling--it makes sense to favor easy.
I'm OK with pulling squiggly-clojure into CIDER proper.
On a related note - I hope that one day clj-refactor (or at least some parts of it) will be incorporated into clojure-mode and cider for the very same reasons. We should provide our users with more power by default.
👍
You're making compelling arguments. 👍
Cool. Lets get this over to clojure-emacs to increase visibility for early adopters. Then let it bake a little, and when most kinks are sorted out merge it into CIDER.
Including its Clojure library?
On Dec 19, 2014, at 13:13, Lars Andersen notifications@github.com wrote:
Cool. Lets get this over to clojure-emacs to increase visibility for early adopters. Then let it bake a little, and when most kinks are sorted out merge it into CIDER.
—
Reply to this email directly or view it on GitHub.
yes