Integrate Parinfer

[deas]

http://shaunlebron.github.io/parinfer/index.html looks pretty convenient. I am just checking out whether/how it is possible to integrate it in a minimal invasive fashion.

What do you think about it?

You might want to check shaunlebron/parinfer#24

[casidiablo]

:+1: Was about to feature-request the same!

One of the things that I miss the most when using gorilla-repl is the lack of paredit. Parinfer looks simple but powerful.

[JonyEpsilon]

That looks very nice. Definitely interested in getting this going!

[deas]

I have a very basic proof of concept working. It is in deas/gorilla-repl in the feature/cljs-parinfer branch. I used ClojureScript because there was no JavaScript library version of parinfer available last week. :)

However, there is one available today: https://www.npmjs.com/package/parinfer

Question now is where do you want to go with gorilla-repl?

You wan't the client source to be JavaScript or are you fine with ClojureScript?

PS: Personally, I'd prefer ClojureScript along with Figwheel and all the other goodness.

[JonyEpsilon]

Cool, that's neat!

Although, I have to say, having now played with parinfer a bit it's currently in the same class as paredit is in my mind, which is "I can see why some people like it, but I find it very annoying"! So if we did integrate it it would definitely have to be optional somehow :-) My feeling - given I have a strong tendency to try and keep Gorilla simple and straightforward - is that it would be better just to stick with simple/obvious code editing, but I am open to being persuaded otherwise.

Regarding cljs: I certainly think cljs shows a lot of potential, but my experience using it is that it's a still a bit rough round the edges. I'm not sure I'd start a new project in it, and I'm definitely sure I wouldn't want to port an existing project like Gorilla to it :-)

[deas]

I fully understand that you want to be very careful changing code. I also understand that you would like to have parinfer support optional.

I am not suggesting to go the risky route and port gorilla client code in one swoop. But I do think foundation cljs is pretty smooth and stable enough to start building upon. A basic non risky start could be the introduction of figwheel. I think its hot reloading alone is pretty much worth it. Even if you do not have a single line of cljs code.

We could then slowly go one step further by trying out cljs for optional parinfer only.

May I ask how you think cljs is rough round the edges?

ClojureScript for Skeptics may help solve some worries. ;)

What do you think?

Please also note that I am not suggesting to merge in feature/cljs-parinfer as is now.

[JonyEpsilon]

I think my preference is not to head in the cljs direction with Gorilla. Mainly because I'd have to see a big win from porting to cljs to justify changing a working piece of software, and I don't really see that at the moment. And with that in mind, I don't think I'm inclined to introduce cljs bit-by-bit as it's moving in a direction I don't want to head.

Regarding my opinion on cljs: I think the core of it is great, and it has great potential. I think a few things aren't there yet, like tool support - the dev tool experience is a bit patchy I've found - and the situation around interoperating with external js libraries is somewhat fiddly, although it's improving rapidly. Perhaps more importantly though, things haven't stabilised yet, and while it's fun to play with the bleeding edge, I'm not sure it's a great idea for a shipping project! In particular, while the core of cljs is quite stable, and the build tools are improving, there still seems to be a lot of flux in the libraries, and people are still figuring out what the best way to write apps is (Om, Om next etc ...). Personally, I'd be looking for that to settle a bit before basing a project on cljs.

Regardig figwheel: yes, love it. I'd say the real benefit of using it isn't realised though unless you're going the whole hog and structuring your app to take advantage of it (i.e. having some state container and everything tracking from that). Gorilla isn't really in that form, so I'm not sure there'd be much benefit to integrating it. Also, I find that, because it's possible to save Gorilla worksheets that debugging things isn't too painful with reloads.

Sorry if this all coming off a bit negative ... if it helps, it's not so much negativity as plain old-fashioned conservatism!!

[deas]

No problem. I fully respect your choice and I am not disappointed. ;)

Personally, I think for gorilla, the choice of the UI library does not really matter since it uses just a handful of services.

However, I would still like to push cljs and I will continue working on my cljs branch. It would be nice if that easily rebases with develop so things don't diverge too much and we may join later on.

Regarding parinfer, I'll check whether the npm version easily goes on top of develop and let you know - but going cljs is my priority.

[markaddleman]

It looks like parinfer is available in javascript now. My js fu is lacking otherwise I'd take a crack at integrating it with Gorilla. Do you have any interest in picking this back up?

[lspector]

I want to chime in on the anti-parinfer (and anti-paredit) side of this. I find both paredit and parinfer to be intensely irritating and problematic. If either of these must be added, then I hope they can be made optional.

[lspector]

PS to my comment above, from my perspective (which I acknowledge is a bit idiosyncratic but FWIW is based on decades of teaching and using Lisps), even the "smartish" stuff that Gorilla already does with parentheses is a bit of an anti-feature.

It's not nearly as bad as paredit or parinfer would be, but I routinely see students surprised and fighting with it when they try to fix code, for example when highlighting some code and hitting something like "(" which they expect will replace the highlighted code (as it would in any normal editor), but then it does something "clever" instead.

I understand why people think these features are cool, but in my experience they are counterproductive, especially for newcomers but even for me as a long-time Lisper.

A Lisp editor should absolutely show what matches what (as Gorilla does quite nicely, although something like rainbow-parens could be even nicer), and it should absolutely provide syntax-aware auto-indenting and re-indenting (as Gorilla does perfectly with shift-tab). But from my perspective pretty much any attempt to be "smarter", including the automatic insertion of closing brackets or anything that interferes with normal typing or cut/paste semantics, inevitably does unexpected and confusing things in some situations, and should be avoided.

I think that Gorilla is quite usable as it is, and I've been able to deal with (and help my students to deal with) its "clever" editing "assists" without too much trouble. But from my perspective the way to improve it would be to make it a bit less "smart," rather than a bit more.

[deas]

My be a bit off topic in this context, but I am generally trying to push gorilla forward at this time. Tried getting in touch via j-star email and now accidently invited to join on LinkedIn . :) However, would you @JonyEpsilon mind having a quick chat on Skype?

[lspector]

FYI Ben Bailey (https://github.com/benfb) has produced a version of Gorilla REPL with a few strategic changes, and several of us have been using and teaching with it. We use it in conjunction with leiningen on the command line as a complete programming environment. For this purpose (with the changes we've made) it's quite wonderful; lightweight and trivial to "install," with all of the features that we need and none of the complexity we don't. A description of how we use it is here.

[benfb]

I believe we've resolved this privately with a fork of Gorilla 🙂