
My thoughts about editors in 2020 - todsacerdoti
https://phaazon.net/blog/editors-in-2020
======
etaioinshrdlu
My thoughts after coding for 15 years now... I still can’t be bothered to
learn emacs or vim. I’ve tried and it just never sticks. I remember fewer
commands in vim than I knew 10 years ago.

I really like smart IDE’s like IntelliJ and pycharm. I’m doing a typescript
project in VSCode and the refactoring and code understanding is just... not
enough. I agree with James Gosling’s opinion of heavy IDE’s. They help me. I’m
not out to prove any my manliness

Also, I feel like I do more reading code and debugging than writing nowadays,
and I am not bothered by my speed at writing code.

~~~
kaesar14
It’s always seemed silly to me not to use tools that make your job easier.
JetBrains products are the most powerful software I have to get my work done.

~~~
mixmastamyk
Those things are often huge, slow, and take a long time to learn—not all
sunshine and roses. When the control panel has search you know you're in one.
All a tradeoff of course.

~~~
YZF
Huge but not really slow. They automate a lot of common tasks, super fast
searches/navigation, refactoring etc. Code analysis is just there. Often my
fellow non-IDE users struggle to find the piece of code when we're chatting
whereas for me navigating or finding things anywhere in a really large code
base is pretty much instant. I stopped pointing it out unless it's a good
friend I just want to rib a little.

~~~
sodapopcan
Most non-IDE users I meet IRL don't take the time to beef up their tool and
actually learn how to properly use it. There are also those who flat out
refuse to install any plugins, for example, plugins that could make searching
large codebases very fast. I don't understand these people, but to each their
own! <3

Of course, the whole reason many people chose an editor over an IDE is because
they don't want to learn an IDE so, not much you can do there. I've worked
with plenty of people who use an IDE and barely using any of its features.

~~~
mixmastamyk
Searching can be handled with ag or ripgrep and used anywhere with any text
files, with only a terminal.

~~~
YZF
I've never used ripgrep... Does it do offline indexing? because that's what my
IDE does and why search is instant. Tools that actually have to go and search
everything will never be as fast. Obviously that sort of functionality can
exist outside an IDE... And functionality can be added via plugins to any
editor...

~~~
burntsushi
Not yet. But offline indexing isn't going to matter much until the amount of
code you need to search is many GBs and/or doesn't fit in your page cache.

------
zmmmmm
It's interesting that none of all this is really the reason why I use what I
use ... I use vim simply because it is ubiquitously installed on every linux
and Mac system no matter what or where, including keybindings in every other
editor or IDE I would ever encounter, including the bash command line (after
set -o vi) and FireFox (with SurfingKeys).

The fact that it happens to be powerful enough to do everything I want is of
course necessary, but there are dozens of editors that satisfy that
requirement. Simply not having to switch out of Vim navigation or move my
hands off the keyboard for the whole day across the dozens of different tools
that I use is what makes it a winner.

~~~
dozzman
> I use vim simply because it is ubiquitously installed on every linux and Mac
> system no matter what or where

This was also my initial reason for learning Vim so that I could comfortably
write code on any machine I encountered, but the editing experience was
actually really fast and enjoyable so I stuck with it ever since.

------
m463
I've been using emacs or vi for a long time.

emacs is my primary editor.

I used to use vi/vim more, because it is available just about everywhere and
it's great for quickly editing a config file on a remote system.

But once I started using tramp, I now use emacs for all systems.

Tramp is a built-in way of editing files on remote systems using ssh as the
transport. I can edit remote config files on dumb iot devices that don't run
much more than busybox - with highlighting and undo and all the full-featured
stuff.

open /ssh:foo:.profile to edit your profile on remote system foo.

You can also mix files - local and remote - all in different buffers.
copy/paste between them, etc.

One thing he mentioned I haven't tried is LSP. anyone have any tips?

~~~
Izkata
> But once I started using tramp, I now use emacs for all systems.

> Tramp is a built-in way of editing files on remote systems using ssh as the
> transport. I can edit remote config files on dumb iot devices that don't run
> much more than busybox - with highlighting and undo and all the full-
> featured stuff.

