ClojureScript and Javascript sources lookup

[Andrea Richiardi]

Hello all,

I am a Clojure newbie trying to fiddle around with LightTable (ClojureScript) sources. The biggest issue so far is to read and find documentation on Javascript classes (like js/console.log).

I would like to be able to jump to the Javascript source whenever I have a doubt and neither LightTable now Cursive can find the source when I try to jump (Cursive gives me warnings, for example on (.replace content (js/RegExp. "[ \\t]+$" "gm") ""))) it cannot find js/RegExp).

Maybe I am missing some configuration in the leiningen script, or in the IDE, therefore my question is, where do I have to put (and how) the Javascript source in order to jump to it when necessary?

Thanks!

[Colin Fleming]

Hi Andrea,

CLJS has been a bit of a second-class citizen in Cursive up till now, but I'm actually working on this as we speak. The next version (hopefully in a week or so) should have much better symbol resolution for CLJS, including resolution of Javascript symbols with their corresponding documentation. I'm also planning an easy to use browser REPL, but that will probably not make it in unless I'm very lucky - that'll be the following release.

Cheers,

Colin

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[Gary Trakhman]

Colin, you might find this project helpful, it's what's driving the autocompletion/symbol-info backend for cider-nrepl (you could use cider-nrepl too!): https://github.com/gtrak/cljs-tooling

[Colin Fleming]

Thanks Gary, I'll take a look. The resolution in the editor is static and doesn't use the REPL, but that looks very helpful for the REPL. I'll take a look at cider-nrepl too.

[Andrea Richiardi]

Great, I love collaboration between projects! Talking about collaboration, Colin, do you think I can include the same tooling system for LightTable? I actually have the same problem of symbol resolution and I really would like to contribute (maybe with just a plugin at the beginning) to it.

[Colin Fleming]

Well, implementing symbol resolution is a pretty huge task. I'd estimate it accounts for at least 60% of the time I spend working on Cursive. Cursive's implementation isn't open source, but even if it were it's very tied to the IntelliJ infrastructure and wouldn't be very useful. Cursive is internally structured around an extension API which I'm going to open source along with the current implementations so in theory those implementations could be used with another core indexing engine implementing the same API, but like I say it's a pretty enormous task. You'll need a good indexing engine which is much harder than it sounds - the one in IntelliJ is really amazing, you definitely don't want to develop that yourself if you can avoid it.

In general, I think it's extremely difficult to retrofit this sort of system into an editor such as LightTable that wasn't designed to use it from the start. IntelliJ's indexing is fundamentally integrated into the infrastructure, it's not something that you could easily bolt on with a plugin.

[Andrea Richiardi]

On Tuesday, 3 June 2014 16:37:33 UTC+2, Colin Fleming wrote:
> Well, implementing symbol resolution is a pretty huge task. I'd estimate it accounts for at least 60% of the time I spend working on Cursive. Cursive's implementation isn't open source, but even if it were it's very tied to the IntelliJ infrastructure and wouldn't be very useful. Cursive is internally structured around an extension API which I'm going to open source along with the current implementations so in theory those implementations could be used with another core indexing engine implementing the same API, but like I say it's a pretty enormous task. You'll need a good indexing engine which is much harder than it sounds - the one in IntelliJ is really amazing, you definitely don't want to develop that yourself if you can avoid it.
>
>
>
> In general, I think it's extremely difficult to retrofit this sort of system into an editor such as LightTable that wasn't designed to use it from the start. IntelliJ's indexing is fundamentally integrated into the infrastructure, it's not something that you could easily bolt on with a plugin.
>
>
>
>
>
>
> On 4 June 2014 02:17, Andrea Richiardi <andrea.r...@gmail.com> wrote:
>
>
>

[CUT]

Gotcha! Thanks for the advice, I'll have a look and probably ask on LightTable's irc channel...but I doubt that a Clojure newbie can tackle this alone (ok...if he can, he will spend a lot of time :)).

[Colin Fleming]

Sure, anything is of course possible with enough work :-)

[Gary Trakhman]

Even boiling the ocean!

[Andrea Richiardi]

On Tuesday, 3 June 2014 16:51:45 UTC+2, Colin Fleming wrote:
> Sure, anything is of course possible with enough work :-)
>

Oh yes definitely! Do you know by any chance some good reference on implementation strategies for these kind of indexers? I think that the spreading of a programming language depends a lot on its tooling, and from what I see Clojure has potential but is missing some cool feature and IDE support (Cursive aside).
I don't know if am going to start something like this, but it would be a good reading regardless.

[Colin Fleming]

No, I don't, sorry. You could always look at the IntelliJ implementation which is open source - it's a massive complex ball of Java though.

I think the actual indexing itself is fairly straightforward - I'm using the lowest-level indexes that IntelliJ offers, and that allows me to basically work with maps which fits very nicely with Clojure. The difficult bit is knowing when to invalidate them when files have been updated. For a primitive version you could just use a file watcher, but IntelliJ's is much more sophisticated since it has a virtual representation of a file system which allows much more control and knowledge of when and how things have changed. You also really need it integrated into your actions - when an action tries to perform some access requiring an index, IntelliJ will lazily update the index at that point, but that's more difficult to do with a watcher. Again, nothing is impossible, but it's a lot of work and I'm willing to bet there are a ton of nasty edge cases.

[Andrea]

I will surely have a look...I am also interested in the auto saving...I guess it's implemented the same way..using this custom file watcher layer over file systems...

It will be fun, and at the moment I read Java better than Clojure ;)

Thank you for the reply

You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/_95-aqLFhb4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.