Atom editor setup for Clojure(Script) development in 2020

#1

If you wonder how to set up Atom for Clojure(Script) development, this is the place for you! I couldn’t find any guide online so I asked more experienced people and here you go.

You need just a few packages:

  • REPL: Chlorine - Sean Corfield wrote an inspiring post about why he switched to Atom+Chlorine. You just need to start a socket REPL in your project (see the plugin page for instructions) and connect to it. You get autocompletion, inline results in the editor, and much more.
  • Structural editing: Parinfer + Paredit - you can never truly appreciate a Lisp unless you leverage structural editing. Parinfer gives you an intuitive, simple model for working with parentheses (indent code block => include it in the previous form at lesser indent, delete ) to move it furthest right, …). Paredit provides useful hot keys to operate on expressions such as “wrap the following expression in (…)” or “delete until the end of the current expression”.
  • (Optional) linting with kondo - a good, evolving linter with warnings about bad practices

You might also want to have a look at seancorfield/atom-chlorine-setup with useful commands, key mappings, and extra support for REBL.

#2

I’m a die hard Emacs fan (been using it for close to 20 years now) and I can’t see myself switching, really, but I was intrigued by your post, and gave Atom+Chlorine a spin. It was nice, easy to setup, and looks fairly impressive (if a bit lacking in functionality compared to Cider). I would definitely recommend something like this to someone new to Clojure and with no Emacs background!

2 Likes
#3

@mvarela great to know! Chlorine is still evolving, and I’m working together with other tooling authors to make it better (and this includes integrating some Cider functionality too).

Can I ask what you did miss? So it would be easy to prioritize features on the package :slight_smile:

1 Like
#4

@mauricioszabo, first, thanks for your work on this (even as a likely non-user), it’s great!

Regarding what I missed, I only took it for a quick spin, and didn’t really go into the docs, so I can’t give you much insight, but the things I noticed:

  • Lack of jack-in functionality, so I need to go to a terminal to start a REPL
  • Functionality like the one provided by cider-eval-pprint-last-sexp. I use that all the time. Printing eval results is ok, but when dealing with larger maps and such, pretty printing becomes more important. Cider does that in a separate buffer, so it doesn’t clutter the code buffer (again, this is more important for larger data)
  • Debugger

I’ll try and give it another, deeper go, and see what pain points I notice (though I suspect those will be more related to missing my Emacs config/functionality, rather than Chlorine)

1 Like
#5

a superior alternative to pretty printing, especially for large data, is IMHO the commercial but very cheap Cognitect REBL

#6

@HolyJak, I don’t doubt REBL it’s great. I’ve never used it myself (yet), and I’ve been using Cider’s pretty printing for years, so it’s more of a habit thing. Based on Stu’s presentation, and Sean’s screencast, it does look like an amazing tool, though some people might balk at it not being free (both as in beer, and speech).

#7

Word.

I also like that you highlight that Parinfer and Paredit aren’t mutually exclusive, like so many people seem to think they are.

#8

I’m an emacs user, but I tried chlorine a bit, it is great. The thing I miss is a keyboard shortcut driven, full-featured data inspector.

1 Like
#9

:+1: I wonder if this was best addressed by an editor-independent tool that could multiple editors leverage. Some nrepl Middleware, REBL, or an open-source alternative…

What about [data walk] (https://github.com/eggsyntax/datawalk)?

I’d love something like that in Cursive. Constantly manually set! -ing print-length/level, manually pretty-printing is a brake on my dev flow.

#10

Can you elaborate a little bit? You mean, to inspect the data with only keyboard shortcuts instead of using the mouse?

If so, I too miss it :laughing:. If you have any idea on how to implement something like this, I can try to implement something

#11

@mauricioszabo, yes, pretty much that: https://docs.cider.mx/cider/0.23/debugging/misc.html#_inspecting_values

I hadn’t heard about datawalk until I saw @HolyJak mention it, but I gave it a go today, and it seems pretty cool (though it’s a bit tricky to make it play nice with Emacs, at least with my config).

#12

Hi, I think that should be something like a rebl, with some keyboard shortcuts support, have a dedicated window.

#13

You most certainly want to configure shortcuts for Paredit and Chloroine as there are none by default. See Sean’s setup and e.g. https://github.com/tkjone/dotfiles/blob/master/atom/keymap.cson

#14

Emacs was great. Back in the '80s. It hasn’t had any meaningful change in nearly four decades*. I used it exclusively on unix and other environments until Windows and the Mac established standard UIs. It is actively hostile to every user interface standard ever create. It’s still possible to be keyboard focused and use the basic standards of Windows and the Mac. Those are very close.

I get the feeling the emacs developers are proud of the impossibility to use by people coming from any non-unix environment. They were incredibly proud of adding Ctrl^x. That’s a one gesture start. If someone could create a keymap that covered 95% of standard windows, it would go a huge way to making it acceptable to 90% of developers out there. People who’ve been using emacs for three decades have a hard time using Windows. People who’ve been using Windows for one year find emacs insurmountable.

Atom isn’t great, but it’s a hell of a lot easier to use than emacs. I’ve recently installed ubuntu and wsl on my Windows machine. Pretty much to use emacs and unix focused programming environments. One of the reasons people won’t ever use clojure is the dug in bias against Windows. 90% of developers use Windows for development, even if they run their systems under unix. Hence my desire to get Atom up and running.

  • Haters need not apply. I was one of the first people to use emacs. It was great when the only alternative was vi. It’s bloated up a bit, but it’s still mostly a text editor.
1 Like
#15

I will also throw this into the mix as supplemental resources:

Clojure Text Editors

Atom + Clojure Screencasts

#16

I use Emacs Cider for Clojure on Windows, works great.

I prefer to develop in Linux, and I admit that’s where I mostly live, but I do so in coordination with Windows where I also use Emacs for notes and REPL experiments and the likes.

I think it isn’t that Emacs is averse to user interfaces, it’s that its user interface capabilities are very old and hard to change in the implementation, as well as whatever UX is provided it needs to work just as well in command line mode and without a mouse, which restricts what you can use UX for. That’s why there’s no find and replace dialog box for example.

I also disagree with it being just a text editor. It’s actually just a REPL for Emacs Lisp. And it’s only if you like that aspect of it that you’ll like Emacs. Which is where people looking for “just a text editor” might be disappointed.

Now Atom is pretty cool as well, because it is also trying to use the Emacs philosophy to some extent. Being mostly a reifiable Electron app. Unlike VSCode and VIM which aren’t self-modifiable in all aspects, Atom tries to be, similar for Emacs. Atom just drops support for command line and no mouse. And it is built over Electron and JS running interpreted and that makes it slower and more memory demanding than Emacs.

I actually have an Emacs config that gives it 95% of Windows shortcuts. But it turned out it isn’t really the shortcuts that turns off people. It is much more the keyboard driven command line aspect of Emacs being an Emacs lisp REPL.

That’s because if you think of the standard Windows short-cuts, they are just inefficient for doing everything without the mouse. So you still need to learn a lot of additional keyboard gestures and commands to use Emacs, even with all standard Windows shortcuts available.

Anyways, I do think a lot about Emacs could be modernized, but that’s a big effort. And once you get over that initial unfamiliar hump, its really not a big deal, so no one who knows Emacs is motivated to fix that part either. Kind of a weird chicken and egg.

2 Likes