
Making Emacs Popular Again - todsacerdoti
https://lwn.net/SubscriberLink/819452/1480c3a59d3d9093/
======
ipv6ipv4
New employee 1 workflow at company X:

1\. Install VS Code

2\. Click extensions and install language specific plugin

3\. Work

New employee 2 workflow at company X:

1\. Install emacs

2\. Try to install some source code indexing tool

3\. Tool is missing 13 dependencies, so spend 4 hours finding, installing and
configuring the dependencies.

4\. Spend another couple hours reading non-existent to terrible documentation
(documentation so bad in places that even Stallman finds it useless) across 3
packages and editing .emacs to configure an otherwise unusable result. It
looks like source code indexing is working! It isn’t...

5\. Go home

6\. The next morning, find the default color theme garish and spend another 4
hours installing themes and theme managers, reading more terrible
documentation, and finding that obscure TTY settings must be tweaked for emacs
to decide that it can use a theme (even though it has no problem displaying
the colors in the first place)

7\. Spend the rest of your tenure constantly hitting code indexing and
highlighting bugs that need constant tweaking and workarounds. You often find
yourself using find/grep because it’s often faster than debugging the latest
indexing bug.

8\. Discover that the vaunted ‘lightening fast editing’ with ‘multiple
cursors!’ and this mode or that mode don’t matter because the slowest part of
the creative process is the creativity and not your typing.

Emacs is a terrible experience with defaults suitable for a 70s TTY. That you
can change it misses the point. The fact that everyone has to have a non-
empty, non trivial .emacs file means it is maximally unsuitable - for
everyone.

In a few years, VS Code has achieved better out of the box functionality for
working professionals than emacs has in 40 years.

~~~
michaelmrose
New employee 3 workflow at company X:

1\. Install Emacs

2\. Sync existing config via git

3\. Work

New employee 4 workflow at company X:

1\. Install Emacs

2\. Spend 2 hours learning default Emacs

3\. Work

New employee 5 workflow at company X:

1\. Install Emacs

2\. Spend 1 - 2 hours learning default Emacs

3\. Spend 2 - 4 hours googling interesting Emacs packages, in each case going
to their GitHub repo to read the directions, adding a use package form to your
config with the settings that seem best from reading the directions and
testing it to see if you like it until you have a useful set of functionality

4\. Work

You can probably spend plenty of additional time tweaking emacs to be
everything from your mail client, your music player, your IRC client, insert
task here but if you do this in the time you would be watching Netflix instead
of the time you are supposed to be working you probably wont have trouble
getting your work done.

