> > 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. >
Right, sadly this is still at the plans stage, although Cursive already uses this API internally. I'll let everyone know when this is public. Cheers, Colin On 22 May 2015 at 12:42, Richard Möhn <richard.mo...@posteo.de> wrote: > 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. > -- 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.
