In recent IntelliJ versions it’s been possible to override actions in different contexts, so now I can ensure that in Clojure contexts the Cursive actions take precedence, and when not in Clojure contexts they have no effect. It’s particularly difficult in Cursive because IntelliJ has so many bindings already which experienced IntelliJ users expect to continue to work as they expect, but Cursive also needs a lot for structural editing actions.
deftype/defrecord/definterface), multimethods, protocols and more, as well as delineating private vars with the standard IntelliJ lock icon.įinally, one thing that has traditionally been a real chore for new users is setting up keybindings.
It now shows these same things defined with keywords (specs, re-frame elements) as well as having much better support for classes (e.g. The structure view is now much more useful. Note that this only works for things defined using namespaced keywords (which is standard for spec, but not so much for re-frame) to avoid changing the semantics of bare keywords unexpectedly. This is now supported, and navigation, find usages etc works as expected for specs and re-frame. There is also a link in each of the error notifications allowing stub generation to be disabled for the corresponding module - hopefully this will allow users to disable it for problematic modules but still leave it enabled for others.Īnother feature that a lot of people have asked for recently is the ability to navigate to things which are “defined” using keywords, such as specs and re-frame elements. I’ve added a config switch per module which will cause Cursive not to attempt to generate stubs for that module, it’s under Project Structure->Modules->->Clojure.
As discussed in the Github issue, the issue with using the notification group is that you can only universally turn it off across all projects.
0 kommentar(er)