I literally have no idea what you are talking about insofar as TTY settings,
themes, indexing bugs highlighting bugs, or constant workarounds. I installed
Emacs the graphical application, opted to spend 2 hours reading a book wherein
I learned how to use emacs and picked a theme by searching for the string
emacs theme and picking one that looked cool. I ran package-install typed the
name of the theme, hit enter and evaluated (load-theme 'theme) in my config.

I have no idea why you would be running Emacs in a terminal in the first
place.

~~~
SkyMarshal
Don't forget:

New employee 6 workflow at company X:

1\. Install Spacemacs, don't bother fiddling with the config

2\. Spend a few hours working through the tutorial or reviewing the excellent
docs [1]

3\. Work. Become a better developer [2].

[1]:[https://www.spacemacs.org/doc/DOCUMENTATION.html](https://www.spacemacs.org/doc/DOCUMENTATION.html)

[2]:[https://blog.osteele.com/2004/11/ides](https://blog.osteele.com/2004/11/ides)

~~~
clarry
1\. Install Spacemacs.

2\. Observe a flurry of errors every time you start emacs. Ignore and hope it
works because no idea how to fix any of it.

3\. Find, among a million others, the command that seems to do what exactly
what you want. Command gives an error. Dunno how to debug.

4\. Watch emacs features that should work ootb not work because spacemacs or
evil or one of the three bazillion packages did something that broke it. Dunno
how to debug.

5\. Complain on HN, get told you need to be using the master/develop version
of packages because upstream devs don't care about maintaining stable
releases.

6\. Use unstable packages. Observe new errors whenever you update or do
anything. Hope it doesn't break more than it's already broken.

~~~
pantulis
This.

While Spacemacs is an admirable effort, I think it misses the point: Emacs is
an editor for power users from another era, so it requires huge effort by the
user to become truly productive by todays standards. Trying to create layers
upon layers of "friendlines" and eye candy is not going to solve the
complexity.

I've always said that it's better to grasp Emacs with a vanilla config or a
small starter kit and see if you can make it grow step by step in a journey
that takes years.

vim is a similar rabbit hole, maybe less deep.

The real question is: can VS Code make you productive _enough_ in less time?

~~~
throwanem
Pretty much, yeah, from what I've seen. Against the shockingly low ambient
baseline of "editors that aren't Vim or Emacs", VS Code's highly usable OOTB
experience and broad extension ecosystem are enough of an improvement to
constitute a real win despite being so poor by comparison with a thoroughly
evolved configuration of either of the Two True Editors.

I stick with Emacs because, now having invested more than a decade in learning
to get the most out of it, I can do a lot of things in seconds that take VS
Code users minutes or hours. But the converse is also true, and I think will
only become more so. Especially in the realm of remote collaboration and
mentorship, which has never been more important than it is today, VS Code does
things that Emacs simply can't, and almost certainly never will.

That's fine, of course. That different tools should specialize in different
things is perfectly reasonable, and I don't have the kind of emotional
attachment to Emacs that would give me cause to be upset with its dwindling
user share or its lack of broad appeal. It serves me very well, but it's not
something I advocate, although of course I mentor those who take an interest.

I am looking at picking up VS Code, with suitably Emacs-esque keybindings, for
the mentoring-in-programming aspect of my role. That's where pretty much
everyone else is, or is going. And in that context, its less fluent and less
extensible user interface is probably a boon, once I get over being frustrated
by it. In the context of teaching someone less experienced, acting with the
speed of thought is really best avoided; if you don't explain why you're doing
what you're doing, or offer the chance for questions and discussion,
essentially the entire point is lost.

~~~
cdrini
> I can do a lot of things in seconds that take VS Code users minutes or
> hours.

Out of curiosity could you provide some examples of some of these?

~~~
jamespo
"Out of curiosity" = "I'm going to nitpick this to hell and back"

~~~
cdrini
Ahh, that's not what I was going for. I'm actually just curious. I'm willing
to give emacs a try, but it just seems like it has kind of a steep learning
curve, so want some strong reasons to know if it's worthwhile. This was the
best I could find googling:
[https://www.reddit.com/r/emacs/comments/8h1cxa/any_long_time...](https://www.reddit.com/r/emacs/comments/8h1cxa/any_long_time_emacs_users_tried_vscode/)

~~~
throwanem
I mean, a lot of it is just the kind of complex one-off text transformations
that would normally require a throwaway script or program to express. (They do
in Emacs too, but you can write it as inline Lisp forms in the replacement
side of a PCRE find-and-replace, and not deal with any boilerplate.) Refactors
and stuff like that all happen through LSP providers, just like in VS Code.

If you're looking for a strong reason to think Emacs is worthwhile as a
totally new user, I'd point instead to Magit, an extremely powerful and
comfortable git porcelain, and Org-mode, which is simply the most powerful and
flexible single-user notetaking/outlining/live code notebook tool yet created.
Those are the two Emacs features I see most often mentioned as the subject of
sentences like "I don't use Emacs for anything else, but I do use it for X
because nothing else comes close".

That said, as I mentioned above, I'm not really here to evangelize Emacs. It
definitely does have a steep learning curve, enough so that unless you see a
clear killer feature (in my case, TRAMP's transparent remote file editing,
since I edited remote files a lot in those days), it's not likely to be worth
the trouble.

~~~
lytefm
This. After having fiddled around with Emacs over the weekend, having tried
out Spacemacs and Doom and working through some tutorials, I concluded that I
definitely won't replace VSCode with Emacs for coding any time soon. As a Git
& PIM-Tool, it seems to be useful though.

------
agentultra
Does it need to be popular or need more users to become maintainers?

I use emacs because I can't imagine using anything else that has half the
features and is harder to extend. I can't imagine why it needs to be popular.
It's a programming environment that happens to have a text editor built in.
That appeals to some folks but I can't imagine why someone interested in
writing for publication would choose it over Scrivener or a word processor and
why it's desirable to attract such users.

If I had a horse in the race I'd focus on the developer experience. Make it
easier to extend, make the runtime faster (the native compilation stuff is
super cool), better unicode support, alternate input methods, etc. If people
want to use it for publishing it should be easy to write a package to cater to
those users.

For me, a long time emacs user, I think the biggest concern I have is ensuring
that the project is sustained by new developers.

~~~
wayneftw
Perhaps adding JavaScript to the list of languages that you can extend Emacs
with would be a good start -
[https://www.emacswiki.org/emacs/CategoryExtensionLanguage](https://www.emacswiki.org/emacs/CategoryExtensionLanguage)

~~~
state_less
Or, emacs in the browser. Popular editors like VS Code use monaco and now
github has codespaces [1] which is running in the browser.

People live as much or more in the browser as the terminal these days, so
bring the emacs sauce to where the people live. Maybe you could get some of
the c compiled to web assembly, and the lisp would follow? It'd be neat to
open a buffer to the page emacs lives in and start editing, call JS code, or
embed emacs into a page as easily as monaco. Maybe the GUI components could be
made out of HTML 5?

1\. [https://techcrunch.com/2020/05/06/github-gets-a-built-in-
ide...](https://techcrunch.com/2020/05/06/github-gets-a-built-in-ide-with-
codespaces-discussion-forums-and-more/)

PS. Rough sledding for Gitpod with this announcement.

~~~
bitwize
Emacs in the browser, you say? _smug Willy Wonka face_

[http://www.ymacs.org/](http://www.ymacs.org/)

~~~
state_less
That’s a cool project and a nice effort. It renders pretty well on my iPhone
too. Not able to edit on the phone, but still.

I see some other good ideas here too that could maybe give emacs a fresh
breath in the new world of IDEs in the browser/cloud.

------
olivierestsage
I hear a lot about the declining popularity of Emacs, but I always wonder how
much it is overstating the case. As a tech enthusiast but (mostly) non-
programmer, my perception has actually been that the "cool factor" of Emacs
has been on the rise. Around 2011 or so, I hardly ever saw mention of it
online. Now a day hardly go by on places like Reddit's "unixporn" board that
someone doesn't post their slick setup with Emacs/Doom Emacs/Spacemacs on
display.

I know that that Reddit board is sort of ridiculous and the jokes about it
write themselves, but I nonetheless feel that Emacs has attained a certain
counter-cultural "cool"/cachet in recent years that it lacked a decade ago. In
my opinion, this is a good sign for its future, all things considered. These
threads are always full of comments about how vscode has surpassed it, etc.,
but I don't think anything can change that--Emacs will ever truly satisfy
those for whom vscode is presently the superior tool, and conversely, vscode
is unlikely to satisfy the Emacs user.

Like vscode, Emacs is in every sense a practical tool; it is simply that it is
practical in service of different needs. It is a practical tool for someone
who takes active pleasure in the _cultivation_ of a practical tool, in the
process of learning and discovery involved. Because this will never describe a
majority of users, I don't think Emacs will ever capture a majority of
developers or whatever, but it seems poised to continue to attract very
dedicated ones who find the cultivation of a personal work environment in a
ridiculously powerful 40-year-old program appealing in and of itself.

~~~
chairfield
Anecdotally, I started learning Emacs a few months ago and am very happy with
my decision. I first considered trying roughly 10 years ago, but didn't see
the thriving package ecosystem I see today, starting with projects like
Spacemacs and Doom. After some time trialing my options, I stuck with
Spacemacs, and that choice saved me time in reaching my goal of transitioning
my knowledge and project management to org-mode.

Even with training wheels, though, getting started wasn't simple. It's had a
very choose-your-own-adventure feel to it. After some early thrashing, I've
now found my favorite resources, have a decent sense of what's out there, and
am even using org-mode to track my overall learning progress. It's become
self-reinforcing.

With more modern tools getting better and better, I find it no surprise that
VS Code and others are gaining market share, and that the Emacs user profile
is becoming less diverse. But I think there will always be a place for a
tool(box) as powerful and configurable as Emacs.

~~~
bobmichael
I've started learning Emacs a few weeks ago, and have had a similar experience
as you. One different is that I considered going with Spacemacs / Doom but
decided to take the route of starting from an empty init file and slowly
building up from there (at least for now). I identify strongly with the
feeling of thrashing; the wealth of different information and flexibility of
the program itself can be overwhelming. Would you be willing to share some of
your favorite resources (and why you chose them)? That would be immensely
helpful for a beginner like me.

~~~
chairfield
I think there's a lot to learn from starting from scratch, and it's something
I hope to do too.

Gladly! I'll keep the list to what I've studied so far. Here goes: \- If you
ever want to explore, say, Doom (Spacemacs is likely too bloated for someone
who gravitates to a vanilla config), chemacs[1] is a nifty, simple profile
switcher \- I think there's a lot of value in studying what they've done with
their mnemonic keybinding systems (I love being able to narrow to an org-mode
subtree and widen again with =, n= and =, N=, respectively, as but one of many
examples) \- Sasha Chua is a good source, as she's very knowledgeable and put
out a drawn 1-pager[2] on starting Emacs - it's geared towards standard Emacs
keybindings \- Personally, I'm a huge fan of Evil-mode for Vim keybindings, as
they're powerful and portable and I had basic familiarity with Vim before
picking up Emacs \- I haven't found a rough edge in Evil-mode yet - it seems
very refined \- Dired is worth getting a handle on early since any improvement
in how you can navigate Emacs translates \- Magit is pure magic, and I now
have my full ~/org under version control with what feels like near-0 overhead
\- Seorenn makes mostly Spacemacs videos[3] and Zaiste Programming makes Doom
videos[4], but I find them useful regardless of my config - you may just want
to skip to the videos on packages that interest you \- If you haven't yet,
choosing either Helm or Ivy is _huge_ \- Personally, I'm happy with helm in
Spacemacs and I was happy with ivy when I used Doom - heck, even my friend is
happy with Ido \- It's fun to explore more efficient ways of jumping around -
the Avy package is very popular for this (check out `avy-goto-char-timer` in
particular) \- Also, I'll note that I've been able to find a clean 1- or
2-pager reference card for every major package I've searched for

But, truly, the jackpot for me has been org-mode. At first, I used it as just
another knowledge repo, like a more efficient (yet local and text-centric)
version of Evernote. But, now, I'm working through the book _Getting Things
Done_ and believe that there is no better tool on the planet than Emacs and
org-mode for implementing the core and majority of that system. Regardless,
having a specific implementation goal has aided my learning dramatically.

Specific to org-mode: \- I started with the Org-mode Compact Guide[5], which
I'd study and practice during 20-30 minute sessions every other day or so - it
moves fast and I was happy with my org-mode skill after only having worked
through Chapter 2 \- However, perhaps the best way to start learning org-mode
is Worg[6] \- Occasionally, I've found that the Compact Guide lacks an
important command for my own workflow, so I'll usually go to the Org-mode
Manual[7] itself \- When learning to configure Refiling, though, I found
this[8] to be the best resource \- Finally, I'm a big fan of "org indent mode"
\- it keeps Git diffs clean when changing indentation yet displays my contents
appropriately indented

This is a lot, and I'm sure your path will be different than mine, but I hope
you find some nuggets in there. Best of luck!

[1] [https://github.com/plexus/chemacs](https://github.com/plexus/chemacs) [2]
[https://sachachua.com/blog/2013/05/how-to-learn-emacs-a-
hand...](https://sachachua.com/blog/2013/05/how-to-learn-emacs-a-hand-drawn-
one-pager-for-beginners/) [3]
[https://www.youtube.com/playlist?list=PLPNohcoOBa5GGreLyc3nn...](https://www.youtube.com/playlist?list=PLPNohcoOBa5GGreLyc3nnSIGYB9UeVO_X)
[4]
[https://www.youtube.com/watch?v=rCMh7srOqvw&list=PLhXZp00uXB...](https://www.youtube.com/watch?v=rCMh7srOqvw&list=PLhXZp00uXBk4np17N39WvB80zgxlZfVwj)
[5] [https://orgmode.org/guide/](https://orgmode.org/guide/) [6]
[https://orgmode.org/worg/](https://orgmode.org/worg/) [7]
[https://orgmode.org/org.html](https://orgmode.org/org.html) [8]
[https://blog.aaronbieber.com/2017/03/19/organizing-notes-
wit...](https://blog.aaronbieber.com/2017/03/19/organizing-notes-with-
refile.html)

------
jrimbault
> "Perhaps we should implement a mode that puts cosmetics on Emacs so it will
> appeal to those who judge by the surface of things."

I'm sorry to react to first quote, but as I kept reading I kept coming back to
it. My thoughts on that : how you present yourself is how you want (and are
going) to be judged.

In general I think Emacs has been user-hostile, as said here, just by its
terminology. Nobody outside a minority of devs (a minority even among
programmers) refers to Ctrl+c as C-c.

> Yes, make Emacs appealing and user friendly. But don't forget that a
> masterful tool in the end requires mastery, which can't come for free.

And the old "I have suffered therefore the others have to suffer".

~~~
jmoss20
I don't think emacs is "user-hostile" on purpose. You have to keep in mind,
it's nearly 45 years old. This is almost unprecedented in computing.

Today's users expect different things than users did in the 70s (who expected
different things than users in the 80s, 90s, so on). Emacs has been relatively
consistent through time, which has been a huge boon to emacs users. The
tradeoff is against current user's intuitions -- for better or worse, emacs
does not work like other popular software today.

Calling this "user-hostile" comes off somewhat entitled. Emacs developers in
the 70s/80s/90s/00s simply didn't know enough about today's users to cater to
us, even if they wanted to. That's hardly their fault.

So, todays way and the emacs way have diverged some, and it does take a bit of
effort to learn. Not because emacs hates you! But because emacs is ancient.
The (objective, non-stockholm-syndrome) reward for your efforts to understand
it are a) mastery of a system useful enough to survive this long, and b)
mastery of a system that isn't likely to change out from under you.

~~~
freddie_mercury
> You have to keep in mind, it's nearly 45 years old. This is almost
> unprecedented in computing.

We can acknowledge Emacs's longevity without straying into unsupportable
hyperbole. Emacs is nowhere close to unprecedented in its age and not remotely
close to the oldest piece of software still in existence.

GNU Emacs is from 1984. It is a reimplementation of the earlier 1972 Emacs.
This matters, since if you're including reimplementations then obviously Unix
itself, which is used by many of us every day, it older. And if you start
counting from 1984...that's not especially old.

~~~
jmoss20
Fair enough! But the point stands, no?

I pointed out emacs' age to note how users expectations of editors have
evolved over that time. Certainly there is older software -- but is there any
other user-facing software that has survived such a dramatically shifting
landscape? _That_ is the part I find unprecedented (and the part relevant to
GP).

~~~
b3n
> is there any other user-facing software that has survived such a
> dramatically shifting landscape?

Yes. Microsoft Word, for example, is older than GNU Emacs.

------
wwarner
I use emacs and have for a really long time. Unfortunately, I don't recommend
it to anyone because I think the costs of learning it outweigh the benefits.

When I read this article, I was surprised that my gripes don't overlap much
with those listed in the article. I do really like the idea of "new user
detection", which would take a user through a short configuration process if
the .emacs file was missing.

I think my main gripe is async. I really love emacs for tramp, but there are
so many operations that block working on all buffers while one buffer is
waiting for i/o.

~~~
01100011
Choosing an editor like emacs or vi is a major decision which will have long-
lasting effects. I love vi, and the homerow movement keys are now hard-wired
into my brain, so much so that using 'normal' applications is noticeably
frustrating. Sure, I can try to add plugins to everything, but that only goes
so far and requires a lot of setup work on every new computer or VM. That
said, the old school editors bring plenty to the table for programmers if you
take the time to learn them well.

Honestly emacs sounds wonderful on many levels, but I learned vi first and I
think that will keep me from ever switching. There's probably a vi-mode for
emacs I guess... anyone have any comments on that?

~~~
mplanchard
I’m also a long time vim user. I basically cannot edit text without vim
keybindings these days.

A few weeks back I decided to give emacs a third try, after installing it once
a while ago and giving up, installing it again with spacemacs a bit later and
giving up when I couldn’t figure out what layer of that behemoth errors were
coming from or how to fix them.

Anyway, I finally decided to give it another shot with vanilla, with the first
thing to do being to get evil mode working (which is vim keybindings). Getting
to that point was a struggle, honestly. I felt handicapped without vim
bindings, and I ran into some errors downloading packages after I added MELPA
to my .emacs file. After an hour or two, I managed to get evil mode going, and
I guess just the little bit of familiarity in what was otherwise a VERY
overwhelming and unfamiliar experience made everything feel much easier.

Getting to where it was easy to install and see the effects of new plugins one
at a time rather than getting the massive overload of spacemacs was super
helpful. It made the learning curve smoother for sure.

I mostly did all of this because I wanted to try org mode, and honestly that
has been amazing. It’s a very very good way of taking notes and tracking
tasks. I’ll probably spend some time next time I’m feeling like tinkering
trying to get it more like an IDE, but for now I’m happy just with org mode.

~~~
RMPR
That's how I settled things down finally, Emacs for org-mode and magit
(actually spacemacs) synced with all my devices with syncthing, on mobile I
use orgzly, and everything is under version control. I use Vim for everything
else.

------
gfxgirl
I've used emacs for maybe 18 months solid. I never found it had a single
feature that my other editors didn't have (not saying it doesn't, just staying
I didn't run into them).

My other editors can be extended via scripts. My other editors (mostly) have
keyboard macros, repeat, etc.. My other editors can be used efficiently
keyboard only. My other editors debug various languages. My other editors open
shells in the editor. I don't care about org mode, I care about editing code.

Conversely many other editors do their best to be dev env aware,
reading/understanding/integrating various language environment project files,
which was never something I found in emacs (maybe it's all been added since I
my emacs times)

About the only thing I still would consider using emacs for is editing in a
shell remotely but (a) usually it's not already installed and (b) usually I'm
not editing anything serious remotely.

What's special about emacs? What am I missing that's not in other editors?

~~~
metroholografix
Emacs is not an editor, it is rapidly-programmable-at-runtime-evolvable
software that is designed to:

\+ Help you realize how _you_ best deal with information.

\+ Help you manifest your realization through _rapidly_ molding Emacs into
your conceived model.

It is also the closest thing we have today to the Lisp Machine paradigm. I
wrote this earlier today:

    
    
      You'll get the most out of Emacs if you treat it as an 
      investment and put in the time to learn at least some Emacs 
      Lisp so that you can confidently explore and customize the 
      rest of the system. You don't need to become an expert 
      overnight, just learn enough to navigate the system (which 
      is self-documenting and geared towards helping you perform 
      that navigation).
    

Yes, it may feel weird or out of touch with contemporary aesthetics but that's
really because it doesn't come with strong, tunnel-like notions of _how you
should think_ and _how you should work_.

It is not easy today to come to terms with a tool that's simply designed to
help you craft a computing experience, since we've been so conditioned to
expect somebody else's model be there from the beginning:

[https://xristos.sdf.org/why-emacs.txt](https://xristos.sdf.org/why-emacs.txt)

~~~
balloneij
At what point does this get in the way of your programming? If there's always
more to learn about the tool, I think that would bother me. I would like to
like emacs, but the couple times I tried it it gets in the way because I don't
know it well enough. Vim seems more appealing because there is less to know
up-front, but it is still extensible

~~~
bitwize
At the point where you find yourself dinking with Emacs and making excuses to
yak shave instead of getting your work done -- which, given that it's Emacs
and makes most other tools seem positively stone-knives-and-bearskins by
comparison, is in practice a quite tempting trap to fall into.

The best way to approach things is incrementally. Find some pain point in your
current workflow and write a little bit of Elisp to automate the painful bits.
Let's say you're running manual UI tests and then eyeball-grepping the logs in
your backend. "But nobody does that!" you say. "Why would anybody do that?"
Heh. You'd be surprised. Anyhoo, thr crank has to be turned on a prod deploy
by COB Friday and you've got no time to investigate Nightwatch or the other
UI-testing libraries out there, let alone integrate them with a log watcher.

Thankfully you're an Emacs user! So you write a little Elisp to start the back
end, capture its output in a buffer, and count the number of occurrences of
the log cookie that represents a successful (or failed) row insert, etc. You
haven't automated your whole process, but you've automated part of it, and
that's saved you considerable pain. And it took maybe half a page of Lisp, if
that.

Recently I was confronted with an ancient web service whose only integration
test process was "manually hit the endpoints with Postman, then check to make
sure the records hit the database". So I wrote Emacs Lisp code to send the
requests, run the queries, and even manage the Docker container where the
service lived. This let me run the whole process much faster with a few M-x
commands. It was nothing fancy, either, I just wrote code to spin up curl,
Docker, and SQL*Plus and capture and examine their output, sort of using Emacs
as a powerful full-screen shell. Rather than get in my way, it became a
versatile tool I could apply to the task to get things done much faster.

Again, this is the difference between an extensible editor and a completely
malleable one. VSCode, JetBrains, or Eclipse cannot be extended as
incrementally and on-the-fly as Emacs.

~~~
balloneij
I can understand that. I just like to tinker too much :). Going at it with a
goal in mind would be a good idea

------
korethr
A shame Stallman put the kibosh on QT quickly. Is he planning on there being a
GPLv4? Not in the "leaving that option open for the future" kind of planning,
but more, "A need has been identified that can't be met by v3, it's time to
start working on v4." Because if they truly want a cross platform visual
interface, AFAICT, QT is the closest you're going to get, and IMO, is the best
means of doing so. Every QT app I've seen has looked and acted a lot closer to
a native app on Windows and Mac than anything that ever came out of GTK or
other GUI toolkits. And I don't understand why GTK doesn't have the same
issues. It's not a GNU project AFAIK. It can't be a GPL vs LGPL thing, because
QT is also available under LGPL. Is Stallman perhaps just stuck on the fact
that QT was once not available under a free license?

~~~
josteink
> And I don't understand why GTK doesn't have the same issues. It's not a GNU
> project AFAIK.

Iirc GTK was born out Gnome, and Gnome was born as a FSF-project.

~~~
korethr
Okay, but even if GTK is a GNU project or a FSF project, why does that mean it
qualifies for being part of a future GPLv4 licensed EMACS, and QT does not?
Both are available under the LGPL. I wonder if Stallman expects that a GPLv4
would likely or definitely be incompatible with LGPL3. I don't think it's
because the LGPL version would be bumped if a v4 came out; GTK is still on
LGPLv2.1

~~~
orangeshark
It is because of the license. GTK's license is LGPLv2.1 or later[0]. The
important part is later, It means you can update it automatically to any later
version, especially if the new license is not compatible with the previous
version. Qt does not offer their software with a similar license.

[0]:
[https://gitlab.gnome.org/GNOME/gtk/-/tree/master#licensing-t...](https://gitlab.gnome.org/GNOME/gtk/-/tree/master#licensing-
terms)

------
dfabulich
Emacs might never catch up to Visual Studio Code, which is actively funded by
Microsoft, but intuitively, it seems like Emacs ought to be able to catch up
to Vim. It's always been weird writing Emacs extensions in ELisp, but it's not
like Vimscript is a top-tier language. Emacs is hard to learn, but so's Vim.

I think it comes down to performance, especially startup time. Emacs
developers have never cared much about it, and I think that's connected to its
reputation for "bloat."

The death knell rang when Linux distros stopped distributing Emacs by default;
Emacs isn't installed by default on Ubuntu or Fedora, say nothing of macOS or
the Windows Subsystem for Linux.

If I were working on Emacs, my #1 goal would be to beat Vim on startup time--
to get the first page of text to show up faster than Vim--and my #2 goal would
be to convince the major distros to include Emacs by default.

Sadly, I don't think any of this will happen. Stallman is too far out of
touch, not just with newbies, but even with active users of Emacs. As the
article points out, he's never even used Org mode! [https://lwn.net/ml/emacs-
devel/E1jR5ss-0001xM-L9@fencepost.g...](https://lwn.net/ml/emacs-
devel/E1jR5ss-0001xM-L9@fencepost.gnu.org/)

EDIT: I know you can do some non-default techniques to make Emacs start
faster. But that won't get Emacs to be installed by default on popular
distros. Installing more plugins won't make Emacs the quickest and easiest way
to edit a file.

~~~
raverbashing
Vim might be hard, but besides jokes about "how to quit it", it makes much
more sense than Emacs.

Emacs key combinations are weird. Discoverability is low. Even Vim will now
tell you how to quit if you Ctrl-C it.

Meanwhile I have opened Emacs and I'm trying to quit it (spoiler: Ctrl-x
Ctrl-c). Some things are actually interesting and it tries to help at first
but then it goes back quickly into emacs-babble that doesn't help much.

The case for vim is simple: a quick editing of a file when you might not have
a window manager up or on a terminal.

I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.

~~~
fhennig
> Vim might be hard, but [...] it makes much more sense than Emacs.

Counter-point: I think emacs makes much more sense. If you start it, you can
navigate a file by clicking in places. It is a GUI application, whereas I
think vim is just a terminal program by default?

Emacs has a little built in tutorial (Ctrl+h t) and is quite discoverable
(type Ctrl+h ? and it shows you a lot of commands you can use to find out
about what functions a chord invokes or how to invoke a function with a key
cord). With helm you just type a part of a function and it gives you a list of
suggestions.

Within programming languages I think auto-completion is a _must-have_ for
discoverability. Otherwise I have to constantly look up stuff in the
documentation. And for that company-mode is really nice, I don't know about
the vim side of it but I think something like that goes against the philosophy
of vim as I understand it?

To me, modal editing didn't make much sense in the beginning and for emacs the
learning curve seemed less steep, so that's what I went with in the end. But
clearly it must be good somehow, because so many people use and love vim! It's
just not for me I guess.

~~~
raverbashing
Yes, in the XEmacs case it is the case, not necessarily when you're using it
like VIM

(There are gui versions of VIM as well but it feels weird)

------
sinkasapa
It seems that if vim is so much more popular than emacs, old fashionedness
doesn't necessarily make an editor less popular.

If one believes that emacs would be more popular if it were more like some
other editor that is more popular then being more like vim would make emacs
more popular. Evil has existed for a long time but vim is still more popular.
As much as emacs can be like vim, people still feel vim is better at being
vim.

If emacs was more like VS code, would people want to use it for that reason?
It seems like VS Code would always be better at being like VS Code than emacs.

Emacs has a loyal following, conceivably of millions of users? It also
attracts new users who like things about it. There are packages for most
languages, even very obscure ones. Being less popular than vim doesn't seem to
make emacs less useful or keep new people from picking it up. It seems like
emacs is a good thing according to many people as is and if its developers
want to make users happy, looking at what people use emacs for and making it
do that better would probably be a good idea. Making it more like other things
that already exist doesn't make as much sense to me really.

I guess I don't really understand why it is important to be most popular as
long as something is useful with a strong user and developer base.

~~~
alpaca128
Agreed. Emacs and Vim basically try to do the same thing with two very
different approaches, and both can fit well depending on the use-case. I also
get why many prefer VS Code, because spending hours to learn and configure a
program just for text editing is not universally appealing. But other people
just want that configurability.

> Evil has existed for a long time but vim is still more popular.

Because the behaviour isn't identical(it even has default settings that
intentionally deviate!), because it isn't complete(it doesn't affect any other
mode), but most importantly for me because Emacs cannot fully match Vim's
keybinding functionality. I broke my Emacs configuration a dozen times before
realising that.

I am glad I tried out Emacs as a Vim user though, it led to a couple
improvements of my Vim configuration and I learned a couple new things.

------
arexxbifs
I'm not an Emacs user, but with all kinds of software like this, I find that
the strengths lie not in what makes it popular but what makes it lasting. If
too much is changed in Emacs, scores of users will cry havoc and switch to
XEmacs (or something) and it will become even less popular.

Emacs has a stable core user base and as far as I can tell, it's recently
getting some traction among a new generation who are exactly the kind of users
that would likely jump ship as soon as a lot of "modernization" started
happening. If they wanted something "modern", they wouldn't opt for Emacs in
the first place. It's not like there's a lack of choice: IDE:s and editors
adhering to current trends and concepts within UI/UX design are plentiful.
They have sought out Emacs because it is uniquely Emacs and not yet another
Sublime/VS Code/Atom.

Editors aren't exactly comparable to desktop environments, but when Gnome 3
was conceived for similar reasons of following design trends and thinking
afresh, we suddenly also had Cinnamon, MATE and Budgie instead of just KDE and
Gnome. Not that I mind diversity, but it's a fine example of alienating a user
base. Now, consider how conservative an Emacs user of today probably is.

I find that one of the few things I still truly enjoy about computers is that
there is stubborn software left for stubborn people to use. Slackware, Emacs,
fvwm, xterm... Familiarity, not innovation. That's worth something, too.

~~~
brlewis
> it's recently getting some traction among a new generation

Where can I learn more about this? If I teach my kids emacs will they not be
the only ones among their peers who use it?

~~~
arexxbifs
As someone else pointed out elsewhere in this thread, check out /r/unixporn.
Kids today with their tiling wm:s and esoteric editors, eh?

------
alexchantavy
Outside of the text editor, I think native emacs keybindings like (C-n, C-p,
C-a, C-e, C-k) on OSX are great and I hope they never get rid of them.

~~~
antipaul
Please never get rid of this

As a user of these key binding in both Emacs and macOS, it’d be worse than
cutting off an arm if this went away

~~~
throwaway_pdp09
Or next-paragraph/last-paragraph movement.

Or all movement combined with prefixes. I regularly do

    
    
      C-u C-u C-p
    

to jump sixteen lines backwards. Or add another prefix and it's 64 lines.

Separately, macros, yea! Macros with regexes FTW! The counter you can use in
macros - occasionally very useful! M-x occur! Dired which can search a whole
directory tree of file contents for a regexp! So much more.

Only thing worse than emacs interface is not having emacs at all.

------
ch1lang0
Emacs is not an editor, is a personal travel to find and build your ultimate
editor through the years, a solution that will work forever but only for you.

Yes, is the most powerful tool that ever existed, a beautiful monstrosity, no
other editor will let you cherry-picking git commits, handle your agenda,
export to PDF, measure the time for a cup of tea and estimate the new project
costs. In some point Emacs becomes a part of yourself. Yes it will be loved
and tamed only for us, the weirdos, and that is ok.

In 1996 all my friends were asking me why I installed and struggled so many
hours with that thing called Linux, when Windows was so easy. "Nobody uses
Linux", they told me. Well, Linux made me very good with DevOps tasks, and I
finally learned what software is about when I discovered eLisp.

As many other things in this world, Emacs is not for all people.

~~~
bagol
Out of curiosity, what is software about to you and how does elisp teach you?

------
mike_ivanov
Please. Emacs will never be popular. Emacs does not need to be popular. Making
it popular will require dumbing it down to the level of VS Code. It's doing
just fine as it is, please leave it alone.

Edit: I mean, it's a complex, sophisticated, hard-to-master instrument, kind
of like Organ. If you feel that popularity of your instrument matters above
all (which is perfectly fine) -- just get yourself a Kazoo.

------
taeric
Oddly, I think you will make Emacs appealing to users when you start asserting
it is appealing to users. Few changes really needed. Just stop intimidating
people before they get involved.

~~~
microcolonel
My experience with Emacs has been a steady upward trajectory, gaining
understanding and access to functionality. I now use CIDER and TRAMP every
working day, and no true equivalent exists for any other editor (though many
are catching up to CIDER, due to Clojure being the better lisp!).

The biggest problems with Emacs, to me, are the rendering performance, the
lack of sufficient threading, the default keyboard-accessible windowing
commands, and Elisp being unergonomic and sad.

The course I'd chart for an ideal Emacs would be rendering with something like
Alacritty†, some default windowing commands similar to tmux, and phasing out
Elisp in favour of a Clojure dialect; the last bit would help a lot with
introducing some basic sources of concurrency.

† Plus smooth scrolling surfaces, since a text editor generally does not have
enough surfaces that the memory overhead of tiled surfaces is a serious issue
like it is for general-purpose renderers like web browsers.

~~~
celeritascelery
As someone who claims to be using "the better lisp" what is it about elisp
that you find "unergonimic and sad"? Genuinely curious.

~~~
microcolonel
At least when I've written elisp, the default datastructures have involved a
lot of work to construct and manipulate, and when you do it right, the ones
you've chosen for convenience may perform so poorly that you have to go back
and change them to get your program to complete in time.

Namespaces for vars and functions being not a language feature is
inconvenient. Unless you are using fakespace or intern-symbol (it seems hardly
anyone does), every symbol in your program needs to include its namespace
information in order to avoid it being accidentally invoked by somebody else,
or accidentally convincing somebody that it's part of the base distribution.

In Clojure, it's many little things:

Keywords are callable, allowing you to evaluate a keyword on an associative
collection like hash-map, or traverse, in an obvious and intuitive way, into a
nested associative structure with the threading macros "->" and "->>".

The default data structures are fast (for what they are) and hard to misuse:
unless you ask politely, you are not going to mutate something your function
was passed passed without noticing. seq, the interface for sequences (vectors,
lists, pairs from an associative structure), pairs well with destructuring in
let and macros/syntax that does binding.

Things like 'let' don't use more parentheses than necessary, which has a
greater impact on readability than you'd think. The use of vector syntax for
bindings rather than list syntax adds a little bit of syntactic texture that
makes reading programs more ergonomic.

I think Clojure may not be as unfamiliar as it seems at first to a person
who's written other lisps before, but I have yet to meet somebody who prefers
the experience of writing Scheme or Common Lisp to Clojure; nor anyone who
prefers Elisp to Common Lisp.

~~~
celeritascelery
You should check dash[1]. It adds a lot of those "many little things" from
Clojure (such as ->, and ->>, and let) to elisp.

[1][https://github.com/magnars/dash.el](https://github.com/magnars/dash.el)

------
simias
I wish Vim users and Emacs users would unite to improve Spacemacs. It's really
a great idea IMO, have the editing power of Vim with the flexibility and
elegance of the Emacs environment.

Unfortunately when I tried Spacemacs (coming from Emacs) I kept bumping on
rough edges with vim command emulation which ended up with me switching
directly to the real vim. It's been about a year now and while I still think I
was right to finally make the switch to modal editing, vim feels like a clunky
and hacky environment compared to the power of Emacs.

~~~
chongli
Vim and Emacs have too many philosophical differences for this to work. For
example, emacs doesn't have a fixed concept of what a paragraph should be.
Instead, it leaves that up to the major mode. This is fundamentally
incompatible with vim's paragraph motions which are determined by empty lines
and remain the same regardless of file type.

As a very long-time Vim user, I prefer that my editing commands be predictable
since I type them with muscle memory (faster than ordinary conscious thought).
Having them vary from file to file based on file type (the Emacs way) throws
me off completely and makes the editor feel untrustworthy, like a horse that's
liable to kick or throw its rider. Vim feels like a complete set of high
quality, manual woodworking tools.

~~~
simias
Interesting viewpoint, but aren't there enough differences between programing
languages to warrant mapping these concepts slightly?

Clearly my Emacs origins show here, because not having simple built-in motions
to select "a function" or "a class" feels like a big limitation to me. I
actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph
motion while coding simply because it doesn't really make a lot of sense to
me. I think about code in lines or blocks, not paragraphs that is a rather
weird concept when it comes to code. The fact that you can't easily add new
motions to vim is a big limitation for me.

>Vim feels like a complete set of high quality, manual woodworking tools.

They're mostly reliable and predictable, I agree with that. High quality I'm
not sure. The fact that the undo tree is effectively unusable without 3rd
party plugin is weird. Tabs are at the same time over-engineered and under-
featured. Nobody seems to really knows what they're for or how to use them
(just make a quick search online for "vim tabs").

They're like Emacs frames except that you can't actually use them like a
separate frame on a different screen. And you can't have them use a different
working directories easily so they're useless to open two projects side-by-
side. Some people coming from editors that open files in individual tab (an
anti-pattern IMO, but that's a different discussion) expect them to work that
way, but it turns out that they can't really do that either. Why even bother?

You also need plugins to do very basic coding stuff like run "make" in the
background without being locked out of editing. Which wouldn't be too bad if
Vim's internal API made it easy to make Vim plugins work seamlessly like
native code, but in practice all the plugins have tested needed to be super
intrusive to offer basic functionality (like remapping literally half the
keyboard to slightly tweak the kill/yank behavior) and it ends up breaking
left and right in weird and unexpected ways.

The visual feedback for commands is atrocious. Spacemacs' genius is that when
you start typing commands it shows you what you can press next and what it
does. You effectively navigate the bindings like menus, and you have this
positive feedback loop where you memorize the bindings by using them.
Sometimes I start typing a command in vim and I think I made a typo but I
can't know because I have zero feedback on the current state of vim. Emacs
almost always tells you what it's waiting for in the mode-line.

Why does ":bdelete" also kill the window it's in, except when there's only one
window left? Since elsewhere there's no 1:1 relation between windows and
buffers, you'd expect to get the next buffer in the stack (that's what Emacs
does in this situation, and that's what Vim does when you have one window
left). Window and buffer handling is hard but Emacs is vastly more
configurable and works better out of the box in my experience.

I also often get performance issues that I don't remember ever getting in
Emacs which is fairly ironic given that Vim is supposed to be the "lean" one.

~~~
chongli
_Clearly my Emacs origins show here_

I think so. The Emacs philosophy is essentially to treat the editor like a
highly-customizable IDE. I use Vim only because I want a Vi that has a few
quality-of-life tweaks here and there (the undo tree works fine for me without
any plugins, I just use g- and g+). I don't use the vast majority of what was
added. The core of what I want was created by Bill Joy back in the 70s.

I want a text editor that works the same whether I'm editing a C source code
file or a text file that happens to have some C pasted into it or a
configuration file or a file that looks superficially like C but happens to be
a different language. I'm not interested in an IDE. I would prefer that most
of those language-specific tools be separate programs that I can invoke by
shelling out.

Performance issues in Vim are usually caused by various autocompletion
engines, none of which I use. I like Vim's built-in completion which is very
simple and predictable (fitting the theme), invoked using C-x in insert mode.

------
geniium
Am surprised that a starting point has not been highlighted earlier: the
onboarding. To get news users using your product, you have to lower the
friction. By making great docs and the environment easy to setup to get
started, you can make this process easier.

Why not start with that?

I have always felt that the initial config of emacs has been painful.

------
dig1
I see this "Emacs is terrible, my (insert currently hyped IDE/editor) is much
better" mantra every few years. These days, it is VSCode, few years ago it was
atom/pycharm/intellij, before that was anything on Eclipse platform... Yet, I
need to see status of any these after 40 years.

Emacs is like a turtle - it isn't flashy and trendy, looks weird and old, but
is still going steadily and strongly. And I bet you'll be able to run your
configuration 10 years ago, for the next 20 years without any problems.

I'd say, if you don't like Emacs, use something else. Usually everyone returns
back to either Emacs, Vi(m) or Sam at some point. True hackers will go to ed -
ed is the standard text editor after all :)

------
kick
I think a large part of the issue is the default keybindings (the GUI is also
bad, but I think it's bad in a way that's not going to be impossible to fix
without screaming from people who like what's already there). It's truly only
lacking a decent text editor.

This isn't to say that the keybindings never made sense; in the stage of
computing before X, where Space Cadet-like keyboards were common, it was more
than fine.

Currently, though? Entirely different era of computing.

Imagine you're walking in with no clue. You haven't heard of any of the memes,
someone just recommended you a text editor. "It's really good! You'll be more
productive!" You have no idea what in the world evil is, or why you would ever
want it.

You launch the tutorial/tour/whatever it's called and immediately it yells at
you to use C-v to jump to the next page. And then M-v to go backwards! If
you're a normal user, your response is probably something along the lines of,
"Like, why?"

Off to a good start, breaking the most universal keybinding across modern
operating systems in the strangest way possible, and not only that, but also
breaking one of the biggest implicit rules of keybindings.

You read a little bit more and eventually get to cursor control. Wow, somehow
they managed to pick the only possible thing less intuitive than 'hjkl'! Not
only that, but it's not even _consistently_ unintuitive!

And that's not even getting into the obvious problems that come with the
placement of M and C on modern keyboards.

There are a few solutions to this, obviously, but good luck trying to find a
solution that isn't universally-hated.

You could make evil the default. Controversial and only slightly helps the
barrier to entry.

You could make it like the Web's model of text-editing but with quality-of-
life enhancements. I think this one is probably the winner. It's definitely
why Sublime/VSC/Atom won, past everything else.

The Turbo C/Wordstar approach was cool, but has no mind-share today.

You could try something new, I guess? This is dangerous territory, though.

I have no idea what the solution is, but the problem(s) seem obvious. I say
this all as a person who really _likes_ Emacs. I even still have most commands
memorized despite not having touched it for years now!

~~~
dmortin
> You launch the tutorial/tour/whatever it's called and immediately it yells
> at you to use C-v to jump to the next page. And then M-v to go backwards! If
> you're a normal user, your response is probably something along the lines
> of, "Like, why?"

The hardcore emacs users think these keys are better. And don't want to change
them, because then they had to rewrite the whole manual which uses these keys.

The user don't have to use these keys, though, so there is no point in the
tutorial starting with them.

~~~
pwinnski
Right? And yet I just typed 'emacs tutorial' into DDG, and the first three
results all hit you right away with descriptions of keys that don't physically
exist on a modern keyboard.

[https://www.gnu.org/software/emacs/tour/](https://www.gnu.org/software/emacs/tour/)

[http://www.jesshamrick.com/2012/09/10/absolute-beginners-
gui...](http://www.jesshamrick.com/2012/09/10/absolute-beginners-guide-to-
emacs/)

[https://www2.lib.uchicago.edu/keith/tcl-course/emacs-
tutoria...](https://www2.lib.uchicago.edu/keith/tcl-course/emacs-
tutorial.html)

I've never tried emacs in large part because I've been convinced over the
years that the various combinations of keys I would need to memorize are too
complicated. I just did that search thinking that maybe I'd been mis-
remembering, but no, that's still the impression that I have.

~~~
1ark
I'm curious, how do you remember key combinations in other IDEs? I learned
Vim, it was tough, but I remember a handful of commands I use all the time.
And used Vim mode when available in IDEs when available. Spent a few years
with VS Code, but I could never remember certain keys to navigate between
panels for example. But the F1 key is great though. For w/e reason, I tried
Emacs with evil-mode. I don't have to remember that many new keys I think, but
a few of course. 'which-key' and M-x enables me to search for _all_ commands,
and I can also see the key combinations if I need to learn it later. In VS
Code I try the F1 key, but if I could not find it there, I would grab the
mouse and click around in menus looking for key combinations. Or go into
settings and try to find w/e I was looking for. Of course, in Emacs I have
spent hours setting things up, searching on the internet for clues on how to
get something working as expected.

Perhaps I am doing something non-optimal in my process. Curious how others
learn/get productive in their respective IDEs.

~~~
pwinnski
In most IDEs, they're the same key combos I use in non-IDE products. I'm on a
Mac, so Cmd-X, Cmd-C, and Cmd-V work pretty much everywhere. They even work at
a terminal prompt, and the latter two work in vi.

I did learn vi years ago, but I'm sure I still don't tap but 10% of its power,
despite using it daily, precisely because the key combinations seem arcane to
me.

------
retonom
Who cares about popularity? It often brings more trouble than anything. Emacs
is a gem and will probably stay like that for decades to come.

The only thing I wonder about is how it is possible that Stallman seems to
have never heard about org-mode which is one of the main reasons I use Emacs
and I don't think there exists anything that even comes close.

I manage my todos with org-mode, generate chord sheets of my songs and even
produce my website from org files.

~~~
gnulinux
I don't think Stallman writes code anymore. It's surprising that he doesn't
use org-mode for other, life organization issues, though.

------
_hardwaregeek
This is a super dumb example, but I hate that scrolling is tied to cursor.
Like if I'm _gasp_ using the mouse to scroll through a file in emacs, the
cursor has to stay in the viewport. If I scroll past the viewport, the cursor
moves to the viewport. In IntelliJ (which has such good emacs keybindings I
can use it for a lot of my work), the opposite is true: when I scroll away
from my cursor, it stays there and when I start typing again, my viewport
moves __to my cursor __not vice versa.

It's a small thing but it shows emacs' age. When emacs was written, GUI
cursors weren't a thing. Scrolling wasn't a thing. Of course the cursor and
the viewport would be connected. There wasn't any other way to move the
viewport. Basically emacs needs to be somewhat GUI native.

Emacs should also be more discoverable. It's hard to incrementally learn key
commands. I hate that the default for M-x is just a blank line. It's really
intimidating. Having some sort of fuzzy search/history like Helm makes M-x so
much easier to use.

Basically emacs needs to get UI and UX people to give it a refresh. Nothing
outlandish, just get it into the 21st century.

~~~
viklove
It's because scrolling doesn't actually make sense in emacs or vim, if you've
put some time into learning how to use them.

In vim, for example, you would be much better off navigating with the keyboard
than the mouse. You can leave bookmarks all over the file and jump between
them with 2 keystrokes. There are also a multitude of navigation controls ({,
}, gg, G, etc.) that save you the time of moving your hand in between your
mouse and keyboard.

If you want to use your mouse, maybe vim/emacs aren't for you -- sublime or vs
code will probably serve you better.

~~~
snazz
I'm genuinely curious: do you not read through code from top to bottom? That's
a very common thing that I do, and using the mouse is a comfortable way of
accomplishing it.

~~~
kgwgk
If you want to go to the next page (screen) of code, isn’t the keyboard just
as comfortable? If you want to go down until you find the thing you’re looking
for, wouldn’t a search using the keyboard be potentially more comfortable?

~~~
snazz
I like how I can control the rate at which I scroll with the mouse more easily
than with the keyboard. It's a more intuitive movement that I can adjust to
match the speed of my reading.

~~~
kgwgk
The point is that reading code from top to bottom is not a reason to need or
prefer a mouse. Other people prefer using a keyboard and find moving through
pages more intuitive than scrolling.

~~~
macintux
Different people have different preferences, so clearly it is a reason to
prefer a mouse.

I don’t use my mouse with Emacs, but I’m not going to tell someone else
they’re wrong for wanting to. I’m beginning to see why people feel the Emacs
community is less-than-welcoming.

~~~
kgwgk
Of course different people have different preferences. I don’t tell anybody
that the way they prefer is wrong! I don’t say there is a reason to prefer the
keyboard either. But being what it is doesn’t make Emacs broken. You can
definitely read code from top to bottom on it.

------
jes
I've been fortunate to be able to use Emacs for the last 35 years or so. If
memory serves (and more and more, it doesn't) I started with Gosmacs and moved
to GNU Emacs sometime around 1986 or so.

At 60 years old, I don't have the enthusiasm or the time to learn a new
editor. And I'm having too much fun programming in Lisp.

------
madballster
I love emacs because it's fully programmable. This flexibility comes at a cost
though, i.e. the time invested making the environment mine; exactly how I want
it to be. It's like a sandbox for text based work on a computer.

Not everyone is willing to invest this time and therefore IMO it won't be a
very popular environment for most users. I don't blame them, everyone's needs
and priorities in life are different.

~~~
soedirgo
It's the ultimate yak shaver ;-)

Or you could start with a popular .emacs.d (I use Doom Emacs), tweak a few
things, and tell yourself "I don't need to modify yet another key binding" a
hundred times.

------
Ataraxic
Popularity is more of a marketing problem than an editor problem.

At the same time, if we compare emacs to vscode, vscode simply requires less
configuration to get going. Given how much tooling exists in the javascript
ecosystem, I think having a few plugins "just work" goes a long way.

Asking users to configure emacs from scratch to have a reasonable editing
experience in their programming language of their choice is a lot. I think
configurations like doom or spacemacs do a lot for this problem, but it really
comes down to marketing.

~~~
dmortin
> if we compare emacs to vscode, vscode simply requires less configuration to
> get going

True, but then why do more people uses Vim than Emacs? Is it becase it's
installed on servers and stuff?

I wonder what percent of desktop programmers use vim or emacs who don't need
to do devops.

~~~
celeritascelery
Where I work nearly everyone uses Vim. We work in less popular languages that
new kids on the block (VSC, Atom) don't really support. It really either Vim
or Emacs. I think most people choose Vim because it is the default "Terminal
based Editor" in most peoples minds.

------
agigao
Well, spacemacs is an awesome intro for new users, which makes it cool, useful
and quickly configurable.

Tried to use Emacs for data analysis in Python, because I write lots of docs
in org and client project status/tasks report page is also generated from my
org file. But the problem is proper support of repl in python. We got number
of packages but none really solves my problem to have a proper analytics
workflow.

P.S. I also write Clojure and Emacs it surely the go-to environment! Actually,
I got into Emacs due to Clojure back in 2014.

\- Spacemacs for all the bells and whistles

\- Emacs Prelude for simple base

\- Doom Emacs is another beast, though.

P.S. What might make it much more accessible I think is builtin project
structure view such as Treemacs. Also, let's not forget that Most of the world
do use Windows and Emacs has a poor support for this platform.

\- The problem with VSCode, Atom and alikes are just absolutely inconsistent
keybindings, half-baked packages and honestly I don't really want to write
code in a browser. It's like a flashy smartphone - does everything but few
things well. Hence my favourite tools for coding are produced by JetBrains -
PyCharm and IntelliJ. These tools do also have their keyboard inconsistency
issues, but it is what it is.

Happy Hacking!

------
arm
For me, I’ve recently started using Emacs solely due to wanting to try out
rust-analyzer¹ (not touching Visual Studio Code since it uses Electron), and
I’m really enjoying how insanely customizable Emacs is! The ecosystem around
Emacs looks great too, with quite a few packages I´m interested in trying
(like Magit²).

――――――

¹ — [https://rust-analyzer.github.io/blog/2020/04/20/first-
releas...](https://rust-analyzer.github.io/blog/2020/04/20/first-release.html)

² — [https://magit.vc/](https://magit.vc/)

~~~
giggles_giggles
I cannot possibly encourage you more to check out magit. It is unbelievably
good. I always share this demo with people to show off just a tiny portion of
what it's capable of doing

[https://www.youtube.com/watch?v=rzQEIRRJ2T0](https://www.youtube.com/watch?v=rzQEIRRJ2T0)

My skills with git have gotten better after using magit, too, because it
brings the power of git to the surface. It's a really fantastic git porcelain
and the fact that it is deeply integrated into Emacs just makes it absolutely
second to none.

Magit is easily one of my favorite pieces of software and I will leap at the
chance to sing its praises.

------
paule89
I think licensing is not the problem, why nobody installs emacs anymore. It is
initial setup. Where can I get a good code highlighter for all my code.
Integration into obscure ide's compilers like iar. A workflow showing me
easily what I changed, which files to check into git. A nice git overview of
file history thanks to extensions. where can I get all this easily. One click
and have a dark theme. Also easily customizable shortcuts. Manpower behind the
editor for many changes and improvements. I mean who pumps out new versions
every month.

I would say vs code does all that and while using an easy to overcome entry
bar. And I am much more productive even than in native ide's for embedded
development. Like iar eclipse or Segger.

The only thing I would want to try is using the org mode in emacs for nice
todo handling. But else I see no appeal in emacs. It is just ugly, more
concerned about it's license instead of just saying, this is free software
just contribute and we will improve by using everything we can.

------
dnquark
I was about to jump ship to VSCode, but lsp-mode (despite minor hiccups) has
extended my Emacs' expiration date.

So if I almost gave up, after having lived in Emacs for the last 12 years, can
we really expect much popularity with those that are new to computing?

In 2020, Emacs is mostly just for people that love to build or customize their
tools, or for folks that want a better Vim (i.e. Doom Emacs). And to customize
Emacs you have to have a basic understanding of modes, hooks, keymaps, etc --
as well as at least rudimentary knowledge of elisp. Getting good at that stuff
is a multi-year-long process. Emacs will never be "popular" for the same
reason that if you want to have a fun night with friends, (statistically)
chances are you'll choose to play Rock Band as opposed to learning real
instruments. But as is the case with many niche and challenging things, it's
hella fun and rewarding once you've spent a few years doing it.

------
mafm
If rms doesn't understand org-mode, that seems to be pretty indicative of what
the real problems underlying emacs' lack of popularity are.

I suspect that org-mode is responsible for more people using emacs than any
other package by a large margin. Not understanding org mode suggests to me
that rms is no longer on the same page as most of the users.

I know there's a lot of other good stuff in emacs, but org-mode seems to be
particularly key.

------
dan-robertson
I feel like I’ve noticed an increase in the popularity of emacs online in the
last 10 years or so. Or perhaps just a waning of vim zealotry. I’m pretty sure
I used to see quite vim-related posts on hn but I don’t really see them
anymore, whereas I do see emacs/elisp related posts from time to time (with
particularly strong mentions for org-mode or magit), and I don’t have much
memory of them.

Perhaps vim is so widely used now that no one bothers to vote up articles
about it. I find the shift particularly strange because it comes with a shift
of the site away from lots of articles about languages like lisp for which
emacs is basically the only sane choice of editor.

Perhaps the real reason is just that I’ve noticed emacs more because I’ve used
it more.

------
superbaconman
Honestly the hardest part about emacs for me has always been documentation.
Like how do I build a plugin. What function do I call to set a custom key
binding? This stuff has always been so hard to find despite it being so
important to the underlying experience. Now that I've used it for a while I
know these things, but they didn't come easily.

~~~
dmortin
These days you can just google to get answers quickly, just like for any other
tool. Stackoverflow, etc. has tons of content for emacs too.

~~~
_peeley
It's ridiculous that end users should rely on third parties for reliable
documentation. For any other tool, if you wanted to know this kind of builtin
functionality it'd be readily accessible in --help, the man page, or first-
party online docs. Why should Emacs be an exception?

~~~
tome
What tool do you go to the official docs for first and only Google second? I
Google everything first. Am I missing out?

~~~
dllthomas
A trivial answer is "internal tools"...

A more interesting answer is bash - I will often check the man page before I
Google.

------
DonHopkins
From: rms@AI.MIT.EDU

In general, the way for a problem to be fixed is for someone who knows how to
fix it right simply to do so. Any solution that involves discussion should be
avoided except as a last resort, because it is inefficient.

~~~
tome
Is this a real email? Do you have a reference? Google didn't turn anything up.

~~~
DonHopkins
Dale Worley posted it to a mailing list in '89, and I asked him where it came
from:

    
    
        Date: Mon, 18 Sep 89 21:55:13 EDT
        From: drw@BOURBAKI.MIT.EDU
        To: don@brillig.umd.edu
        Subject: An interesting bit of philosophy from RMS
    
           From: Don Hopkins <don@brillig.umd.edu>
    
             From: rms@AI.MIT.EDU
    
             In general, the way for a problem to be fixed is for someone
             who knows how to fix it right simply to do so.  Any solution
             that involves discussion should be avoided except as a last
             resort, because it is inefficient.
    
           Interesting all right! When/where and in what context did he say
           this?
    
        It was on one of the Emacs newsgroups, where lots of reasonably
        uninformed discussion had broken out on how to resolve the fact that
        VM and Gnus (I think) interfered with each other, because they both
        used the overlay-arrow mechanism.
    
        Dale
    

Searching Google Groups for the first sentence found the unexpurgated version:

[https://groups.google.com/forum/#!search/%22In$20general$2C$...](https://groups.google.com/forum/#!search/%22In$20general$2C$20the$20way$20for$20a$20problem$20to$20be$20fixed$20is$20for$20someone%22/gnu.emacs/p4sUVns_APg/945MYv3CBrMJ)

    
    
        Date: 9/11/89
        From: rms@ai.mit.edu 
        Newsgroup: gnu.emacs
        Subject: No more on overlay-arrow-position
    
        I don't think most Emacs users want to participate in a discussion
        about how to solve a fairly obscure problem in how Emacs is implemented.
        This kind of discussion doesn't help me solve the problem.  I know you
        mean well, but you aren't experts.  Most of this discussion consists
        of proposals that are completely wrong, or won't work, followed by
        refutations and counterproposals.  When I decide to fix this for
        version 19, I won't read the discussion; I'll just fix it--it will
        take less time.
    
        In general, the way for a problem to be fixed is for someone who knows
        how to fix it right simply to do so.  Any solution that involves
        discussion should be avoided except as a last resort, because it is
        inefficient.
    
        Remember, the purpose of info-gnu-emacs (and its repeater newsgroup,
        gnu.emacs) is to carry the information that *every Emacs user will
        want to know*.  There's nothing wrong with non-experts discussing how
        Emacs bugs might be fixed, but please don't do it here.
    

RMS also doesn't like people posting baby announcements to mailing lists that
are clearly intended for making dinner arrangements (and the baby in question
is 27 years old now):

[http://www.art.net/studios/hackers/hopkins/Don/text/rms-
vs-d...](http://www.art.net/studios/hackers/hopkins/Don/text/rms-vs-
doctor.html)

I love Lile's response, who has the grace and composure of dang:

>Please send your "fucks" via personal mail and refrain from using Kabuki-west
for such messages. -Lile Elam

~~~
tome
Very interesting. Thanks!

------
ngneer
I use Emacs and love it, but the problem as a newcomer is that basic questions
never have basic answers. The answer is either in the form of a complex
incantation, or requires one to come to grips with new abstractions.

------
sys_64738
Emacs is eternal. It was here before most other editors and will outlive the
majority.

~~~
stupidthrottle
> It was here before most other editors and will outlive the majority.

While your first statement is true, taking the second one for granted is
dangerous and may lead to the exact opposite.

Every long-term FOSS project needs to continuously ensure it maintains a
healthy level of contributors, or it _will_ die.

------
snazz
I think that the Emacs _concept_ is really good, but it clearly has a lot of
problems that make it altogether unattractive to new potential users.

\- The keybindings are not the standard CUA ones. Even with Cua Mode, every
page on the internet still suggests using the regular old Emacs keybindings.
There's weird conflicts between some packages, especially if you use non-
default keybinds like Evil. The defaults are not even ergonomic (Emacs pinkie
is a thing...) or mnemonic, so there's really nothing but historical interest
that makes them the way they are.

\- There's no namespacing between packages. They can run right over each other
and cause weird bugs. This isn't theoretical; it's what happens when you have
a bunch of packages installed. Sorting out performance issues caused by the
interactions between packages is very challenging.

\- Lots of other defaults are super user-hostile. To get anything approaching
the productivity of an editor like Sublime or VS Code, you have to spend hours
installing packages, learning their unique keybindings, and sorting out
conflicts.

\- The base is minimal in a way (it's missing a ton of what is needed to be
considered useful today) and also very bloated (it has things like mail
readers and web browsers and IRC clients included). The set of default
utilities needs to better match what people actually use a text editor for.

At the same time, it does do plenty of things right:

\- From anywhere in the editor, you can run code---you don't need to make a
new package to be able to execute a snippet of Elisp.

\- Unicode works OOTB, which is impressive for a project of that age.

\- Some of the "killer apps" like Magit and Org-mode are really good and have
spawned their own ecosystems.

\- Emacs is oftentimes the first editor to get support for super-obscure
programming languages through a package.

A lot of what makes Emacs so cool and so difficult comes from the fact that it
doesn't have an "extension API"\---packages just run the same kind of Elisp
that the editor itself is (mostly) written in.

Edit: I should also add that Elisp is an absolutely _terrible_ programming
language when compared to more modern alternatives.

~~~
dmortin
> To get anything approaching the productivity of an editor like Sublime or VS
> Code, you have to spend hours installing packages, learning their unique
> keybindings, and sorting out conflicts.

Isn't it the same with VIM or other free editors?

~~~
stupidthrottle
To be fair these days you come far by just installing ’lsp-mode’.

------
nullc
I like emacs' aesthetics. It looks like something developers would use in a
movie, especially with the colors set dark and the scrollbar on the left where
all scrollbars ought to be.

I agree that aesthetics have importance, but they should complement what emacs
is and how its used, not make it pretend to be something else. Emacs is a
powerful tool, that isn't going to change-- so it should look like one.

There are already many editors with a "sleek look"! So users that want that
are already using one. They won't switch to emacs if emacs adopts a sleek
look, especially because emacs' internals won't match the drapery.

Emacs epitomizes the Hole Hawg in Stephenson's excellent "In The Beginning Was
The Command Line" ([https://steve-
parker.org/articles/others/stephenson/holehawg...](https://steve-
parker.org/articles/others/stephenson/holehawg.shtml)). It should lean into
that. The users it loses from being overly industrial are ones mostly wouldn't
stay, but the ones it gathers will stay because there are few alternatives.
There is always a role in the world for serious tools.

------
thayne
> Terminal-based Vim is not like a modern application, yet is more popular
> than Emacs.

As someone who has started out with vim, spent a couple years using emacs
(with evil-mode) and ended up with vim (more accurately neovim) again, here's
my take on why this is.

First of all, I ssh into a lot of systems that have vi(m) installed, but not
emacs. So, if I am using vi bindings for my main editor, I don't have to
switch to using completely different editor bindings on remote systems. For
other's that are in a similar situation, that's also an incentive to learn vi
over emacs.

Secondly, while vi(m)'s modal editing is difficult to master , once mastered,
it is, IMO, amazing. Emacs otoh just has unfamiliar, and sometimes unergonomic
key bindings. While many editors do have "vim modes", I have ultimately been
unhapy with most of the one's I've tried (evil mode for emacs is ironically
one of the best).

Finally, there is the configuration. Both emacs and vim are extremely
customizable. While VimL is certainly not the greatest language, it is at
least fairly familiar to programmers with experience with ALGOL-family
languages. It's also somewhat straightforward to write plugins for vim in
other languages, such as python and lua. Emacs otoh, uses Emacs Lisp. And
while I admire lisp, it is certainly very unfamiliar to many potential emacs
users, and can often be much more verbose, especially for setting custom key
bindings.

With all that said, there are things I miss about emacs. Probably the biggest
is that several modes let me customize how auto-indentation worked. In vim,
the ability to customize that easily is not very common, and when it does
exist is not well documented.

------
mwfunk
How on earth was RMS unfamiliar with the existence of Org Mode, and how on
earth was RMS unfamiliar with the concept of outliners, and why on earth, when
he finally figured out what Org Mode did, was his immediate response to be
super dismissive because it wasn't something that he's interested in using
personally?

He sounds like some random person spewing random subjective opinions about
things, rather than the original author of GNU Emacs making an honest effort
to provide leadership and guidance that means something (anything) to anyone
other than himself. He sounds helpless and oblivious to everything and
everyone except his own personal proclivities, which is the opposite of
leadership and the opposite of an experienced person providing valuable
guidance to the community. Like he's not even making a token effort to do
those things, and to say he's metaphorically lifting a finger here to provide
leadership and guidance would be very generous.

This is akin to Linus rejecting a driver because he doesn't own the hardware,
or because he doesn't like the colors of logo of the company that makes it. It
really doesn't get more incurious and intellectually/emotionally immature than
that.

This is in 2020, after a couple decades of Emacs being one of the only actual
software projects he involves himself in anymore. To be clear, I've had a
really low opinion of RMS for going on 20 years now (after a few years in
college where I thought he was cool because I didn't know any better and
people seemed to revere him because they thought everyone else revered him).
But reading these mailing list exchanges are still kind of shocking to me.
It's really hard to believe that anyone on the GNU mailing lists pay any
attention to him at all, or values his opinion on anything. For those that do,
surely that's nothing more than a cult of personality, it just seems as plain
as day to me. This is exactly the sort of thing that drives people away from
GNU and the FSF, and it sucks because they could be so much more impactful and
meaningful and helpful and positive and constructive otherwise.

Sometimes I think if more people had simply stopped making excuses for RMS
like 20 years ago, we might currently be living in some sort of GNU utopia
dreamworld where everyone everywhere uses Emacs for everything, and GCC is the
preeminent compiler suite, etc. etc. etc. It's quite a high cost for people to
pay, when the only thing they get in return for keeping this guy around is
helping a damaged narcissist continue to feel good about himself and continue
alienating everyone else, just like he's been doing for decades. He absolutely
got GNU and the FSF off the ground and helped create a large community that
has produced tons of great software, but in the past 25 years it seems like
all of his efforts have been counterproductive to his own goals.

~~~
dmortin
> How on earth was RMS unfamiliar with the existence of Org Mode, and how on
> earth was RMS unfamiliar with the concept of outliners, and why on earth,
> when he finally figured out what Org Mode did, was his immediate response to
> be super dismissive because it wasn't something that he's interested in
> using personally?

He seems out of touch even with modern emacs packages. He doesn't use any of
them, doesn't even know what they do, I guess he uses the same config since
the 90s, doesn't try new packages, he's more interested in preaching the GNU
message.

~~~
stupidthrottle
> He seems out of touch even with modern emacs packages. He doesn't use any of
> them

And he believes the right thing for the core Emacs-developers to do is to
spend their time trying get everyone in MELPA (a modern package repo, with a
modern GUI, based on modern tools and workflows) to instead move their
packages to ELPA, with all the change in tools, modernism’s and workflows that
entails.

He seriously believes this is important because MELPA isn’t GNU, and that’s
all he cares about. It’s not enough to be open-source and free. You must be
GNU, or it doesn’t matter.

He may add things of value still, but I refuse to believe it’s not
overshadowed by all the backwardisms he constantly tries to impose on the core
developers actually doing the dirty work.

------
theramblingfool
It really depends on your needs. For modern development of projects with
bloated file structures, having a hand-holding GUI like VSC that tames the
file structure of the project really is nice.

If you're just occassionally dropping into headless filesystems to do some
text editing, you're not going to invest in learning a new paradigm and you
will likely use whatever default editor is presented to you. That is typically
vim. For those who mindfully choose to set out and learn a new paradigm
because they've decided to invest in a long-term time-saving skill, I doubt
the vim/emacs divide is quite as stark as the numbers mentioned in the
article.

------
arsdragonfly
The most unfixable UI problem for Emacs is that its rendering model works upon
"character cells and cursor positions, not pixels."[1] No amount of effort
would steer Emacs's UI away from an ortholinear matrix of characters. Whenever
you install an LSP plugin on Emacs, you'll realize how badly it hurts
readability and your eyes. [1][https://m.facebook.com/notes/daniel-
colascione/buttery-smoot...](https://m.facebook.com/notes/daniel-
colascione/buttery-smooth-emacs/10155313440066102/)

------
brainsmith
When I started programming on ruby my laptop couldn’t handle IntelliSense and
tests which required too much cpu and ram. So I’ve switched to vim on server
through ssh. Later I’ve switched to emacs as it seemed to me more powerful
than him back then.

After I got MacBook I’ve switched to TextMate utilizing powerful macOS
keyboard shortcuts for text navigation. MacBook was pretty fast to handle
ruby-related tasks.

Later I found myself in IntelliJ idea working on my Scala projects with emacs
keybindings. I intuitively used emacs keybindings everywhere - from terminal
to text fields in browser (without changing defaults!). Pretty comfortable
until...

I started programming in Rust. It’s compiler and lsp servers use very much
cpu, ram, compilation is really slow heating laptop like a frying pan. Here
comes VSCode with vscode-remote which allows to write code on desktop gui
while compiling, executing IntelliSense commands (lsp server to be exact), etc
on a powerful cloud server. As I understand it executes everything remotely
except GUI rendering and interaction. On network interruptions it restores
connection seamlessly, I barely noticed. It was a salvation. VSCode has a
bunch of predefined hotkeys which can be customized to fit my emacs-like
navigation habits but there are always conflicts with some already existing
bindings, also extension tend to add their own defaults. Too messy. Vim/emacs
emulators are incomplete and buggy. This led me to weird trackpad&keybindings
experience for navigating, building, debugging... Remembering how productive I
was in vim/emacs I couldn’t handle this despite perfect state of the art
vscode-remote.

So I decided to give vim/emacs a try, discover how ecosystem changed during
10+ years. After some investigation I’ve landed on neovim and tried to work on
a rented server as I used to in my first programming years. Experience was far
away from VSCode-remote. Due to network lags and ssh overhead I can’t be
productive with all the benefits neovim offers. So I ended up buying a
powerful home server, connecting to it from my MacBook and work in neovim over
ssh. It’s ok but I really miss the “true” remote mode which offers local
almost zero-latency editing with remote everything else. Renting powerful
servers which has access to the whole dev infrastructure. Paying for them
hourly. There are so many discussions about/plugins implementing VSCode and
its extensions features in (neo)vim/emacs but in my opinion the really missing
piece which don’t turn (neo)vim/emacs to VSCode but instead makes them as
powerful as VSCode in cloud-powered code development. Am I the only one who
miss this feature?

~~~
tgbugs
I think what you're looking for is TRAMP [0,1]. After resisting it and
continuing to ssh into remote hosts in a shell, I finally started to switch my
workflows over, and the improvement is substantial. Async remote compiling
might work out of the box in some cases, or it might require some additional
configuration.

0\. [https://www.gnu.org/software/tramp/](https://www.gnu.org/software/tramp/)
1\.
[https://www.emacswiki.org/emacs/TrampMode](https://www.emacswiki.org/emacs/TrampMode)

------
deft
Making it more popular is going to make it worse. Already in this thread
people want javascript shoved into it. Emacs can be improved in many ways, but
if it strives to be popular the opposite will happen.

------
sdegutis
There is a human aspect to software, and when you forget that, and try to
force people to adapt to software instead of adapting software to people, you
come up with software that naturally is difficult and unpleasant for people to
use.

Emacs is built on a philosophy of human nature that deemphasizes the
subjective personal experience in favor of (a limited group of people’s theory
of) the objective ideal experience.

In a short amount of time, VSCode and it’s ecosystem has almost equally
matched what Emacs and its ecosystem took 30+ years to create.

~~~
whateveracct
> In a short amount of time, VSCode and it’s ecosystem has almost equally
> matched what Emacs and its ecosystem took 30+ years to create.

I'm not $o $ure that'$ actually a$ impre$$ive a$ it $ound$ ;)

~~~
sdegutis
I think you're making the point that a majority of VS Code was funded by
Microsoft, and therefore it can't be compared to Emacs which was either mostly
or entirely coded by volunteers?

The vast majority of Emacs's usefulness is its ecosystem. Several Emacs clones
have been made in a very small amount of time, but none have caught on because
they lack the ecosystem and community. So it's only really fair to compare VS
Code's ecosystem with Emacs's ecosystem. And VS Code's ecosystem was created
by unpaid volunteers too.

------
madhadron
I've had Emacs open in my screen while I'm working for twenty mutter mutter
years, and my keybindings have diverged enough where I can't use stock Emacs
without stopping and carefully thinking about what I'm doing.

But that's sunk cost. I discourage young programmers from diving into it, for
a couple of reasons. First, early in their career there are places where they
will get a lot more leverage. Spend some time learning your text editor, sure,
but at the five to ten hour mark that rabbit hole starts yielding swiftly
diminishing returns. And second, everyone talks about shaping it to your
workflow, but, in the end, Emacs is a terrible environment for writing UIs.
Not everything is best interacted with as text in a terminal. In fact, most
data is not. Compare org-mode with the best of breed todo apps like OmniFocus
and Tasks. I use org-mode for my technical diary, and I use OmniFocus for my
tasks. OmniFocus is simply better. GUIs with a mouse are a more efficient way
to navigate most tasks on a computer that aren't programming.

Stallman mentioned preparing text for publishing. I'm probably unusual in that
I have both typeset professionally (back in Quark XPress days) and gone really
deep in to LaTeX (in my physics days). I've written and typeset two books. The
technical text I did in LaTeX. Actually, I wrote the text in a mix of
Scrivener and LyX, and then used Emacs for the final document. For what lies
nicely in LaTeX, that's great. The other one I did in Adobe InDesign, and
doing it in LaTeX in a text editor instead sounds like masochism. If you're
willing to accept what LaTeX gives you, it's fabulous. If not, typesetting
with Emacs and LaTeX is a simply inferior experience to using a proper
typesetting program.

------
Myrmornis
I'be been using Emacs for 17 years mostly for programming-related tasks. My
opinions are:

\- Emacs is an editor for people who think that learning some Lisp sounds fun
if they don't know some already.

\- Emacs should not bother trying to appeal to a more general audience; it's
not an editor for most people when new to programming, and it's an editor for
a very small minority of non-programmers.

\- Emacs should focus on its strengths: it is the most powerful and extensible
editor ever created. As long as it looks after that identity, it will always
be highly respected.

\- The infinite customizability via emacs lisp and the ecosystem of libraries
is the only thing that can make Emacs more attractive than other editors.

\- Emacs should be sleek, minimal, fast, and visually beautiful, by default.

\- The customize interface is ugly and not a priority; it should be expected
that Emacs users will configure things in Emacs Lisp.

\- The clunky default icons and splash screen should be got rid of: present a
blank screen with minimal tooling if a beautiful first impression cannot be
created.

\- Many of the elisp packages that ship with Emacs should be removed from the
core, with users installing them as packages (Org-mode, Gnus, etc), leaving a
more easily maintainable core.

~~~
EsotericAlgo
I agree that a leaner core seems intuitively right. However, the discussion on
emacs-devel has been in the other direction as of late
[https://lists.gnu.org/archive/html/emacs-
devel/2020-04/msg01...](https://lists.gnu.org/archive/html/emacs-
devel/2020-04/msg01421.html).

~~~
Myrmornis
Thanks I skimmed that thread and the one this HN thread is about. There are so
many depressing things. In particular this arrogant and utterly ignorant
condemnation of Pull Request-based workflows infuriates me:

> A lot of people have not been contaminated by the entitlement that comes
> with the "I'm sending a PR, please check it in" generated by the Github
> culture.

I don't think the person who wrote that has even looked at the pull request
review that goes on in high quality emacs packages on GitHub, let alone
participated in it. This sort of thing really makes it clear that some of the
people on emacs-devel are hopelessly out of alignment with the majority of the
people would would willingly contribute to the emacs and emacs lisp package
ecosystem.

There are many good reasons not to included packages in core Emacs. A big one
is that package authors are working in their own free time and don't want or
need to have to prepare an especially bug-free release to coincide with Emacs
release cycles. Also they don't want to support users using the old version
that is in Emacs.

------
azinman2
The Emacs community has held itself back by continuing the line of thought of
resisting anything that fundamentally changes what they already have spent
years learning and know. It's their power tool, and using tools is important
for humans to do their craft. So I understand why they don't want anything to
change.

Meanwhile new generations of people have different tools and aren't held onto
these past ones because they didn't start with it (and they weren't coding in
the 80s). The world of computing generally has moved on with new ideas, new
experiences, and new form factors. So their new tooling has won them over, and
outcompeted a dying generation.

This is a good thing! It's called progress. Unless Emacs is willing to have
fresh blood decide a new direction for it, it will be relegated to history. If
Apple held onto its Apple II vision, we wouldn't have the iPhone today. Either
you are willing to fundamentally change with the times, or you aren't. Emacs
has shown they aren't, and they've had over three decades to do so.
Fortunately others will in their place!

~~~
Koshkin
I can imagine a few ways emacs could be improved, but "a new direction for
it," I can't.

~~~
azinman2
And that's why it'll slowly go extinct.

~~~
Oekeai
Newness contradicts creativity, because the creative process needs to result
in objects that last. In fact, because new designs create a future need for
more new designs, it cannot last by definition!

Think of shops that sell novelty items. Newness at an object level looks like
novelty items. What is the quality of novelty items? How long do novelty items
last?

~~~
azinman2
I don't understand your point. We're not talking about physical things, we're
talking about software. Software is always changing, morphing, adopting, and
growing user bases. It's what's amazing about it compared to hardware. My 2012
MBP runs the latest OS from approximately 8 years later, and with it a whole
new slew of features and additions that both Apple and the rest of the world
have brought it. Why be stuck in the past?

~~~
Koshkin
> _Why be stuck in the past?_

I surely would want to go back to the pre-corona days.

------
mongol
How much can Emacs change while still being Emacs? Is it worthwhile to start
building a new editor on the core Emacs "idea"? Because I think minor changes
will not move the needle. Someone compared it with the birth of Firefox,
scrapping Netscape Mozilla Communicator or whatever it was called. I think
that is what it would take but even that would be uncertain.

~~~
bobochan
I have used emacs for decades so I do not see the need for a big restart, but
your question does remind me of something RMS said years ago. I cannot find
the exact quote, but the essence of it was that any editor that offered the
programmability of emacs was worthy of the name regardless of its keybindings,
etc. In that sense I do not believe there would be any problem with emacs
following the model of Fortran; it can look and behave quite different, but at
its core it has to be open and accessible for the user to extend and adapt.

------
linuxhansl
It's still popular with me :)

In fact instead of being in either the vi or emacs camp, I use both. I also
use Eclipse.

Each of them for the task at hand.

~~~
DonHopkins
Eclipse was designed and named to piss Sun off, and it worked.

~~~
Scarbutt
Fun fact about the Eclipse name, thanks.

------
_bxg1
> You are basically making a commitment to being or becoming a power user. I
> certainly would not have put up with it if I didn't think it was going to
> save me a lot of time as a software developer (and it does, everyday). I
> doubt anyone invests the mental effort to deal with learning emacs nowadays
> unless this is their goal.

> Terminal-based Vim is not like a modern application, yet is more popular
> than Emacs.

I think what happens here is that when someone decides they want to invest the
time to learn an advanced editor, most of that subset of people end up
choosing vi. Emacs is not approachable enough to appeal to people who _don 't_
fall in that group, and vi has more obvious productivity wins for someone who
_does_ enter that group, since its focus is on velocity-of-editing rather than
extensibility, the latter of which is not even that unique any more (see
VSCode/Atom).

------
hvasilev
I've spend 4 years mastering vim and I can definitely say I could have spent
that time better elsewhere. I'm pretty sure Emacs would be the same waste of
my time. These editors have a very steep learning curves and require a lot of
effort to master.

Don't buy into the meme, at the end of the day they are just text editors.

~~~
geowwy
It took me maybe a few hours to learn vim and I could be decently productive
in it. After that I just learnt through exploration.

For me it was definitely worthwhile. Vim is almost everywhere so I can easily
edit text wherever I go.

------
zimablue
Not to be divisive but I see a parallel here with what happened in the gaming
industry. As it became more popular and socially acceptable, the quality of
games went down, from the perspective of people who played games when they
were unpopular. Eg. baldurs gate vs fortnite. Development is now fueled by an
insatiable industry demand and fairly high salaries, and a lot of offshoring
to desperate countries where it’s a way out. The taste of people who only
write software in the context of cultural cache and a salary is always going
to be different from that of people attracted to something for its own sake.

This conversation even reflects that- Too comment how many days before I can
be productive for X company in JavaScript from scratch? That’s not a question
I’m interested in but it’s been accepted as the most interesting question
here.

------
kovek
How do you make scrolling to work not line-by-line but pixel-by-pixel in...
MacOS and Ubuntu? There’s some arcane installs that are each incrementally
better than the next one but none match the native scrolling experience you’d
usually see in a modern/graphical text editor

------
Yuioup
What makes Emacs attractive to me is that it's a programming environment which
you can modify on the fly. At least, that's what I have read, I've never
actually done it myself.

Visual Studio Code, the editor that I use daily, is based on Javascript
(Typescript) but I have yet to see a page by Microsoft explaining to me that I
can quickly whip up a script and execute it in my editor. From what I
understand you need to create an extension and I think that takes a bit of
setup.

A spiritual successor to Emacs could be an extensible editor based on a
language which you can interpret on the fly, modifying your environment as you
go along. That's what would make Emacs more attractive to me, along with
modern keybindings like arrow keys...

~~~
olivierestsage
FWIW, Emacs does support navigation via arrow keys by default, unless I am
misunderstanding what you mean.

~~~
Yuioup
Ten minutes after I posted my message I just realized that the concept of a
Macro has been around since the dawn of computing and is in large part
responsible for the meteoric rise of Microsoft (along with a lot of viruses)

What I mean is I'm looking for a editor with macro capabilities that can be
programmed in, say, Javascript, Python or Lua.

~~~
samatman
Neovim is an editor with macro capabilities, which can be programmed in
LuaJIT.

It's my terminal editor of choice, and yes, arrow keys work. But why would you
want to use them?

~~~
Yuioup
I've been using vim for 15 years so I know neovim.

But ... can you make changes in neovim while it's running?

Let me take it a step further. Imagine a text editor in which you can, while
it's running, literally go into its source code and make changes and that
those changes immediately take effect. If I'm not mistaken you can do that in
emacs. That's what I find intriguing about it, not the text editor.

~~~
samatman
I believe so, yes.

Neovim is less programmable than Emacs insofar as more of it is written in C,
it's substantially less documented, and Emacs has a substantial head start.

But yeah, still fundamentally a programmable text editor. If you wanted to set
up a file watcher over source code that automatically reloads it when files
change, there's nothing stopping you.

It's true that nothing other than Emacs is _quite_ like Emacs. Neovim is
evolving in the right direction though.

------
look_lookatme
Emacs 100% lacks a reasonable sidebar strategy. I use Visual Studio Code's
sidebar for 3 things, navigation via search, navigation via changed files,
navigation via directory tree. It is very fast to use all of those, even
though they are mouse oriented.

The only comparably fast and useful ripgrep that works out of the box in Emacs
is swiper, but it uses a temporary buffer. Deadgreap is great but you have to
harangue it behave in a similar way to the sidebar in vs code and even then
it's just not the same.

The other thing is emacs regexps suck and PCRE is the standard of every well
used regexp implementation in the world at this point and emacs ought to find
a way to transition to it.

~~~
jakear
You can use keyboard for all of those things in VS Code, just by the way :)

(On the team)

~~~
look_lookatme
Awesome. Y'all do great work. I have a couple of questions if you are checking
this thread:

1\. Do y'all do security analysis on extensions? Static analysis etc?
Specifically, I am talking about detecting potential source exfiltration type
stuff.

2\. Any chance you'll develop the ability to customize the editor via some
personal scripts vs a plugin? I'd like to implement a command to do a specific
thing (toggle between test and implementation in a rails project) but I don't
want to go through the process of creating a plugin... I just want to map a
shortcut to a TypeScript function. I know there is a couple of extensions that
try to enable this but it would be nice to have an official path to doing
these kinds of personal customizations.

~~~
jakear
1) see info here: [https://code.visualstudio.com/docs/editor/extension-
gallery#...](https://code.visualstudio.com/docs/editor/extension-gallery#_can-
i-trust-extensions-from-the-marketplace) I’m not going to say more here, but
if you post an issue someone will get back to you. :)

2\. I’d recommend just finding an extension that does this. It wouldn’t be
hard for an extension to implement, and supporting multiple extensibility
classes in core when we don’t need to probably won’t happen. What exactly are
you looking for in an “official path“?

~~~
look_lookatme
In Emacs land, ~/.emacs is executed as an arbitrary code. I would like to be
able to have a ~/.vscode.ts that contain a function and I would like to map
that function to command+t. It doesn't seem like a stretch to offer that
feature. Right now I have to use something like this:

[https://marketplace.visualstudio.com/items?itemName=ego-
digi...](https://marketplace.visualstudio.com/items?itemName=ego-
digital.vscode-powertools)

~~~
jakear
I encourage you to look into writing extensions, an extension which simply
registers a command that executes some script at a fixed location would be a
good starting point for learning.

------
helsinkiandrew
I still consider myself an emacs user even though I haven't used it for over a
decade (or 2?).

For me emacs is from a time where text was king - the productivity to use
Emacs for my entire work process - latex docs, coding and debug in multiple
languages, reading email, accessing remote systems (gdbserver, scp, ftp, even
gopher and the web) from within emacs without using the mouse was astounding.

But as things become more graphical - rich text email was the first, then the
web, UML, word/excel etc it became less useful.

Emacs feels like a long lost lover - sweet memories from a distant past, but
you can't go back.

------
nromiun
First of all I really like the value of Emacs as a modern lisp machine. And it
is the best environment to write in any lisp language.

But for anything else it is not good enough. Emacs Lisp is better then
vimscript but only if you are extending it. For just configuration I prefer
vimscript because it is so terse.

But IMO just better then vimscript is setting the bar too low. Imagine if it
had something like Neovim's msgpack and you could extend it in any language
you like. I am still hopeful something like that will happen.

------
mrwebmaster
It would be cool to have package statistics to know which packages are more
popular/used. The community is too fragmented at this moment, and there are
too many competing packages. While it's good to have diversity, having package
statistics will make it easier to choose the best packages for end-users and
package developers will focus on improving the most used packages. It will
also improve compatibility between packages.

Or is this already implemented? VS Code does it and it's a good feature.

~~~
celeritascelery
[https://melpa.org/#/?sort=downloads&asc=false](https://melpa.org/#/?sort=downloads&asc=false)

------
jshaqaw
I love Emacs. I don't use it beyond dabbling. The contradiction? I'm not a
full-time computer professional. Keeping Emacs stable and running just takes
too much bandwidth. It's a tool for dedicated professionals who get a massive
return on their investment spent optimizing and maintaining their Emacs setup.
Sadly as much as I love the idea of Emacs, I don't personally get enough
productivity return to justify the investment. It's not a flaw with Emacs.

~~~
craigsmansion
> I'm not a full-time computer professional.

Emacs is used by non-computer professionals as well. If your profession relies
on the manipulation of text, emacs is the tool to use.

>their investment spent optimizing and maintaining their Emacs setup.

It's really not that bad. Say you're a fiction writer: you only need to figure
out your preferred workflow once, but then you can use it for decades with
only minimal changes.

Of course, once you get the hang of it, you might think it convenient to be
able to write short mails directly, or do a bit of your own typesetting all
from the comfort of your, by now, favourite editor, but .emacs files usually
see very little churn. What's in a .emacs has usually just accumulated slowly
over the years as one's usage of the program increases.

------
guenthert
IDEs come and go, Emacs stays.

Turbo Pascal (wayyy back) was quite impressive (then), Visual Age for Java
much more so some fifteen years later. IntelliJ is alright (prefer it over
Eclipse, which somehow managed to lose the smart features of its predecessor).
Haven't tried VS Code yet, but from the videos I've seen, it seems quite
handy.

I stick with Emacs for two reasons: familiarity and SLIME (the next best thing
to a LISP Machine ;-}

------
cammil
It seems to me that productivity is the assumed goal. But that is not the
whole story. I also enjoy using Emacs. I appreciate and support its commitment
to free software. I like that _everything_ is customisable.

Also, I wonder if it would be possible to do a study on productivity between
IDEs. It seems to me much of the data would be measurable. One idea would be
to allow github users to state their IDE.

------
fallingfrog
I still use enacts for all my coding (with cua mode on), mostly because I have
yet to find another tool that does context sensitive indentation quite right.
And I suppose I’m just used to it. But I don’t actually use most of the power
features. I mean code is just text; all i really need is normal editing, and
the occasional search and replace. I also use org mode for all my notes.

------
loosetypes
Maybe not the appropriate forum but does anyone have a sane setup for the
insane javascript setup of modern times?

I love emacs and am willing to put the time into tooling and configuration.
But despite several hopeful attempts, I’ve been unable to manage anything
comparable to vscode for this environment.

That is, support for all versions of ecmascript, but also jsx, typescript, et
al.

~~~
KitDuncan
Sorry I don't use emacs, but Vim/Neovim is pretty easy to setup with coc and
all it's subextensions for stuff like eslint, tailwind, vue and whatever. It's
essentially just the VSCode language server running in Vim and it's awesome.

~~~
loosetypes
I appreciate the input and will look into the VSCode language server.

------
dimitar
One thing I've noticed is that I'm using not only Emacs but other editors, I
really like Org-mode for notes and cider-mode for Clojure but I find myself
switching to other editors including vim and VS Code when doing other tasks.

Perhaps something like Spacemacs but built around CUA-mode with a nice default
theme and menus will win people to the platform.

------
commandlinefan
I've been a vi user for about 30 years. Once, a few years back, I decided to
force myself to use emacs for a year to see if I could understand what people
saw in it. Once I realized, 10 months in, that I was counting the days before
I would "let" myself use vi again, I finally threw in the towel and bailed on
emacs.

------
nineparts
If they could make some kind of a visual layer that makes it look like Word
and Photoshop (not in the same time, I'm being realistic here), their name
would be remembered in eternity.

Of course, emulating the shortcuts & functionality of Word and Photoshop
shouldn't be considered a problem, we are talking Emacs here after all...

~~~
Cerium
A closer example might be autocad (at least older versions). You could do
everything with a mouse, but a true expert could type the plans for a building
faster than you can imagine.

~~~
nineparts
Yes, that's why it's fishy that GIMP doesn't emulate the Photoshop
shortcuts/menu structure.

But any arguments regarding word editing in latex markup I won't accept.

------
malkia
I used to use emacs daily, but nowadays sticking to "mg" and "vscode"...

~~~
dmortin
Org mode is really good for note taking, so emacs has uses even if one does
not use it for programming.

~~~
tehbeard
I gave it an honest try for 6 months and even as good as Org-mode is (I used
it to track project tasks, notes, timelogs, even had a go at custom
templates), the 80s design choices and trying to find information that didn't
expect a full working knowledge pushed me away from Emacs, might have been
made worse trying to do this on "the devil's OS".

I'd have loved to have been able to give magit a go.

I do still have Orgzly on my phone though.

------
pcj-github
Used emacs for years, switched to VSC as it's just more compatible with the
present time in terms of plugins, languages, and even simply working with
other people. Emacs is a thing of the past. I do really miss the kill-ring
though.

------
neop1x
I like Vim better because it's easier for me to press one key to do an action
or write :command. I can also use Vim on the mobile (Termux and other
terminals). Having to press CTRL+A CTRL+whatever doesn't make sense IMO.

------
bythckr
I attempted to learn Emacs first, then settled into VSCode+Vim.

I even tried recently, but failed again.

So, please share some good resource for learning emacs. That is the biggest
issue with trying emacs to see if it suits.

As it cannot be tried, its not considered.

Please suggest.

------
tjr
Just got a new Mac computer with Catalina pre-installed, and was surprised to
see

    
    
        zsh: command not found: emacs
    

Of course, I can (and did) install it myself, but it used to be included by
default.

~~~
KMnO4
I imagine that Apple is trying to remove GPL-licensed software from macOS.
Similar to the replacement of Bash (GPL) in favour of Zsh (MIT).

------
chrischen
The which-key feature (whos you key bindings by pressing the first key) of
doom and spacemacs is great for discoverability but would be infinitely better
if they also had a key binding instant search.

------
BOOSTERHIDROGEN
I'm not programmer, but I'm interested in emacs because someone say it can be
devonthink alternative, tried spacemacs, for a weeks, still don't understand
how its behave

------
choeger
If it was a tool to be mastered, there should be a way to learn it.
Unfortunately, due to the many, many ways to customize it, I struggle to see a
clear path to emacs mastery.

------
Grue3
First we need to make Common Lisp popular. Since it's nigh impossible to write
Common Lisp in any other editor, Emacs will certainly experience a surge of
popularity.

------
russellbeattie
Awesome! I haven't seen a good "Emacs vs. x" thread in _years_!! People are
coming out swinging as well! Woohoo! Where's the popcorn??

------
bor100003
I will repeat what others said but here we go. On my work pc, on windows,
VSCodium works much better when it comes to graphics.

------
rataata_jr
Firefox mode for Emacs would make me never leave emacs for anything else.

Multi threaded Emacs would be very nice as well.

------
googya
one reason i did not use EMACS is it is a bit slow in my Mac air, maybe i
should buy a better machine.

------
jack1243star
Emacs works poorly on Windows, that is the only reason I don't use it.

------
wetpaws
I tried to learn emacs but after the week of struggling through arcane
keybindings and the bizzare quirks I just noped. Emacs is cool but it did not
age well in a way that any software with three decade+ history would.

------
ggm
They need to restore the foot pedal options.

------
jsilence
Better defaults on the vanilla installation would be a nice.

Apart from that: How dare you criticize a god?

------
bfrog
Emacs is awesome. The default setup is near useless. Elisp is really not
exciting.

------
bitwize
Folks, I want to disabuse you of the notion that in order for Emacs to be any
good in 2020, it needs to be "modern". It needs a modern UI. Emacs Lisp should
be replaced with a modern language like JavaScript. Its display backend should
be replaced with something modern like embedding a browser engine and
rendering to HTML5. (I have literally seen this suggested on /r/emacs). At any
rate it should be accessible via a browser in the cloud, because in the future
everybody will develop in the cloud. If somehow the maintainers do all of
these, then it would only serve to effectively transform Emacs into Visual
Studio Code, and it would make a shitty clone of Visual Studio Code at that.
So ｍｏｄｅｒｎ. There are parallels with the efforts, started in the late 90s, to
make Linux into an inferior clone of Microsoft Windows to increase its
popularity.

The problem is, much of what today's twentysomething webdevs consider modern
is mere fad. It is not objectively better (and is sometimes objectively worse)
in terms of user affordance than what we had in the 90s. The current trends in
UI design obscure distinctions which were bloody obvious in the days of
bevelled gray buttons. Browser engines run like pigs, especially when compared
with simple bit-mapped windows, and developing in the cloud hits a brick wall
when your network connection goes down.

I want you to try something. Try to imagine Emacs not as an ancient editor in
need of modernization, but as a programmers' tool _from the future_. It may be
a grim future indeed, one in which programmers learned some harsh lessons --
that not all programming is webdev, and the dominance of webdev in the field
today is likely to be short-lived; that CPU and RAM are cheap, but not free;
that networks go down; that software the user can't examine and completely
control is software that is potentially hostile to the user; that the job of a
program's UI is to enable work and not to dazzle the user; and that
programmers have a higher duty to expand their users' minds, making them
capable of more than when they started, and not to simperingly cater to 1984's
notions of what an absolute beginner should experience. (The implications of
the fact that Stallman learned many of these in the 70s and 80s is left as an
exercise.)

But a program from far enough in the future is just as incomprehensible to
today's users (especially today's generation-Z webdevs) as a program from the
distant past, the difference being that the future program is likely to be
much, much more advanced -- and today's users can learn a lot by understanding
it on its own terms as they try to unlock its secret power. So it is with
Emacs -- an omni-tool designed to be shaped and sculpted by the user into just
the thing for the task at hand _as the user works with it_. No kidding
--hacking something together in Emacs Lisp is so easy, for many data munging
tasks it compares favorably to _regular_ Lisp. Such hacks may not be beautiful
or elegant or even production-ready, but if they let you get a job done
quickly, they're valid. When you combine Lisp's eldritch power with the
ubiquitous buffer abstraction and all that enables, you have a juggernaut for
information workflow optimization -- and by comparison, Visual Studio Code is
explicitly designed _not_ to be extensible in such an ad hoc fashion.

Try this in your editor: Emacs has a command M-. If you are working on some
Emacs Lisp and you type M-. on a symbol with a function binding, Emacs will
jump to the function definition, opening the file it's compiled in if
necessary. If you keep drilling down like this, eventually you will hit
bedrock: the primitive functions of Emacs implemented in C. If you compiled
your Emacs from source, and you say M-. on one of these, Emacs will _remember
where its own source lives_ and take you straight to the C file and line where
the primitive is defined. This, my friends, is the quintessence of open
source.

Plus, Emacs can talk to text terminals and bitmapped displays, and almost
everything works the same either way. When I finally get my VT330 working, I'm
going to hook it up to my sweet-ass Ryzen box, fire up Emacs, and take
advantage of all its modern -- nay, _futuristic_ \-- power from my 1980s
terminal. Why? _Because I can._ More practically, this means Emacs can
communicate with its user over very low bandwidth channels -- making it ideal
for working with remotely, cloud or otherwise.

And all this in an editor, several instances of which can be supported by a
cheapass SBC like the Raspberry Pi. It's a bloody miracle of design, even as
its hackishness is made manifest.

Emacs doesn't _need_ to be changed to suit the whim and caprice of today's
developers. Emacs is eternal, an emanation of the Tao; if it were to somehow
disappear, somehow some way we would re-make it from scratch. It's not without
faults, it can be improved, but the ideas behind it are transcendent and
unmoving, and should not be compromised in favor of webdev fads. Let it shine
forth like a beacon unto the void, and let its luminousness enlighten all
those who are drawn to it.

------
Iwan-Zotow
I heard it is called VS Code nowadays

------
telaelit
vi > emacs

If you disagree you're either just a troll or lying to yourself

~~~
Uhhrrr
Emacs has vi emulation. Does vi have Emacs emulation?

------
nojito
The only way emacs get popular is if it changes its licensing.

Everything else is just window dressing.

------
blackrock
One thing is to make the keyboard shortcuts better.

Get rid of the ancient and archaic method of Ctrl-C to start a command chord.
Reserve that for basic commands like copy and paste.

Instead, use the slash, Ctrl-/ to start a command chord. This way, you can use
all the nifty shortcuts you want, and still not interfere with common
commands.

Another feature is to use Ctrl-Spacebar to allow a search of command aliases.

Like, highlight your words, then hit Ctrl-Spacebar, then type “upper”, and
it’ll do a dynamic search for all matches, and one of those matches is to make
the selection uppercase.

This can be useful for all types of commands and personalized macros.

But then, the other problem for Emacs, is that Visual Studio Code is pretty
damn good. And it also works on Linux. Its memory footprint is really high,
taking about 85 MBs of RAM, but Emacs takes like 30 MBs, so it’s less than 3x
more, for much better features. But, it’s not like I’m using a 20 year old
laptop anymore.

~~~
samatman
> _Instead, use the slash, Ctrl- / to start a command chord_

This has an obscure problem, of which you were no doubt unaware.

In the terminal, Ctrl-/ sends backspace. Emacs isn't commonly used in the
terminal anymore, but it can't become useless in the terminal, and this change
would make it useless.

Unfortunately this is a non-starter.

~~~
blackrock
Then use the dot: Ctrl-.

~~~
samatman
^. just sends .

The ASCII page on Wikipedia does a good job of explaining what all these
limitations are about. There's CSI-u mode, and I believe terminal emacs
understands it if you enable it, but, yeah. There's a lot of legacy to support
when your program is older than Unix.

------
NelsonMinar
The kindest thing we could do for future programmers is let Emacs and all tty-
oriented editors die. There are much better options now. UI has improved a lot
since the 1970s, let's embrace it.

~~~
talentedcoin
I’m sorry, what?

Which modern editor has tools like SLIME or CIDER?

~~~
azinman2
Genuine question: what's different about SLIME/CIDER than any IDE? Auto-
completion, documentation lookup, REPL, code reloading, unit test
integration... these are all in Xcode, IntelliJ, Eclipse, Visual Studio, etc
depending on language support.

