Live data from Hacker News

Buying into the Emacs Platform (2018)

two-wrongs.com

1–10 of 136 posts

Re: Buying into the Emacs Platform (2018)

#2
Very nice list, thank you for the writeup and for sharing this!

One interesting thing about the Emacs modes listed here is that many one of them are by themselves already enough to justify the use of Emacs for at least someone in specific application domains.

For example, there are statisticians who do not use much of the breadth of Emacs, except for the listed ESS mode, and who do a lot of their work in that mode. The same for magit, Org mode, calc, dired, Tramp and others.

In addition to this richness in features and flexibility, a major attraction of Emacs is that switching between all these aspects is instantaneous.

Re: Buying into the Emacs Platform (2018)

#4
I remember giving Emacs a serious go 5 years ago. I really wanted to like it but the archaic mode switches[1] were just too much when you are used to the convenience of Ctrl+C and Ctrl+V (I'll call these "modern shortcuts").

I've tried using ErgoEmacs[2] but what I've learned was that it doesn't really play nicely with all the other extensions.

It's a shame because I've wanted to find something a bit more powerful than nano for config and code updates on remote machines.

[1] http://ergoemacs.org/emacs/emacs_kb_shortcuts_pain.html

[2] https://ergoemacs.github.io/

Re: Buying into the Emacs Platform (2018)

#5

I remember giving Emacs a serious go 5 years ago. I really wanted to like it but the archaic mode switches[1] were just too much when you are used to the convenience of Ctrl+C and Ctrl+V (I'll call these "modern shortcuts"). I've tried using ErgoEmacs[2] but what I've learned was that it doesn't really play nicely with all the other extensions. It's a shame because I've wanted to find something a bit more powerful th…

You can use CUA mode: https://www.emacswiki.org/emacs/CuaMode

I also highly recommend Spacemacs. If VI isn't your thing, it is still great to use it, just set it up in Holy mode using Ivy.

What it adds (on top of a great default config), is bindings which start with M-m (that's Alt+m). For almost everything. Like saving your file is M-m f s (that's Alt+m release, f release, s release).

Re: Buying into the Emacs Platform (2018)

#6
post #3

The way I see it, there are two major approaches to IDEs - Extendable text editors (of which Emacs is the best example) and Visual Studio knock offs. There is no right or wrong answer, but I like the Emacs way.

I'd put it slightly differently, but I guess it is the same idea.

There are two major approaches to software development: 1) powerful text editors (vi, Emacs) or 2) IDE.

Powerful text editors are universal, but up to now their language support was often subpar compared to IDEs. They tend to do well for niche languages with no dedicated IDE, as then they're the reference editors. But for mainstream languages on can usually find IDEs with better language specific support. Still, they shine in pure editing power and after an initial investment you can use them for anything text based.

Then an IDE can have the best language support for some usually small set of languages, but is not as powerful as a vi or Emacs for pure editing.

That's the situation so far, but I see this changing thanks to the language server protocol [1]. It's the pattern seen in portable compilers, where a universal IR avoid a MxN explosion with M languages front-ends and N target ISA. Except here one avoids the M editors times N languages by having a universal protocol between an editor and a LSP server for a language. What the LSP allows is decoupling your editing front-end from the language support back-end (the LSP server).

All this is a bit young, and moving fast, but in time it offers the possibility of a no-compromise experience: use the best editor for you, and still get the best language support available. It's already possible to extract Eclipse Java support, or Microsoft Python support, and use it with any LSP compliant editor for example, with some ad-hoc work. In time, all this should get more streamlined. Which makes me happy to have invested into Emacs ;)

[1] https://microsoft.github.io/language-server-protocol/

Re: Buying into the Emacs Platform (2018)

#7
post #6
post #3

The way I see it, there are two major approaches to IDEs - Extendable text editors (of which Emacs is the best example) and Visual Studio knock offs. There is no right or wrong answer, but I like the Emacs way.

I'd put it slightly differently, but I guess it is the same idea. There are two major approaches to software development: 1) powerful text editors (vi, Emacs) or 2) IDE. Powerful text editors are universal, but up to now their language support was often subpar compared to IDEs. They tend to do well for niche languages with no dedicated IDE, as then they're the reference editors. But for mainstream languages on can us…

Also, IDEs tend to have better framework support (it's nearly impossible to write Java code without one because you want an IDE that knows about Spring or Hibernate and can make all the Gradle stuff work), but that's economics - it's easier to sell an IDE than to sell an Emacs minor mode (which would end up having to fit in a with set of other things that may or may not conflict with what you have).

Re: Buying into the Emacs Platform (2018)

#8
post #3

The way I see it, there are two major approaches to IDEs - Extendable text editors (of which Emacs is the best example) and Visual Studio knock offs. There is no right or wrong answer, but I like the Emacs way.

And ironically, I'd argue that Visual Studio Code despite the name is more of a member of the former (it is basically an Atom clone) than it is like traditional Visual Studio.

Re: Buying into the Emacs Platform (2018)

#9
No thanks.

I've had several bouts of trying to learn emacs throughout my life.

It isn't necessary to list all the benefits, sure, there's a lot. Yes, I get it's "extensible" and you can write little elisp programs to do just what you want.

Here's the obstacle: Motor skills. It just takes way to long to first memorize reams of commands and then to train your fingers to issue those commands effortlessly. In the meantime, searching, "apropos" and googling stuff isn't an attractive thing to do when you have _actual_ work to do.

That's a serious obstacle and no listing of all the awesome-ness of emacs is going to convince many of us to put in that kind of effort.

Post reply on HN