> open /ssh:foo:.profile to edit your profile on remote system foo.

Vim does it through scp:

    
    
      vim scp://user@host//path/to/file
    

I don't usually use it (since vim is pretty much guaranteed to be installed
remotely anyway), so I don't know what pitfalls/weirdness may exist, I just
know it has the functionality.

~~~
m463
thank you, I learned something new today.

------
somada141
I’m a big fan of the JetBrains ecosystem which I think has won the IDE wars
(given its ubiquity). Once you get comfortable working in one of their tools
and configure it to your needs it’s easy to carry that over to the next tool.

What I was never sold on was their DB offering Datagrip which never felt
intuitive for my work. There I was a big fan of SequelPro for MySQL but when
it comes to other RDBMS the jury is still out (have tried Navicat, TablePlus,
and a myriad others)

------
strait
During the period of about 10 years that I was using Emacs as my main editor,
I invested countless hours in mastering Elisp, configuring this and that,
writing custom functions, fixing abandoned minor modes that I still found
useful... It was literally all over the place.

At some point, the list of things that were broken/didn't work well for me got
quite long, and I became dissatisfied enough to stop what I was doing and
start going through various elisp packages, trying to understand what was
really happening.

Let me say first, that I really admire and respect the potential of Lisp. When
the code is well written, it is elegant, reasonably comprehensible, and
malleable. However, when the code gets sloppy or unnecessary levels of
abstraction are added to 'just make things work', it quickly becomes
inscrutable. I kept running into package after package of this kind of poorly
written, inscrutable Elisp. One package was using EIEIO (object-oriented
Elisp) and there were excess levels of indirection all over the place, across
thousands of lines of code.

Org-tables are pretty neat, but ultimately a fancy gimmick. I had a 7 column
table, and after 200 rows, the reformatting became ridiculously slow. After
looking through the tens of thousands of lines of org-mode Elisp code, my main
question was, "Is all this code really necessary?" I know that org-mode does a
lot, but Elisp is a dynamically typed scripting-level language. With macros.
What went wrong?

~~~
bzg
Did you try to see what made the table unusable? If you feel want, you can
report this to emacs-orgmode@gnu.org and maybe we can do something about it.
Thanks!

------
pcvonz
I've sunk a pretty substantial amount of time into learning vim (neovim) and
imo it's paid big dividends in taking the monotony out of text editing tasks.
But, I don't limit myself to one tool. If I need a graphical debugger or the
language doesn't have a fast lightweight language server, I use an IDE.

I switch between neovim and an IDE pretty frequently. I use yakuake to open up
a terminal when I need it. best of both worlds! Plugins like comrade[1] make
this pairing delightful. If your definition of a VIM mode only includes text
objects and navigation, than an IDE with VIM bindings is plenty to replace it,
but it doesn't cut it for me. My workflow has become reliant on VIM macros,
global commands, buffers, and filters. I also haven't found a compelling
reason to replace Fugitive[2] for another Git GUI.

None of the stuff I do in neovim is necessary, but it's fast, flexible, a bit
obtuse, and pretty dang fun.

It's tough to fill the editing niche VIM fits because of the peculiarities
that make it VIM. Doesn't mean that it's the de facto editor for every
situation.

