I considered jline as well, but using it would require mixing it into the classpath, which I did not wish to do. Many have died on the bikeshed of rlwrap vs jline and I've made the decision for now. Changes were made to the clj script yesterday to make it tolerant of rlwrap being unavailable and there is a ticket working toward some additional changes to give you more control.
If you wish to use jline it is of course, a Java library, so you can add an alias with :extra-deps dependency on jline, then include it on the command line with "clj -Rjline". With the changes mentioned above you would also be able to disable rlwrap. On Wed, Jul 26, 2017 at 5:42 PM, Rick Moynihan <rick.moyni...@gmail.com> wrote: > Regarding the cross platform nature of rlwrap, at the cost of an extra JVM > dependency might it not be better to use jline? > > http://jline.sourceforge.net/ > https://github.com/jline/jline3 > > I used to use it with clojure many many years ago and it seemed to work > quite well... > > R. > > > On 26 July 2017 at 17:57, Alex Miller <a...@puredanger.com> wrote: > >> >> >> On Wed, Jul 26, 2017 at 11:48 AM, Steve Miner <stevemi...@gmail.com> >> wrote: >> >>> I’ve been using my own launch script that does something similar to the >>> new clj script. (I’m caching a Leiningen generated classpath.) I had some >>> bugs when my project directory was copied to another user or machine >>> because the cached classpath was not validate in the new environment, >>> particularly with a different Maven repository. The same kind of problem >>> can happen with a remotely mounted project directory. File time checks did >>> not necessarily protect against these relocations. >>> >>> I fixed my problem with two changes. First, I put the cache in the >>> PROJECT/target subdirectory so that a “lein clean” would allow the user to >>> recover. >>> >> >> This is a non-starter - we need the cache to survive a rebuild by >> separate build tool (also don't want to create target dir if not needed). >> >> >>> Second, I named my cache file with the inode of the project.clj file. >>> If the project is copied somewhere else, it is highly unlikely that the >>> inode numbers would match. The inode of the Maven repository or project >>> deps.edn should work with the new clj script. >>> >> >> Interesting, will think about that (portability issues though). >> >> >>> I use rlwrap, except within an Emacs shell. I suggest you test for the >>> presence of rlwrap as you do for java. $(type -p rlwrap) and ignore it if >>> it’s not found. I think Emacs is popular enough that it’s worth testing >>> for within your clj script ($EMACS will be defined). It would be good >>> enough if you provided an option to turn off rlwrap so I could wrap your >>> script with my own. >>> >> >> I've had feedback from others on rlwrap too (since it's currently missing >> from the installation instructions, which is just my oversight). The idea >> was that the installer would ensure it's installed so it can be assumed it >> exists. But there are surely cases where you might not want it so a jira >> for having a way to add more control around it would be fine. I don't want >> to check for $EMACS but wouldn't mind having a new env var that you could >> set to skip it or something like that. >> >> >>> I can file bugs and provide patches if you want. >>> >>> Steve Miner >>> stevemi...@gmail.com >>> >>> -- >> 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. >> > > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/clojure/FpMqtNu0TCE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > 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.
