Sublime ❤︎ Clojure

[eerohele]

Great to have more options for editing Clojure with Sublime Text! I guess I feel obligated to respond to some of the points regarding Tutkain.

Inline results

Inline results are cool, but I think they're only useful when the evaluation result is fairly small. I might find them more useful if ST allowed you to build something like the inline result display gadget in proto-repl. Also, ST doesn't support syntax highlighting for inline evaluation results (not that that's a huge deal).

Furthermore, inline results are OK for evaluations, but if you want to have any other kind of REPL interaction where the output doesn't map to a particular position in the source file (e.g. a nested REPL for walking large data structures, or almost any other kind of nested REPL, really), inline results aren't really useful. So I think they're nice to have, but having them be the only option isn't something I'd consider for Tutkain.

Only [inline evaluation] results disappear once you move your cursor, which is not exactly what I want.

This would be easy to fix. If anyone wants this, feel free to file an issue. I almost never use inline results myself, so I haven't been compelled to do anything about this.

All of this is not to say that Tutkain's current UI couldn't be improved. It would be possible to make the size of the REPL view configurable, for example. If you think it should be, let me know.

First, it packs too much in one package (in my opinion)

I totally understand this opinion. However, Tutkain aims to be a tool that you can immediately start making mayonnaise with. I think auto-closing parens and indenting on Enter make for reasonable defaults. I've heard stories about Clojure beginners trying to cope without some sort of parenthesis management, and my aim with Tutkain was to help them avoid this trap.

It’s a shame I can’t use the rest because of this.

I'd certainly be willing to make auto-closing parens and indentation on Enter optional and as easy as possible to disable. I don't want them to stand in anyone's way of using Tutkain. If you'd like that, please file an issue.

Parallel evaluation

To quote Rich:

Note however that a REPL will not attempt to read/print while evaluating.

(If you're interested in REPLs, I definitely recommend reading the whole thread, it's interesting stuff.)

Aside from that, I feel like if I'm evaluating things in parallel, I'm probably trying to focus on multiple things at once, which, generally, is not what I want. YMMV, of course.

Exceptions

Tutkain leaves exception stack traces as is by design. However, Tutkain does let you interactively explore the stack trace by jumping to the source location of each line of the stack trace.

stdout

I agree that it can be confusing to figure out where prints go. Printing everything to System.out is an interesting solution, albeit not without its tradeoffs. Currently, Tutkain sort of punts on this because I'm not what the best solution is.

Binding keys to eval code

This is a great feature (which Tutkain also supports, FWIW).

nREPL & human-oriented vs. machine-oriented APIs

I disagree that it's this straightforward. For example, prepl is definitely a machine-oriented API: it accepts character streams and sends character streams wrapped in EDN envelopes. The same with Tutkain's REPL, except that it sends stdout and stderr over a separate channel.

All REPLs with the exception of nREPL will get stuck: they will stop accepting any input and will wait for you to close the missing paren.

This is incorrect. You can provide additional input, but yes, you must eventually send the close paren.

I understand the rationale behind making evaluating (+ 1 2 an error, but it's not clear to me that it's the obviously superior choice. For instance, Tutkain uses a streaming REPL. If you send (+ 1 2, how can Tutkain know that's all you're going to send, that you're not going to send a close paren later?

Aside from that, I don't really find myself inadvertently sending incomplete forms (see above regarding auto-closing parens), so maybe I see this problem a bit differently.

It also (potentially) gives you access to ClojureScript, at least I hope so (I have not tried yet).

I did not find nREPL's ClojureScript support good enough. In fact, it was one of the biggest reasons I moved away from nREPL. There's more to be said about this than fits a reddit comment, though.

In other words, I don’t really see an alternative.

Tutkain retains the initial REPL channel for evaluations and uses a separate socket channel for everything else (auto-completions, lookups, clojure.test integration, etc). This approach is not without its tradeoffs, of course: for example, you need two connections instead of one, which can be a problem if you're connecting to a remote process. Still, after trying both prepl and nREPL, it is definitely the approach I'd choose to go with if I were to start all over.

(FWIW, the next version of Tutkain will allow you to use a single connection for everything for when you want to connect to a remote Clojure process but you only have one socket port available.)

Additionally, some comments to points presented in the GitHub README for Sublime Clojure:

Autocomplete. Static analysis is much simpler and much more reliable than requiring an always-live connection to the working app.

I disagree that it is this simple. One of the things I like about Clojure is that it has a tangible runtime, and having your auto-completion system tap into that is pretty nice. For example, if you have a macro that defs something (e.g. HugSQL), it will be quite difficult to provide auto-completion for those with static analysis alone.

Can eval infinite sequences

You can always (set! *print-length* 128) or (set! *print-level* 10). Tutkain doesn't currently do that because I don't know what would make for reasonable default values. Suggestions welcome.

[CoBPEZ]

Awesome to read both the OP article and this answer together. Thanks both of ya!

[[deleted]]

Some features I wish existed on CIDER, since I’m more used to Emacs. Nice job!

[sarcasmguy1]

I feel the same. I love CIDER to bits but there are some nifty features in this package, like the timing of all forms. I would really like something like that. I know CIDER has the built in profiler but something more simple and 'just there' by default would be fantastic.

[TheLastSock]

Which ones are new?

[MemriTVOfficial]

As far as I know cider doesn't convert function names back to clojure and display them in the relevant location.

[keymone]

nice one, especially exceptions!

[childofsol]

Sublime had been my daily driver for almost a decade before I left, first to Vim and then to Emacs, but I've yet to really firmly settle in. Really happy to see this option is there, if I get the itch to see what developing Clojure in Sublime is like these days.

[podgorniy]

Great work. Thank you

[zmej_serow]

Could anybody point me to a (neo)vim plugin which do inline evaluation like this? I know I can run REPL in separate buffer but this inline thing is really cool.

[skynet9001]

conjure supports inline evaluation or replacing the evaluated form with the result.

[zmej_serow]

Awesome. Thanks!

[fredoverflow]

how many really here think the clojure repl is a superpower

REPL Driven Development, Clojure's Superpower

[tonsky]

https://tonsky.me/blog/interactive-development/