[1] [https://github.com/beeender/Comrade](https://github.com/beeender/Comrade)

[2] [https://github.com/tpope/vim-fugitive](https://github.com/tpope/vim-
fugitive)

------
msla
> Even though it could be seen as a positive point, I think that all the great
> plugins emacs has make it very bloated, and that’s a problem to me. For
> instance, Org-mode, which is a wonderful piece of software, should have
> benefited much more people if it was a standalone application. To me, it
> feels like starting using emacs will lead to using your computer to run
> emacs, and all your applications inside emacs. It even has an IRC plugin and
> an email reader plugin!

That's the point, yes.

Emacs' philosophy isn't so much text editing as it is using text as a
convenient representation of something else and then having a powerful set of
text-editing primitives you can use to manipulate whatever it is you're using
text to represent. Living inside Emacs means always getting to use those
customized, "slick" (in the author's words) text editing commands to do
everything.

Emacs has gotten to where Web browsers are going, except Emacs isn't evil
unless you actively make it so. ;)

------
baby
I spent some time learning emacs, and I use it every time I'm in the terminal
and need quick access to a file, or SSH into a machine, but there's no way
I'll ever spend the time to make it my main editor. The learning curve is not
steep, it's fixed to a "hard" mode: every new plugin you want to try, you'll
have to figure out how to use and there'll be some time adaptation to learn
new shortcuts.

While I don't see them dying, since editors in a terminal is still a thing,
but I'm wondering if we're going to see alternatives popping up at some point,
or perhaps VSCode will have a "ssh into this machine and open the file in the
editor" flow at some point.

Realistically editors like VSCode and Sublime text are the future: easily
extendable AND it's fast to try new plugins. If you don't remember a shortcut
just cmd + P, fuzzy type what you want to do, remember the shortcut displayed
next to the name for next time.

~~~
candiddevmike
Good news, you can do remote development in VSCode:
[https://code.visualstudio.com/docs/remote/remote-
overview](https://code.visualstudio.com/docs/remote/remote-overview)

~~~
baby
holy shit! Thanks so much, this is awesome!

------
hardwaregeek
I love my emacs commands and I have a .emacs file with various snippets and
packages like any good user, but I've been finding myself using it less and
less.

First it started with front end development. I couldn't get emacs to play nice
with syntax highlighting modern front end. I could get JSX highlighted OR I
could get TypeScript highlighted. Not both. I started using WebStorm and
discovered that the emacs keybindings were pretty good! Not perfect but the
best I've found outside of emacs. And the refactoring! So nice, so convenient.

I still used emacs for various languages. Ruby, Python, then some Rust. I
wrote a solid amount of Rust in emacs. But then my Rust projects started
growing, I started wanting automatic refactors and good type info. A couple
times setting up language servers on emacs had chastened me. So I switched to
IntelliJ Rust. And damn, it's really nice. Same decent emacs keybindings, with
really good language tooling. I can see the inferred type of a variable while
I'm typing it out. I can refactor without having to run cargo all the time.

At this point I use emacs for writing blog posts, Python/Ruby, and config
files. That's it. Oh and debugging wasm binaries. Hexl-mode is still
unrivaled. It's a little sad though. I learned to program as I learned emacs.
I like the idea of having a powerful, text crunching editor. But it's so damn
inconvenient. Everything feels a little tacked on. Language servers are super
brittle and hard to get right. Multiple cursors mostly work but aren't the
first class citizens of IntelliJ.

If I had to provide a thesis on why emacs is failing me, it's because emacs
was designed to manipulate text. It's incredibly good at that. But code these
days isn't text. It's hypertext. It's a code graph that is automatically
formatted, refactored and linked. Emacs can certainly treat code that way, but
it's a lot of work and a lot of suffering that IDEs provide out of the box.

------
candiddevmike
I have a tendency to switch between VSCode and Neovim on a semiannual basis--
mostly to come back to the speed and native vi in Neovim, only to switch back
after going through plugin hell for weeks.

Neovim could be a great editor if they spent more time adding core plugins to
the main program. I see it's starting to happen a little with the built in LSP
and package manager, but it should do more. The docs are a mess for
configuring some of these bleeding edge features (like the floating windows),
and it definitely impacts my workflow without them.

On the flip side, VSCode has too many "non sensible" defaults for my liking,
especially between versions. Nothing grinds my gears more than making a big
edit, only to look at the diff and realize some plugin decided to autoformat
everything. VSCode also has a tendency to hang, especially with vim mode for
some reason

------
GolDDranks
I realised that the reason why I haven't bothered to learn powerful keyboard-
based navigation controls, is because I'm almost totally distanced myself from
using a normal mouse. I love using MacBook Pro trackpad more, and I feel
restrained every time I use mouse.

This also affects the amount of hand movement: the trackpad is a lot closer to
the keyboard, so navigating with it doesn't bother me that much. In the long
run, I'm sure that learning stuff like the author would be a nice boost, but I
don't simply feel the need.

------
MrOxiMoron
It's funny how people who know vim expect every other editor to have support
for it's keybindings too, while I as a non vim user am expected to love and
learn vim keybindings

~~~
dijit
Not entirely sure how true that is.

I’m a heavy vim user and I love it, but that’s me.

I work with people who can navigate codebased absurdly swiftly and debug
things faster than I ever could, and they use visual studio keybindings.

It’s all about knowing your tools; I’m a sysadmin so vim (Or, vi) has a high
value for me as learning the keybindings makes me more powerful on my entire
fleet.

For developers though? Debugging and codebase navigation is significantly more
valuable- you read more than you write.

------
ImaCake
Things look quite different in biostatistics research and adjacent fields. I
personally use vscode, nano, and rstudio. But I am still mostly wetlab. People
in my research group use some combination of these, maybe atom, and I am sure
some of them like vim or emacs, but I haven't asked. The python guy uses
vscode instead of intelliJ. I haven't seen anyone use vscode over RStudio, for
R. But some of us will occasionally preference R intepreter in the terminal.

------
codemac
His "types of navigation" doesn't include searching as navigation.

I use emacs with C-s (isearch-forward) more often than left and right.

~~~
taeric
Ace jump has become a very welcome nature for jumping to a spot.

~~~
codemac
But it only works on what you can currently see, right? Or does ace jump work
differently than I recall.

isearch moving you along further in the buffer interactively as you type is
far more useful than searching what you just see, and typing rando letters
that appear. If it's on the wrong entry with the same word, I just hit C-s
again - which is very fast to type repeatedly (rather than ace's find the
right letter combo, and type it).

~~~
taeric
Fair. ace-search which has a delay to turn into ace-jump is what I actually
use. With enough characters, defaults to helm-swoop.

------
mplanchard
I just wanted to note for the author, if they’re here, that VSCode has a
newish plugin called neovim I think that actually uses neovim itself to handle
movement and editing, so it should work no matter how odd the config.

I currently use VSCode and Doom Emacs, after being a fairly long time vim
user, fwiw.

------
kstrauser
I stopped reading when they wrote that they preferred modal editors because
they hate navigating with arrow keys. Uh, I use to live in Emacs and now I use
VS Code, and you could remove my arrow keys for all I’d care (or notice).
Those are entirely orthogonal, like “I prefer cars to bikes because I like
tires.”

~~~
addicted
How do you navigate text in VSCode without arrow keys (and equivalents such as
Pg Up/Dn, Home, End)

I’m not sure about the author, but I consider emacs essentially a modal
editor. The vast majority of actions are preceded by a combination of modifier
key presses, which is essentially modal, except you can’t (or can you?) keep
it sticky.

So, for example, next line in Emacs is Ctrl+N whereas in Vim is Esc+J. The
only difference in VIM is that you don’t need to hit ESC the next time want to
go to the next line whereas Emacs reverts you to “insert” mode requiring you
to press Ctrl again. But in both you can type out a number to allow you to
jump 5 lines instead of just 1 with each key press.

Of course, those are only the in built modes. In many ways, emacs is even more
modal than Vim, since there are so many packages that shift you into different
custom modes With different behavior (e.g. org mode, magit, etc).

~~~
OrderlyTiamat
That's not modal though. You could make it modal/sticky with e.g. god-mode,
evil-mode, or others, but essentially its a single shortcut (yes, it uses two
keys instead of one, but that doesn't make it modal: try pressing Ctrl and
afterwards pressing n like with esc h for vim, I don't think it'll work...)

Org-mode and magit are modes in the sense that they are different
environments, not input modes. You won't have a good time trying to update
your calendar using magit, and reverting the latest commit is going to be a
challenge from within org-mode. These are different tools.

I'd say once again, emacs _can_ be as modal as you like, more or less exactly
like vim, or it can be non-modal.

~~~
bzg
Well, of course you can revert a commit from org-mode.

Simply create a bash source code block that goes in the right directory and
does the git revert. \o/

------
fao_
I'll crosspost what I wrotw about Doom Emacs on Reddit:

\-----------------

> The killer feature of Atom to me is its ability to tell you what commands
> are associated (or erased) for a keybinding you are pressing, live. It is
> very practical to debug keybinding issues and I wish more editors had it.
> Other editors feature _similar_ stuff, but not quite as good as this _echo
> mode_ for keybinding.

Btw, for Doom Emacs this is accessible through the help interface.

`SPC h k <key combo>` will open up the manual page for that function, with a
description, list of keybindings, argument list, and at the bottom, full code
listing where you can jump to references including callers/callees and examine
the code in-situ if you need.

`SPC h b b` will allow you interactive search through Doom Emacs bindings and
bring up the same as above, and `SPC h b` exposes other neat things like
keymaps for the current major-mode, etc.

\---

Honestly, I have been using Vim constantly in various forms -- GVim, Vim, Vi,
ex-vi, Neovim, etc. (Even ex and ed(1) for a little period) for about 8 years.
I discovered Doom Emacs this July, and gave it a few hours. Then I kept on
giving it a few hours. A week later I hadn't boot up vim for a week. With Vim,
there was always a barrier around writing extensions -- it never really felt
like it was _meant_ to be integrated with them. The single best Vi experience
I've had wasn't with Neovim, it was with ex-vi. There were some sharp edges
but the interface felt orders of magnitude more clean than I was used to.

I had tried Emacs before but Spacemacs was poorly integrated -- I tried using
package-install and I was dumped into a buffer with no evil-mode bindings. And
learning Emacs was a hilarious nightmare. Just look at these amazingly
terrible commands to know how horrible that was[0], the last straw was when I
tried to undo using `C-x u` (I think?) and it undid one character at a time!

Two things sold me on Doom Emacs - the support, and the feeling I get when
using it.

* The support is amazing, I can't even begin to comprehend how much the maintainer, Henrik, works at it. He has a well-developed system on the discord where you can hit up one of the assigned channels (how-do-i or troubleshooting are the main ones as a newbie), tag \@helpme, and you will get seen quickly. He stays up until 2 am some nights answering support requests, and has put a lot of work into `doom doctor` so there are some rudimentary diagnosics included. It is by far the most pleasant and memorable support experience I've ever had with any piece of software in the 10 years I've been programming, and I have a _huge_ amount of respect for him.

\- The feeling I get when using it is harder to quantify. I'll attempt to
quantify the 4 or so years I spent digging into hacker history in the
following comparison: \- Vim - Editing becomes _muscle memory_ , so you don't
need to think. You can sit down at a computer and be sure it has some variant
of Vim that you can use almost like normal. \- Emacs - The editor grows around
you, as you customize it to your taste. You're taking an editor built on a
language, and altering the code, patching in improvements. Each Emacs instance
is totally unique, and can rarely be used by another Emacsen (I actually
vaguely recall reading/hearing of a joke where it was implied the Emacs
instance and the beard grew into each other).

Doom Emacs, for me at least, is the perfect blend of the muscle memory
interface power of Vim, and the "block of clay" feeling I get from Emacs.

[0]:
[https://www.gnu.org/software/emacs/manual/html_node/emacs/Ch...](https://www.gnu.org/software/emacs/manual/html_node/emacs/Change-
Window.html#Change-Window)

~~~
OrderlyTiamat
That feeling while using it is very recognizable to me. It's like the cliché
about swordfighting: the tool is an extension of your arm, rather than
something you interact with.

------
YarickR2
No Sublime Text in review; huge omission

~~~
tuatoru
What about `cat > file.txt .... [Ctrl]-D' and `sed'?

(Joking, but for very small files, I'm doing this more and more.)

~~~
YarickR2
Oh, nothing like 'cat <binary> | base64' , copy, paste in another terminal to
cat <<_EOF_ | base64 -d > <binary>

extremely useful in locked down environments

