Thanks for the great feedback! Am Freitag, 22. Mai 2015 05:48:38 UTC+9 schrieb Laurent PETIT: > > Sorry for jumping late inside the pool, but the topic has retained my > attention from day one. > > As a developer of an IDE plugin (CounterClockWise for Eclipse), I'm very > interested in this effort. > Here are my ideas/questions/remarks: > > - Finding a winning scenario for adoption is key. A perfect tool with no > users will be of no use > - Specifically, for broad adoption, one scenario I can see is that such > APIs are automatically delivered by library authors without changing any of > their habit. E.G. the result would be automatically downloaded to either > clojars or maven central as just an additional jar with a specific > classifier. > - To be even more specific, I think that this means that from start you > should plan to provide leiningen plugin, at the very least. And probably > maven (clojure-maven-plugin) and boot plugins as well. Go reach the users > where they are. >
I didn't think of giving the plugins high priority, but I guess you're right! Thanks for pointing out their importance again. > - Of course, from the point of view of an IDE, which already has the > tooling to get jars from maven repositories, it would not be difficult then > to get information from libraries, that could be used to help Users anytime > about the libraries they've chosen. No need to get a REPL open and get all > the project namespaces loaded. No need to reinvent another way to > statically parse all the project dependencies to get static analysis (at > least for the project dependencies). > - This would also enable providers of not open-source projects to deliver > the API - and not the source code -, and for this kind of scenario only > your solution will be of help. > > If I remember well, when talking about this with Tom Faulhaber, the author > of Autodoc, several years ago (yeah, hammock time can sometimes be veeeeery > long ;-) ), he told me that everything was already there, in Autodoc, after > it had produced the HTML pages. But maybe not published in the final "HTML" > product. But definitely there, maybe even not just in memory, but as an > intermediary set of files to be transformed, on the filesystem. > Do you mean the fourth item of "what Autodoc will generate" in https://tomfaulhaber.github.io/autodoc/? It could be a starting point, but I think we will have to go further. Last point for today: I don't know how easy it could be done, but if the > tool could give most possible accurate guidance about which arguments of a > macro should be considered as symbols that will name locals inside the > macro body, that would be very cool ! Currently Cursive probably has a list > of macros for clojure core, and for most used clojure projects, with a way > to declare which argument will be a symbol usable as a local, etc. > Sooner or later, I'll have to do that for CCW also. > Unless a standard comes out from your project first, which would be great > :-) > I'm not entirely sure how you mean this, but I'll take some more time for digesting your feedback anyway. On one of the latest Cognicasts, Colin Fleming talked about a repo where library authors can upload extensions that help the IDE understand their macros. I have to listen to it again, but it sounded a bit like what you're talking about. Right now I can't find that repo, though. Maybe he was just talking about plans. Richard -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
