Yes, if you uncheck Settings | Languages & Frameworks | Clojure | Hiccup Conversion Options | Use shortcuts for class/ID they’ll be added to the :class map instead.

See this issue: https://github.com/cursive-ide/cursive/issues/2420

great! thank you @U0567Q30W

Is it precisely spy, or any of the functions referred by this macro? I think symbols/vars created/referred by most macros are not 'understood' by intellisense. Somewhat deeper info here: <https://cursive-ide.com/userguide/macros.html>

I’ve always had a distaste for such “magic” and that has only grown larger 🙂 (context: I like & use timbre but I wouldn’t use such automagic refer/require tricks… it just makes it harder for anyone who isn’t aware of that trick to understand what’s going on; for example I’ve used timbre for years and didn’t know that’s a thing)

Yes, I have never liked this sort of thing, and I consider Cursive’s lack of support for it to be a gentle nudge to just not do that. Sadly, not everyone listens to me 🙂, and it’s annoying when these things don’t work. I’ll take a look, Cursive does already support some such macros (e.g. Potemkin’s similar import-vars).

Yup… I would go as far as saying that I almost always consider Clojure :refer harmful 🙂 But macro-magic that does a “hidden” refer is on another level 😜

Macros are supposed to provide well abstracted leverage (say, next.jdbc/with-transaction ) … not clever+hacky import/require one-off conveniences.

To push back on this sentiment - macros are not "supposed to" do anything. They do what is supported by the language. A contrary point of view is that if the language allows certain functionality but the editor does not and so people start coding to please the editor which changes the style of code written. I do no think this is a good thing. We have a situation where the tooling makes a feature less useful (like interning Vars dynamically) and thus makes it annoying to use, but it is a feature of the language and obviously can be useful (otherwise the use-case wouldn't come up) and thus the argument is that it should be supported by the editors. In short, the editor should not be making value judgements on code style by lacking support of language features.

As an alternative imagine if you inform cursive that when you a function/macro is evaluated that Vars will be interned, similar to the indentation configuration screen - that way it is extensible and allows for this common use-case.

There are lots of examples where the extreme flexibility of Clojure leads to the ability to do things which were probably never intended. For example, you can happily def a var inside a function - it will work, but it’s almost always a rookie mistake, often by people coming from Scheme. Cursive doesn’t support that by design, and I would argue that’s a good thing since it guides people away from something which is usually a mistake (although the language will happily allow it).

Obviously the var-refer thing is more of a grey area and I will try to support it (I have added support for some similar things in the past). It’s a fine line as to whether editorialising is a good idea or not - I think the def case is clear cut, I’m not so sure on this one. I think it’s sloppy API design personally, but that’s just me.

If you’d like an example of extreme flexibility leading to weird edge cases, you need look no further than the first form in your files - ns. Clojure allows all sorts of crazy stuff in there, but there’s a reason that other dialects learned from that and disallowed them.

Lisp macros are Turing complete. They don’t do what is supported by the language – they are the language, in a sense (minus the Clojure special forms). To suggest that Clojure somehow “supports” implicit dynamic imports just because it’s possible to do is a big stretch (because of Turing completeness there’s virtually no bound on what is “supported”). There’s support for dynamic, explicit require via … require https://clojuredocs.org/clojure.core/require

Thanks for the thoughtful feedback @U0567Q30W I agree that providing helpful feedback from the editor does make sense for things the culture deems appropriate or not. I'm actually not sure myself if var-refer is always a terrible idea. One use-case I have in mind is code generation based on data where a DSL is created following a common structure (like (create-<entity>) which would be created from an HTTP OpenAPI spec for example). I think your intuition is correct that for some cases the opinion of the community is clear-cut but I think for this case it's blurry, which is why I wanted to provide a counter point.

Thanks for the clarification @U050KSS8M one of the issues with speaking in generalities regarding clojure "the language" is that with all the dialects there are actually quite a few "languages" - I often target ClojureScript and in that environment dynamic requires are not available and sometimes doing things in a macro can be the best solution given all the tradeoffs of the browser environment. To reiterate the main point I made - we're discussing whether or not the editor should make a value judgement about the code we write and implicitly push our style of writing in one direction or the other based on the features the editor allows (not the language) and does not allow (or make easy/convenient or hard/annoying).

Sure, and I appreciate the counterpoint. I agree this case is murky, and clearly several people who write a lot of valuable OSS (Zach Tellman, Peter Taoenssis) disagree with me on this. Even ClojureScript does it under the hood.