Emacs isn't for everyone (2010) | Hacker News Reader

Emacs isn't for everyone (2010)

briancarper.net

38 pointspmoriarty20 comments

Emacs is good at integrating with Git too. So good that there are four or five different Emacs-Git libraries, each with a different interface and feature set. I gave up eventually and went back to using the command line.

This is superficially true but fundamentally incorrect. There is one Git mode that everyone uses: Magit. Magit is incredible; it is one of a couple Emacs integrations that make the tool it integrates with better, in a significant and meaningful way.

I'm not a "use Emacs as my shell", "read my email in Emacs" kind of person. And I am nowhere nearly as effective in Git on the commandline as I am with Magit.

Use Magit.

To be specific, magit enables a couple of incredibly useful workflows, like the "what changes have I made that are outstanding? review them, jump to the file in question to gain additional context if confused, stage individual changes and THEN commit" workflow (a compelling way to review your work for bits you'd forget with commit -a and far more convenient than git add -p), the "darnit, I just lost my place in the code again -- I know, I'll find it in the diff and jump to the line" workflow, and a number of other interactive repository history-viewing workflows.

The functionality provided by magit and a couple clever hotkeys to find code and run tests have proven in my own experience to be excellent foundations for developer productivity in any medium-to-large sized codebase.

I couldn't live without magit. It has really improved the way I work.

There is one Git mode that everyone uses

This is actually a bit of a problem. Even with many things available out there, some things are more useable than others, and it takes quite a bit of digging to figure out which packages you want to install.

I think people who write up their experiences in emacs and give suggestions about which packages are genuinely useful, and which alternatives aren't, are being really helpful.

Actually magit is the second most downloaded package from MELPA. It's kinda hard to miss it.

Actually magit is the second most downloaded package from MELPA.

Thanks. I didn't know MELPA had download counts, now I do. But there is nothing in `list-packages' that hints at this, really, it's just a list of packages.

It's kinda hard to miss it.

The person who wrote the article managed this easily enough. Emacs packages also interact with each other (e.g., completion minor modes and language major modes, things like flycheck). I still think there's a fair amount of uncertainty about what packages one should install, and that projects like https://github.com/bbatsov/prelude are really helpful in this regard.

> The person who wrote the article managed this easily enough.

Since it's a single data point I think it really says more about the author of the article than about Emacs...

The title of this blog-post is Emacs isn't for everyone". Another posts on the same blog is charmingly titled "Emacs undying hatred" (http://briancarper.net/blog/290/emacs-undying-hatred ). Just putting two and two together here, I'd come to the reluctant conclusion that emacs is not for brian carper (the blogger).

I used emacs for about 10 years. I got to be pretty ok with it. On a lark I decided to try vim for a few weeks and see what it was like. About 2 weeks in I was already more productive in vim. I've never even considered switching back. I don't hate emacs, but emacs isn't for everyone. But vim isn't for everyone either. Use what you like.

I think you should read the article before commenting.

You can always use emacs like Notepad until your curiosity takes hold. There are so many resources to learn emacs that it's easy to browse and learn. Reddit and StackExchange are "newer" communities.

http://emacs.stackexchange.com

http://www.reddit.com/r/emacs/

More resources for a quick start:

http://emacs.sexy

    brew install emacs --HEAD --use-git-head --cocoa --with-gnutls --with-rsvg --with-imagemagick

One could argue that if an editor needs it's own stackexchange it's somewhere in between being too complex and being self aware...

I suspect that if i had to learn emacs with the "big-bang" theory, I would be less satisfied. Big-bang is where you try to get it all at once.

My path to emacs started with MicroEMACS. Then, I ended up with a DEC workstation with emacs. What worked for me was starting with the minimum viable command set--open a file, find some text, add or change some text, save the file, exit. Then add a new command or two as you go along. In the 22 years that i have been using emacs, there hasn't been a period of concentrated study. Maybe a few minutes at a time picking up something new.

If I had to teach someone learning emacs to "Refactor this java code", I'm not sure how I would go about instructing someone to do that.

But it serves me well for most of my programming and writing.

Over four years have gone by since this post was written and there are now a number of other options for working with Clojure. For example, Counter Clockwise adds Clojure support to Eclipse and Light Table is an editor built from the ground up (in ClojureScript) that adheres more closely to modern UI idioms.

You can see which development environments are most popular in the 2014 State of Clojure survey results [0]. It's interesting to note that Emacs is still by far the most popular.

[0] https://cognitect.wufoo.com/reports/state-of-clojure-2014-re...

I am less then convinced that relying on Emacs as a primary environment is a problem, but I think that not documenting the relevant features of emacs and the relevant emacs mode(s) for your language or tool the same as you would if it was a custom, language-specific environment is a problem. Too often the relevant emacs mode is documented with the assumption than any new user of the language already has a broad general proficiency with Emacs.

it's nice to see an article that says "X isn't for everyone" in the field of text editors.

While the author talked about emacs being "painful" to learn, they later rephrased in terms of a time investment. But I don't think it's just about a time investment. Some people find the process of learning new key bindings, workflows, etc. more painful than others.

I notice that every single person on my ~5 person team uses Eclipse, instead of Emacs or Vim. That's probably partly due to the influence team members have on each other. But I think it's also because we chose (or were assigned) this team based on certain personality traits. The team's product is focussed on making certain hard to use things easier to user. I think that the people who could relate to this product, are the sort of people who experienced the "pain" of learning things like emacs more than others.

I think that we need to acknowledge that people are different. We should value the people who are capable of learning things like emacs with little psychological difficulty. But those of us who like things to be easy and intuitive from the start, should use our visceral experience or hard to use products, to guide us in making easier to user products for others.

And the alternatives are... nothing beyond text editor + terminal, it seems. So does anyone have any plans?

If you're working on clojure, there are many alternatives to emacs. Counterclockwise for if you want to do editing in eclipse. Enclojure if you want to do work in netbeans. vsClosure if you want to work in visual studio. Emacs is not the alpha and omega; there are other tools out there which quite possibly have better workflows depending on your need.

Cursive (an IntelliJ plugin) is probably the #2 behind CIDER/Emacs right now.

Reply on news.ycombinator.com