Just installed it...very happy to see structural editing! Aaand immediately I want more features! Can we have a feature to allow any function (that follows some specification) to be bound to a key so that it can be applied to the selected expression ? This would allow for functional editing or even editing based on core.logic and core.match.
Also can we have function application graphs (which functions use which other functions) ? BTW I will gladly pay/donate for/to your work - nice one!
Hmm, the functional editing idea is interesting - can you drop me an email at the address on the webpage to discuss? I'd like to know what you have in mind for that. Function application graphs would be great too, and could be built off the resolution functionality.
Cursive is based off a fork of La Clojure from a long time ago. Since then I've rewritten 80% of the code in Clojure and added a lot of new functionality and fixed a lot of bugs. There's lots of new stuff in there, but the main highlights are Paredit-style structural editing and good nREPL integration (for local and remote REPLs). Jan Thomä also kindly let me bundle the leiningen plugin so that's provided out of the box and I'll be making a lot of improvements to that over the next couple of weeks. All the beta testers have said it's a great improvement over La Clojure. Unfortunately La Clojure has never been a priority for JetBrains, which is what let me to start work on this a while back.
I'm planning to release this as a commercial PyCharm-style IDE, at a similar price point. I've done this in consultation with JetBrains, in case anyone's concerned about that.
Awesome. I've only been playing with Clojure for a few months but IntelliJ IDEA has been my go-to IDE for a long time now so all of that time has been spent with La Clojure + Leiningen plugin and I've always felt that it was a little clunky (and that the Leiningen plugin was a bit of a 2nd class citizen). Hopefully a little TLC and a cohesive vision can yield something that's much nicer to work with. Looking forward to seeing where this project ends up.
As far as I understand, Cursive will be available both as a plugin and as a standalone IDE, right?
What will be the added value of standalone IDE?
PyCharm is a subset of IDEA Ultimate + Python plugin, will it be the case with Cursive? In other words, does it make sense to buy Cursive IDE for users who already have IDEA Ultimate?
The standalone IDE will be useful for people getting started with Clojure, since it'll provide a more integrated experience - we bundle lein so that Windows developers don't need to download and install it to get going, for example (although this is currently not exposed to the user, coming soon). Clojure is great but the getting started experience is still not great for total newbies. I hope to provide a great environment that'll be basically a one-click download to get started.
It'll be similar to PyCharm in that the standalone IDE will be basically a cut-down Community edition plus the plugin, right, although it can be customised more heavily for Clojure if required. The licensing will be the same for the plugin and the IDE (i.e. your licence will work for both), so if you already own IntelliJ Ultimate it would make sense to stay with that. Unfortunately I don't have the luxury of offering the plugin free to IntelliJ Ultimate users as JetBrains can do with PyCharm.
Pretty much right away after the beta program, although I'm not sure how long that will be. Probably late this year sometime, but it depends on the problems people find.
CLJ-183, CLJ-186, and CLJ-77 are fixed. I'll check CLJ-165. CLJ-129 is coming very soon. ClojureScript support is definitely on the list but will take a while - we do recognise .cljs files, at least.
Right, this is one of the great things about the IntelliJ platform products - the IDE actually parses the program and creates an AST. This allows support for all the magic like refactorings and so forth, including rename. Basically I implement symbol resolution and rename mostly just magically works. Unfortunately due to macros in Clojure symbol resolution is far from trivial.
This will be commercial, similar to PyCharm, RubyMine and the other JetBrains IDEs. I'm considering a slightly restricted free edition that can't be used for commercial work, but I haven't worked out the details yet. It almost certainly won't be fully open source, but I'm considering having a small closed source core and then the majority of the Clojure implementation being open source and extensible. This will need some thought and probably won't happen right away though. In the short term it'll be closed source commercial.
Yeah, I would definitely appreciate a free edition to try out. It would have to be pretty impressive to switch me away from emacs (and vim), and I'd have to try it first to know.
Yes, they released their code under the Apache license. I checked with them before deciding to go ahead with this and they didn't have a problem with the idea.
There's still some lein functionality I need to add. Currently the best way to add a non-standard task like lein midje is to create a run config (Run->Edit Configurations..., hit + and select Leiningen). I'm going to be improving this soon - I assume you'd want to see those in the Lein toolwindow? Drop me an email if that doesn't do what you need it to.
> I assume you'd want to see those in the Lein toolwindow?
Exactly.
Good plugin BTW. I like the jump to Java code (I work on a mixed Java/Clojure project), and was very happy to find out that renaming a Java method fixed the Clojure calls, too. And find usages works across languages! Keep up the good work!
EDIT: One problem I've found: If a function is defined not with defn but using a macro that expands to defn, then the symbol is not resolved.
EDIT 2: Just checked: refactoring and find usages works with Kotlin code, too (in a mixed Clojure/Java/Kotlin project).
Although you've probably thought about this more than I have, it seems like there's a fundamental tension here. On the one hand there are Java IDEs and code-generation in the sense of (re)writing physical source code files. On the other hand, there are lisp macros in the sense of "an API for the compiler". Fully embracing the latter can obviate much of the need for the former (at least there's a long lisp tradition of this).
But it seems that the Java interop aspect of Clojure complicates this picture. The JVM poking through isn't inherently good or bad (for some people that interop is an advantage, for others it's unfortunate), it's just different from other lisps.
So the point I'm ponderously getting around to making is -- it seems like this IDE will be most useful for people using Clojure as a JVM lang, as opposed to using it as a lisp per se. Would you say that's a reasonable characterization, or not?
If I could weigh in, I don't see why one has anything to do with the other. Many people enjoy using IDEs regardless of what language they're using. Historically, the case has been that statically typed languages benefitted more from an IDE, because there is less ambiguity in symbol resolution (functions or methods are known, typed entities, rather than a string). BTW, Clojure is similar to statically typed languages in that respect in that its dispatch mechanism uses namespaces, so symbol "foo" is well known (either as a function, a macro, a multimethod or a protocol method) symbol in a specific namespace, so that you can easily find its usages or jump to definition.
But even languages with more ephemeral dispatch (Ruby, Javascript, Groovy) can benefit from an IDE. It's often convenient to have an editor, a debugger, and control over the build in a single program (and that's why emacs is an IDE).
So I don't see any connection between IDEs and the JVM. Some people enjoy IDEs and some don't.
I probably didn't explain it well. My impression is that refactoring with an IDE is mainly an artifact of Java, not Clojure.
Also: Lisp macros are a unique kettle of fish. They support Don't Repeat Yourself in ways that plain functions cannot. Whereas an IDE is often used to generate repetitive code in files -- i.e. Automated Repeat Yourself.
> My impression is that refactoring with an IDE is mainly an artifact of Java, not Clojure.
I don't think this should be so. If an IDE could help refactor Clojure - why not?
> Whereas an IDE is often used to generate repetitive code in files -- i.e. Automated Repeat Yourself.
Yes, IDEs do that, too, but IDEs had existed long before this feature came about. There's probably no need for code generation in Clojure, but an IDE could still help with debugging, building, navigating the code, refactoring, and maybe even new things like Light Table tries to do.
I agree that IDE functionality matches the programming language. But IDE features are not a pre-specified set. I'm sure there are many ways IDEs could help Clojure (or any other language).
Absolutely - it's a common misconception that IDEs only generate code for blub programmers. Most IDE functionality, particularly things like refactorings, are not at all language specific and are just as useful in Clojure as in Java. They're a lot harder to implement and it's pretty much impossible to give a guarantee of correctness as you would get in Java or another statically typed language, but it's still very helpful.
The real problem in Clojure is the fact that the syntax is so flexible, which massively complicates symbol resolution and other things. You can't even reliably tell whether the form you're in has a do-body or not!
It's pretty clear that a Clojure (or any other lisp) IDE would have to expand macros. This could potentially have side-effects, but there's really no (good) way around it. Besides, Clojure programmers are used to "passive" tools evaluating forms. Even documentation generators like marginalia and codox actually load a namespace rather than just examine the file, which could have side effects, too.
You should be able to run any script in Debug mode (Run->Debug instead of Run->Run) and you can also debug your REPL session, although this is very clunky right now. I'll get some documentation up and provide a link here.
Do you have a mailing list or something so I can get development news? Cause I'm interested in hearing how this develops, the website is a little sparse still, and I absolutely will not remember to come back in a month, haha.
For a couple of reasons. One is that there's already a great Clojure environment for Eclipse - Counterclockwise. Secondly, I think that IntelliJ provides a better platform for building something like this - it's just a better IDE all round in my opinion, and it's a great infrastructure to build on.
I suspect that you'd probably find that the percentage of Java devs using IntelliJ has gone up a lot in recent years too, their market share and mindshare has increased massively recently. I'm not aware of any stats though (and I'm not sure how accurate they would be if there were). Google recently switched from Eclipse to IntelliJ for the official Android development environment, for whatever that's worth.
BTW someone mentioned below the lack of a mailing list - if anyone would like to be updated about new releases drop me a line on cursive@cursiveclojure.com and I'll keep you up to date.
Yes, that's already about 80% there. There are some of the paredit commands missing but it's very usable right now. The most obvious omissions are open-round-and-newline, wrap-round and kill-word. Most other commands are there, and it's strict in the sense of preserving braces with backspace/delete.
If you're interested in whether the Cursive functionality can be integrated into Vim, the answer is no - it relies on a lot of the functionality of the IntelliJ platform. As AndreasFrom mentioned, the IdeaVim bindings are meant to be really good, but I don't use them myself.
