@simon I think that's related to what I asked above – as far as I understand it's a functionality that generates a file with minimal defs for files which generate symbols with macros, so that autocompletion for such namespaces can work. For example https://github.com/dm3/clojure.java-time/blob/master/src/java_time.clj re-exports symbols from namespaces with a macro and without stubs it confuses Cursive – it can't offer completion for this namespace. When the pop-up shows and you ask it to generate stubs, it will (partially) evaluate the macros, to produce a file it can use for completion. So if you value the use of completion, it will be generally a good idea to click that Generate now link. One downside I can see is that there seems to be no way to navigate from the stub to the macro that generated it, so if you want to read the implementation, it's less accessible.

@cfleming is there a way to navigate from a stub to the code that generated it?

@jarppe So right now this is done statically from the source code, i.e. is has to be an (is (= a b)) form. That’s not extensible at the moment, I’ll look to see if I can do that.

@simon Yes, @jaen is correct on how this works.

@jaen No, in general I don’t think that’s possible, there’s generally no information in the generated code that will tie it back to the macro.

Actually, now that I think about that, I’m not so sure - I’ll see if I can do that.

I mean, I don't presume to know how exactly you implemented it underneath, but considering it output just the stubs, it can't be regular macrcoexpansion, can it? Then you could probably thread location metadata through the code that does macroexpansion, I suppose? Depending on how exactly you have this implemented it it can be simple or annoying to do, but hopefully doable? Not a high priority though, you could even just add a navigation action for the whole stub file to it's source file – it's certainly way simpler and almost as useful as navigating per symbol.

Also, re: usability of that tooltip – maybe it would be a good idea to put it in a bar that appears on top of the file (like for missing file associations or filetype plugin sugesstions)? It would be harder to miss and more discoverable then. Not sure if that's possible for plugins to do it though.

@jaen The implementation is actually pretty simple - I basically just start a process with the classpath of the module, that requires the namespace and then introspects it. So if those generated vars have any file/line metadata, I might be able to use that.

Ah, so you just use macroexpansion and then simplify it, I see.

re: having it in the in-editor notification, it actually worked like that at the start, but the process was surprisingly difficult to make robust. The in-editor notification drove people nuts when the stub generation didn’t work since it was present constantly.

Well, I don’t macroexpand myself, but generally loading the ns will as a side-effect create vars via some technique or other.

Sometimes macroexpansion, but sometimes they’re table-driven (e.g. om.dom etc)

I see.

That's a shame about the ticker tape though. Because I was quite confused why this didn't work until I restarted IntelliJ later and the tooltip popped up.

It will also not generate stubs for vars in the ns that Cursive knows about already via its own analysis, to try to reduce duplicates in completion etc.

Yes, I was worried that would happen.

I could possibly re-visit that and add a Dismiss option to it or something.

Well, at least now I know where I look, but if it's possible to do it robustly with the ticker, it will probably help other people coming across this feature for the first time.

Incidentally, is there any option to force stub generation even if you missed/dismissed that tooltip?

It will be re-checked when your project is synchronised - you can force that in the Leiningen toolwindow (View->Tool Windows->Leiningen->Refresh) or using the Refresh Leiningen Projects action

Ideally it would also be re-checked when the ns form in any file is updated, but that’s tricky unfortunately.

Maybe some context menu item on the tab could work? But refreshing from the leiningen tab is a simple enough workaround.

Incidentally, how are the plans for boot support? Just out of curiosity, really, because writing a task to output a lein project works well enough (except no completion in build.boot unfortunately)

@jaen I’m planning to start working on better build tool support soon. It’ll start with deps support, and then add boot support using deps for dependencies. I’m using those to investigate the IntelliJ infrastructure for build tools, which the lein integration pre-dates and needs to be moved to.

I’ll also add shadow-cljs support once I figure out how the moving pieces work.

Sounds nice, thanks for the info. I'll probably should look into deps.edn then, I've so far had my own simple edn format for that.