Gary, I had tried Figwheel a couple years ago and I had a positive experience, so that was the next thing I reached for.
I just want a practical dev environment, for both Clojure and Clojurescript. To me, that means simple and stable. I definitely want fewer things that can go wrong, but if I can install a package by cloning a repo and adding a few lines of elisp, and it works, I'm happy. I don't care how complex it is. If it causes my REPL to hang, prints out control characters, regularly breaks after updates, etc., then I'd rather drop down to something simpler, with fewer features. For Clojurescript, I've used lein-cljsbuild in the past. That seemed to work well. I know I've connected to a REPL running in the browser before, but I don't remember it being useful enough to bother with. I don't think I knew how to write "reloadable code", then, though. I would love to hear how people do Clojurescript development today, especially if they aren't using Figwheel. On Thursday, July 5, 2018 at 12:07:13 PM UTC-7, Gary Trakhman wrote: > > I'm not sure the desires for lightweight clojure-emacs integration and any > CLJS integration are yet sympathetic. Figwheel is a pretty complex piece > of software. For example, see my issue that has been languishing for almost > a year and hints at greater problems with the compiler integration: > https://github.com/bhauman/lein-figwheel/issues/593 . From my > perspective, this is more due to coupling of the REPL to the compiler > itself than a problem with figwheel. > > But I was surprised when the thread went in this direction just from > reasons I think someone might want to not use cider, fast startup time, > less stuff to go wrong. CLJS adds that back unless it's gotten > significantly better since the last time I tried. > > On Thu, Jul 5, 2018 at 2:19 PM rob <r.p....@gmail.com <javascript:>> > wrote: > >> If ClojureScript repl integration works smoothly out of the box then >> that's already one reason to use it over Cider... (This is not a jab at >> Cider, just a statement of fact that Cider's support for ClojureScript >> development has so far been lacking, IME) >> >> >> On Thursday, July 5, 2018 at 10:51:02 AM UTC-7, Austin Haas wrote: >>> >>> >>> I tried Monroe, yesterday. It seems to work as advertised. I didn't have >>> any issues. It's nice that "jump to definition" works out of the box. It >>> does not appear to support Eldoc, so no help with function signatures. >>> >>> This is the Emacs config I'm currently using: >>> >>> ;;; clojure-mode >>> >>> (add-to-list 'load-path >>> "~/.emacs.d/site-lisp/third-party/clojure-mode/") >>> (require 'clojure-mode) >>> (add-hook 'clojure-mode-hook 'rainbow-delimiters-mode) >>> (add-hook 'clojure-mode-hook 'paredit-mode) >>> (add-hook 'clojure-mode-hook 'hs-minor-mode) >>> (add-hook 'clojure-mode-hook #'eldoc-mode) >>> >>> ;;; REPL >>> >>> ;; Monroe >>> >>> (add-to-list 'load-path "~/.emacs.d/site-lisp/third-party/monroe/") >>> (require 'monroe) >>> (add-hook 'clojure-mode-hook 'clojure-enable-monroe) >>> (setf monroe-detail-stacktraces 'true) >>> >>> I went on to include Figwheel. >>> >>> I created a new project using `lein new figwheel my-project` (which >>> provides the fig-start and cljs-repl functions), and then entered the >>> following commands to set up a Clojurescript dev environment: >>> >>> M-x monroe-nrepl-server-start >>> M-x monroe >>> (fig-start) >>> (cljs-repl) >>> >>> On my machine, those 4 steps take about 30 seconds to run. The first >>> takes 18 seconds, and the rest only take about a second each, but the whole >>> process ends up taking close to 30. >>> >>> Figwheel seems to work great, but I couldn't figure out how to evaluate >>> code in a library dependency and have it updated in the running system. I >>> can evaluate functions, but the new definitions don't appear to be called >>> by the main code. I might be misunderstanding how this is supposed to work; >>> I don't know if it's a Figwheel issue or a Monroe issue or my mistake. But >>> to work around that, and to fix other issues preventing a clean initial >>> compilation, I had to restart the REPL a few dozen times, which was tedious. >>> >>> I'm posting this information in case it is useful to someone else who is >>> trying to discover the current state-of-the-art with running Clojure in >>> Emacs in a straightforward, minimal way. I'm also hoping that people will >>> reply with comments and suggested improvements. (FWIW, I've been using >>> Emacs full-time for about 20 years, Clojure full-time for about 7 years, >>> and Common Lisp for 5+ years before that, so I'm not new to REPL-driven >>> development in Emacs.) >>> >>> >>> -- >> 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/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.
