Nightcode uses Compliment for providing completion suggestions and documentation of Clojure functions:
https://github.com/alexander-yakushev/compliment On Wednesday, December 18, 2013 11:27:06 AM UTC-5, juan.facorro wrote: > > Hi Clojurers, > > I'm building a tool for Clojure and I've been hitting the same bump for > quite some time now, namely auto-completion and finding the definition of a > symbol. After doing some research I've found that some tools rely on a > running REPL to figure out where a symbol might be coming from; these > include emacs [1], Counter-Clockwise, clooj and maybe others I don't know > about (like Nightcode or Cursive). This seems the natural thing to do since > while developing we always have a REPL running to try out what we code, > after all this is one of the best LISP features. This approach results in > very accurate locations for global symbol definitions, but locals are not > found since they are not accesible form the REPL. > > Another approach I've seen used for auto-completion in Clojure is the > token-based, which involves looking for tokens in the code base associated > with the current project and then providing the nearest match regardless of > context; these include J Editor [2], Light Table (which I think uses > inter-buffer token matching [3]) and emacs when it uses dictionary files > (maybe not specifically in existing Clojure modes but it's something that > emacs can do). Although this approach resolves the auto-completion, it is > not very accurate when locating symbol definitions. > > From what I've read this is not a trivial problem so I was wondering if > there's some implementation that actually resolves symbols statically (I > mean without having a running REPL) in an accurate way or, if there's no > implementation, maybe someone could point me in the right direction (or any > direction) as to what would ease the pain to accomplish such a task. > Building something on my own to do this "static symbol resolution" is out > of the question, since that sounds like a whole project on its own and I'm > currently trying to build something else entirely. > > There are parsing libraries which provide good parse trees (i.e. Parsley, > Instaparse), but my understanding is that what needs to be mantained is a > full abstract syntax tree for the whole code base and although > clojure.tools.analyzer [4] does the job of creating an AST, generating and > mantaining all these trees sounds very costly and not the right way to do > it. > > If the running REPL approach is the saner one, then I would have no > problem with going down that road, but I just wanted to make sure what the > viable options were. > > If you got this far, thank you for your time. :) > > Any help, thoughts or comments will be greatly appreciated! > > Juan > > [1] https://github.com/clojure-emacs/ac-nrepl > [2] http://armedbear-j.sourceforge.net/ > [3] > https://groups.google.com/forum/#!msg/light-table-discussion/Q-ZvOJSr1qo/-D6tAV_XiMUJ > [4] https://github.com/clojure/tools.analyzer > -- -- 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/groups/opt_out.
