2010/7/20 Chas Emerick <cemer...@snowtide.com> > > On Jul 20, 2010, at 4:29 AM, Laurent PETIT wrote: > > You're right. When ccw will be remotely connected to web server instances, >> the current behaviour will be a recipe for disaster. The "middle way" is >> definitely the final target, but providing good defaults for the >> "smart-reload-on-save" should be studied. >> Here are my thoughts for the defaults: >> a. jvm loaded by ccw: 99% of the times it's in "dev mode" => >> smart-reload-on-save true by default >> b. connection to a remote REPL: 99% it's for "touching" more "sensible" >> environments (test serveur, pre-production server) => smart-reload-on-save >> false by default >> > > I'll have to strenuously disagree again. Defaults matter, insofar as they > recommend preferred behaviour.
> By all means, use a background REPL to support editor features, So e.g. code completion while in the file editor works on a set of possible completions, and code completion while in the REPL works on another set of possible completions ? e.g. if I dynamically define a new var in the REPL, it's not suggested in the editor. If someone asks the editor for "macro-expansion", it will macroexpand with the definition found in the "background-instance", not the one the user may just have modified/corrected in the REPL but not yet re-saved in the file ... Hmmm .... > but don't step on users' REPLs -- doing so isn't actually doing them any > favors. I have to repeat this for emphasis: > > > Knowing how to work with REPLs, and understanding the relationship between > them and source files and (if one uses AOT) classfiles is paramount to being > able to use Clojure effectively IMO. If anyone were to get the impression > that REPLs are really just an editor feature, are managed automatically, and > are not a natural outcropping of Clojure being a lisp, they'd be at a > disadvantage. > > I'm curious: are there any other lisp environments where reload-on-save is > the default? > > > Totally FWIW, I think enclojure's REPL support is stellar (some are >> probably tired of hearing me say that). I think ccw (or any other >> "integrated environment") would do well to ape it as much as possible >> (something I aim to help with, but I'm underwater at the moment). >> >> Chas, that's not a problem if you cannot work on this as you offered to >> do. I just wish you had told me that sooner, because that's an area on which >> I also can (and would like to) work, but I had stopped touching it since you >> volunteered (my work on paredit enhancements is slow currently, so I want to >> start something else in parallel). >> > > It's not that I cannot work on it, just delayed from doing so. I'm sorry I > didn't say so last week, but I didn't think it was relevant -- I don't think > I've ever worked on an open source project where there was such a schedule! > ;-) > > Cheers, > > - Chas > > > -- > 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<clojure%2bunsubscr...@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 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
