This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (21)
- # announcements (4)
- # babashka (35)
- # beginners (36)
- # calva (76)
- # cider (16)
- # clj-kondo (24)
- # clj-on-windows (12)
- # clojure (70)
- # clojure-europe (7)
- # clojure-nl (13)
- # clojure-spec (3)
- # clojure-uk (3)
- # clojurescript (34)
- # conjure (11)
- # cursive (22)
- # datomic (30)
- # deps-new (2)
- # emacs (36)
- # fulcro (28)
- # gratitude (4)
- # honeysql (16)
- # hugsql (8)
- # introduce-yourself (5)
- # jobs (1)
- # malli (4)
- # missionary (6)
- # off-topic (129)
- # other-languages (34)
- # polylith (3)
- # reagent (9)
- # reitit (27)
- # releases (13)
- # remote-jobs (1)
- # reveal (1)
- # shadow-cljs (2)
- # tools-build (3)
- # tools-deps (18)
- # web-security (7)
- # xtdb (4)
Is there currently beginner-friendly emacs Clojure setup with these properties? 1) cross-platform Mac/Windows, 2) trivial setup/config on both platforms, 3) bracket matching and re-indentation that works on incomplete expressions, 4) all basic functionality (incl buffer management, editing, repl interaction) accessible via menus or other standard UI elements, without requiring understanding emacs-specific concepts or key chords, etc.
Probably you'd be better off with Calva / VS Code, which afaik is quite hacker-friendly and definitely a polished project :) I say this because distros tend to be big and constantly changing, so you are doomed to tweak / understand what's going on
re-indentation that works on incomplete expressions might be an unsolved problem in general :)
I think that once you get the hang of
paredit or equivalent you won't really feel such a need
I have a personal Emacs setup that I rarely tweak, but I only do Clojure as a very part-time hobby, and am happy with Clojure-mode for colorization of comments/keywords/strings differently, basic indenting features, and inf-clojure for very basic REPL interaction. If I were doing Clojure development full time, I would likely be looking to either spend at least a week's worth of time spread over months tweaking that Emacs configuration, or looking seriously at VScode+Calva or IntelliJ+Cursive.
On the subject of setting up spacemacs, it requires just adding to configuration layers the symbol
> Everything else is handled for you Perhaps I'd phrase it as everything else is intended to be handled to you, but that is an arduous task in a buggy, ever changing world So it's sort of a leaky abstraction. Emacs (whether it's homegrown or from a distro) requires one be willing to debug things from time to time, especially when API breakage is commonplace and the dependency manager has its quirks. I wouldn't give up Emacs for anything else but personally I haven't yet witnessed a flawless, 'packaged' experience.
@U45T93RA6 Calva is indeed a near miss, currently mostly just missing re-indentation of incomplete expressions, for which I've posted an issue. Lately I've been using Cursive, which does a better job of that, as have other tools in the past (like Counterclockwise and quite a few Common Lisp tools, etc).
@UK0810AQ2 perhaps there's no good answer to "why emacs," except that I try to re-evaluate my choices periodically and someone recently showed me that gnu emacs does have buffer management in a menubar at least, so I wondered if there was a more complete emacs-based solution these days that I should be considering. It sounds like the answer is probably no, and that I'll probably stick with Cursive or maybe switch to Calva if the indentation situation improves. FYI the main downside of Cursive for my situation is the huge amount of incidental complexity, involving things that my students won't understand or have any use for, but which must be dealt with in one way or another (even if just to ignore them) to do simple things.
If your students learn "I'm giving you one way to set up editing for this Clojure programming language that I understand and can help you with. Programmers throughout the world get into holy wars on preferences over such things, and you are welcome to participate in them outside of class, but if you have questions about the setup I've given you, I can help you. If you are a software developer for any significant length of time, you will likely develop your own strong preferences and customization settings for your favorite editor environment over time, and/or for several editor environments at different times in your life." That is a nice heads-up for anyone who hasn't learned that already, for what is probably coming.
@U45T93RA6 FWIW I know this is controversial but as a many-decades Lisper and Lisp teacher, I find paredit to be counterproductive, both for myself and for my students. I probably should have added requirement 5) paredit is off by default, or easy to turn off. Same for parinfer, but more so.
Check out #doom-emacs - it's got a very nice Clojure setup right out of the box. The one caveat is that it uses vim keybindings, so it helps to have some vim experience
Thanks @U0CMVHBL2 -- that's good advice!
Thanks @U01BTEYDC05 -- I will check it out, although I'm doubtful that vim keybindings will be helpful in my context. I'm aiming for as close as possible to no learning curve, because the editor behaves like the text editing environments they already know from the rest of their lives, just with some extra Clojure programming goodies (bracket matching, re-indentation, send to REPL, etc) that are easily discovered and used via standard UI elements.
I found from experience that vanilla spacemacs + clojure "just works" ootb. However, if you want to go for the least opinionated platform, it would probably be VS Code. If you're targeting students, it's also fair to ask yourself if you're imposing your habits on them. If they're used to some form of text editing, I wouldn't force them out of it.
To @UK0810AQ2’s point, if you're looking for as close as you can get to "zero learning curve", you'll likely want to skip emacs altogether and use something like VS Code. Emacs is awesome, but it has a ton of unique quirks that will frustrate beginners.
As much as I like Emacs, I second this, go with VS Code and save
yourself them the trouble
Yep, Calva and Cursive do appear to be the best options at the moment. Calva is currently missing one crucial feature (re-indenting incomplete code) and Cursive is thick with incidental complexity.
I was just trying to see if a better emacs-based solution had emerged in the years since I last checked.
OOTB it would either be Spacemacs or Doom, both with CUA. If you want to get a feel for the viability of these solutions, and it's for students, I'd suggest the following: • try them both yourself. See how they pan out. You can disqualify them immediately if they don't meet your expectations • Find some 10 volunteer students. split to two groups at random, have them try one configuration or the other, see how it works for them
FWIW something much lighter weight would be even better, and I periodically also try to check text editors that have plugins... but so far all lack something crucial like (most often) re-indentation.
Once upon a time there was something called Clooj that was great, but I think it was abandoned, and Nightcode was great until, I think, parinfer became mandatory...
Thanks all. Just fyi I explored a bit more and plan to stick with Cursive unless maybe Calva gets re-indenting for incomplete code before my spring semester starts, in which case I'll consider switching tho that. Some day I do hope that emacs "catches up" with the FRED editor that came with Macintosh Common Lisp in the 80s and 90s, which was basically emacs under the hood (but programmed in common lisp) and met all of my criteria here except for not being cross-platform and of course being a common lisp rather than Clojure environment.
With enough Elisp coding, time, frustration, and effort, I'm sure you can make Emacs behave like almost anything you want, but then, anywhere is walking distance if you have the time. One often does not have that kind of time 🙂
I already recommended doom-emacs for a lot of friends/co-workers, and I don't see it like something it needs a lot of knowledge, doom's has modules which when enabled makes emacs behave like modern IDEs :)
@UKFSJSM38 thanks but the installation instructions themselves for doom-emacs made me pretty sure this wasn't going to be a winner for me because of condition 2 (trivial setup/config). Probably fine for many, but for some of my undergrads, particularly those with Windows machines, this looks like too much.
@U06BV1HCH I'm curious to hear more about how you find paredit counter-productive. I haven't heard anyone say this before.
I find paredit counter-productive in several contexts. I guess what I'm talking about here is strict paredit, which enforces structural soundness. I teach, and my students are usually learning a lot of new things at once, including a new language, a new programming paradigm, AI concepts, and how to develop and execute scientific research projects. I don't want them to have to learn a new way to type on top of all of this. They have well-honed text editing skills from other contexts, and I want to let them use them and get on with the work of thinking about functional programming and AI. If the editor reindents on command, then the student can see where the structure is messed up, or isn't what they intended. And they can use their existing editing skills to fix it. I can see the frustration when they're trying to do something but can't make the editor behave, preventing them from typing or moving things, or typing things they didn't ask for (like closing brackets). Another context is my own coding work. I often jump around when I'm writing, write things out of order and rearrange them, etc. I want to do this in the same way that I edit any text, which means lots of intermediate states that aren't structurally sound.
While I see your point in not overloading students with new concepts, jumping around, writing things out of order, rearranging them, etc, sounds to me like a dream scenario for structural editing, not vice versa.
I can see how structural editing would help with some ways of editing out of order, etc., but it absolutely drives me bonkers. I've been Lisping for about 35 years and still, if I have to work in a strict structural editor, I soon end up copying code into a plain text editor, editing it there (without bracket matching or re-indentation 😞), and then pasting it back into the structural editor. Super frustrating. I think one thing I often want to do is to make two copies of a bunch of code, which may itself not be balanced, and then remove different parts of each, which may end up structurally different. Trivial and natural using the editing skills that are built in to my muscles from all of the other writing and editing I do, but a weird puzzle that I have no interest in solving to edit structurally. Another thing that I think I often do is comment/uncomment chunks of code that may not be balanced, and then patch up the imbalance manually. Again, almost automatic from muscle memory using the skills I'm using to type and edit this comment, but a puzzle I don't want to think about to do structurally.
Sounds to me like you're set in your ways. That's fine, but don't confuse your habits with proper arguments. I also found it super frustrating to learn structural editing, having spent 24 years editing code without it. I even ranted about it on the Emacs IRC channel, at which point Phil Hagelberg said these undying words: "If you think paredit is not for you then you need to become the kind of person that paredit is for." That turned me around, and on the third attempt I was able to power through the pain. It was certainly worth it.
I'm not making an argument for my preferences, or opining about what kind of person anyone else should be. As a teacher of diverse classes of newcomers, though, I will indeed argue that paredit can be counterproductive. In this context it's super helpful to have an environment that allows people to edit using the same skills and muscle memory and expectations that they bring to editing in the rest of their lives, with no editing-specific learning curve, aided by bracket matching and re-indentation that works on incomplete code. As it happens, that's what I want for my own coding as well, although of course others want different things.