Thanks, I'll definitely take a look at those libraries, I actually didn't do too much searching for prior art, I'll have to start now.
You're dead on with whitespace and reader macros being a problem. I know I heard of someone working on trying to build a clojure formatter, so maybe something like that will come to fruition, otherwise I was just going to return something formatted in a super basic way and punt that problem to the user. The reader macros though is a bigger problem that I have no idea how to deal with. I ran into that with the cycle-privacy refactor. If you try to read '(def ^:private a), you always get back '(def a). I ended up evaling the form and calling meta on it to get the privacy, but that felt wrong and now that you point out #_, it's clear it's not going to work in a lot of cases. I'll have to take a look at clj.tools.analyzer, thought I was hoping there might be some way to just turn off reader macros. I think I might make a separate list post and see if anyone has ideas there. On Friday, February 7, 2014 3:10:49 PM UTC-8, John Hume wrote: > > I haven't attempted any code manipulation, just analysis and indexing, but > I embarked on a similar idea here: > https://github.com/duelinmarkers/insfactor and here: > http://github.com/duelinmarkers/insfactor.el. (Nothing Vim-related there, > the similar part is trying to put as much as possible of the smarts into > the same JVM as the project.) It indexes a simple clojure project and > provides a find-usages command, the idea being that find-usages is the > first useful step toward rename-var and move-var commands. (I say "simple" > because it still barfs on some common stuff, including defprotocol, IIRC.) > > Focusing on what you're doing in http://github.com/cgag/nrepl-refactor, > the mess I came upon and backed away from when I initially played with > transforming code in Clojure is that the forms are easy to manipulate but > formatting is hard to maintain. There are also several non-whitespace bits > of source that the reader will hide away from you (including comments and > #_ forms) but that a proper refactoring tool won't clobber. > > If you haven't already, you might take a look at > https://github.com/cgrand/sjacket. > > I've been hoping that the new > https://github.com/clojure/tools.analyzer<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Ftools.analyzer&sa=D&sntz=1&usg=AFQjCNGdQqvOgv4UWDokQ46-YhCAp7AqLQ> > work > will support some of what source manipulation tools are likely to need, but > I haven't looked into it. For example, one hassle with > jvm.tools.analyzer (at least the now outdated version I've been using) is > that the reader doesn't provide line and column metadata in many places > where you'd expect to find it. Another is that it can only show you the > post-macro-expansion view of the world. > > > > On Fri, Feb 7, 2014 at 3:51 PM, Curtis Gagliardi > <gagliard...@gmail.com<javascript:> > > wrote: > >> Hey everyone, I just wanted to get some feedback on whether or not this >> is a good idea. I've seen clj-refactor.el recommended a decent amount, but >> as a dyed-in-the-wool take-no-prisoners vim user, I can't use it. I've >> always thought it was weird that refactoring was so tightly coupled to >> editors and IDEs, so I thought I'd try writing some refactors as an nrepl >> middleware, that would ideally be able to be used across editors. I've >> only re-implemented the threading and some of the cycling refactors from >> clj-refactor.el, but it's to the point where I'm going to investigate >> actually integrating with vim or light table. I've never written any >> plugins for either of these editors so I might discover there are good >> reasons I haven't seen refactoring done as a client/server type thing. >> Anyway, the code is here: https://github.com/cgag/nrepl-refactor , if >> anyone has any has any feedback I'd love to hear it, and if anyone has >> vimscript or lighttable plugin experience and wants to help, that'd be >> great as well. >> >> Curtis >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- 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.
