
Why don’t we have good code editors? - kreykjalin
https://kristofer.reykjal.in/2019/09/27/its-2019-why-dont-we-have-good-code-editors/
======
tlackemann
> In all seriousness though, a terminal does not a pleasant user experience
> make.

Yes, yes it does. At my fingertips I have access to every single tool and
program without needing to clumsily navigate through folders or Finder,
whatever it is. Moving my hand away from my keyboard to my mouse to check TS
typings is biggest waste of time when I know how to get to any line in any
file with less than 3 keystrokes.

> The way these editors achieve this is through graphical representation of
> the project hierarchy – the file sidebar

I work on a site which is part game engine, part marketplace, and part React
application. I have never once used a file tree because I don't need it to
understand the code. This isn't a flaw of terminal editors, it's classic
PEBKAC.

Terminal editors don't suck. They require learning and discipline, something
that some might argue is becoming a lost art in this field. In the days of
"gluing modules together", maybe vim isn't for you, but it's for me and this
piece contributed nothing.

~~~
shawnz
The mouse is not a "clumsy" input and there are plenty of situations in which
the mouse allows more efficient usage than the keyboard like when navigating
through 2D space. For example it is clearly more efficient to place your
cursor at a certain arbitrary point in the document using the mouse than to
navigate there using keyboard commands.

I'm also not really convinced about the "hands on the keyboard" argument...
What percentage of the time that you work are your hands actually on the
keyboard and ready to input? Are they on the keyboard right now? Because that
seems like an uncomfortable way to sit at a workstation. I also don't think it
takes very much time to switch between the input devices unless maybe you
don't have practice with that workflow.

~~~
majewsky
> Are they on the keyboard right now?

Of course they're not on the keyboard while I'm exclusively reading. But while
I'm in vim, my hands certainly are on the keyboard nearly at all times,
resting on the home row.

~~~
c256
When I’m trying to understand code, my hands are absolutely on the keyboard.
This is very common and quite efficient once you learn how to navigate using a
code editor.

This is similar to the way a mathematician will often ‘read’ math with a
pencil and paper, or a musician will ‘read’ music with an instrument in hand.

When I’m reading prose, I often don’t have either a keyboard or a mouse, but
that’s a very different operation (uses different parts of the brain, etc).

------
fennecfoxen
> Terminal editors are out of date. By this I don’t mean that they’re
> obsolete; I mean their user experience is lagging far behind modern
> standards. Using editors like Vim and Emacs is not a good experience for the
> user.

You... you are aware that you can run emacs _not in a terminal_ , right? Use
the mouse and resize split buffers and everything? It's okay if you still
don't think it's good enough, just... don't pigeonhole it _quite_ like that.

~~~
c256
Modern GUI emacs has basically all of the features that the OP’s rant mentions
(You can even run WebKit inside of emacs, if you want), but they have to be
configured. It seems likely that they haven’t tried emacs in a while, because
the rant demands things about packages that already exist. If this were a
serious request for help rather than a rant, “Use Spacemacs or Doom-emacs”
would be a fine response.

That said, there’s nothing wrong with a little rant now and then. There’s a
pretty pervasive feeling among programmers that our tools for interacting with
code certainly could be better, and probably should be. I assume the OP is
hitting one of those moments right now.

More seriously, though, I believe that there is an answer to the headline
question: we don’t have better code editors because the people with the
combination of skill, desire, and opportunity almost always fall into one of
the two traps:

1.) If they want to make a better general editor for experienced, skilled
programmers, then they get sucked into learning an existing editor (usually
emacs or vi, sometimes both) on the way, and they find that once you are
proficient, those are really quite powerful coding environments.

2.) If you want to make a better general editor for people learning to code,
then they tend to create something that is limited (simplified, streamlined,
etc). Along the way, they either stop at a version that’s good enough (there
are lots of these around), but definitely missing things that are important to
(a smaller group of) skilled, experienced programmers – at which point, see
#1. The strongest candidates survive, and some of them go quite far (Linus
Torvalds uses a fork of micro-emacs, there are people at Google who use nano,
etc.)

In the end, the “editor wars” between emacs and vi came down (IMNSHO) to a
question between “fast and lean” vs. “expandable”. In the end, both became
”expandable enough”, and software growth (bloat) grew so extensive that both
became “fast and lean enough”.

------
jimmyvalmer
Summary: I would like a vscode that better integrates modal editing.

Verbosity is an existential threat.

~~~
Ballas
Well, it would not be a proper rant if it wasn't as verbose.

------
bauerd
>a terminal does not a pleasant user experience make

Author doesn't establish this, just takes it as a given. I wonder what
features terminal emulators/editor programs would lack that are afforded by
GUIs? I consider the terminal text editing experience far more efficient

~~~
bipinu
Efficient is not necessarily a pleasant user experience though, is it? I am
not downplaying anyone's preference of one over the other. However, a better
UX would mean that the initial learning curve to start with something should
be low, which isn't usually with terminals.

~~~
carlmr
>However, a better UX would mean that the initial learning curve to start with
something should be low, which isn't usually with terminals.

Depends how you define better. If you do something very often a steep learning
curve with long term payoff can be the better UX seen as a whole.

I use almost only VSCode mind you, but I can see the argument here. I know a
bit of vim and it is practical when configuring servers via PUTTY. For bigger
projects I find it very lacking.

------
roryrjb
I disagree. Terminal _is_ modern it's just different to GUIs, of course they
were a precursor but I don't think anyone can say that GUIs are supposed to be
a replacement, as in, I don't think they can say this in retrospect. It's just
a different interface, which to me is much more convenient and intuitive. I
can pick up a command line application that I have never used before and get
up to speed very quickly. Obviously this does depend on the usage of
conventions, such as environment variables, arguments, man pages and so on but
because of its perceived "limitation" it probably means that applications in
this domain are more alike to each other at least in terms of their
interfaces. I am biased of course, I live inside tmux and vim and I would
happily just use the framebuffer (and use cmus, newsboat, irssi, mplayer, et
al) but I _have_ to use a browser for work so yeah. Vim is a very good user
experience, you either have to learn it a lot to be productive, or use a few
plugins that gloss over this somewhat, but I don't think it has such a massive
learning curve considering its vibrant ecosystem. Emacs on the other hand, and
I really like the keybindings (using a subset in the shell) just makes my head
hurt.

------
kace91
I think there could be a huge market for a ux effort that brings the somewhat
forgotten goodies of old modal editors into the modern world, combining them
with new advances like fuzzy searching. I love vim, but it's appalling that we
have so many historical baggage creating a gap for the users...

It's so obvious how vim's ergonomics are made for the [adm 3a
keyboard]([https://catonmat.net/images/why-vim-uses-hjkl/lsi-
adm3a-full...](https://catonmat.net/images/why-vim-uses-hjkl/lsi-adm3a-full-
keyboard.jpg)) (location of esc, control, arrow keys, etc) and yet we keep
making layers of customization or force ourselves to the standard instead of
doing the very needed reboot.

------
GordonS
Erm, we do have good editors? VSCode, Visual Studio, Rider, to name but a few.

I'm not really sure what the OP's beef is here. They begin by bemoaning
anything that isn't vim, then move on to say they want a graphical UI, support
for plugins, and a bunch of other things that pretty much _any_ IDE has these
days.

I think what they really want is a vim extension for VSCode, customised just
for them?

~~~
Ballas
>I think what they really want is a vim extension for VSCode, customised just
for them?

Exactly. But they don't want to write it themselves.

------
sundayedition
Vim has plugins that seem to address most of what you note.

Nerdtree gives you see semblance of a graphical UI. I rarely use it since
installing fzf and getting better at using buffers. It's much, much easier to
press a shortcut and type a partial name. I use Nerdtree when I need to browse
the hierarchy. I also previously had ranger integrated into vim which is
really nice

Vim has tons of user extensions. Yeah, the package managers aren't great UI
but I use vim awesome website to browse and a plug-in install is a simple copy
paste of 1 line.

Using tabnine with vim has been really great for autocomplete. It's probably
not as good as vs code but it's good enough for me.

Peek at implementation is available via ctags. Configuration can admittedly be
a bear but I have a shortcut to jump to the method definition under the cursor
that works pretty well.

I'm using neovim which is usually fast and responsive. Some things like
folding and syntax highlighting aren't great in certain conditions but you can
write scripts to disable those things in those conditions (file name, and
probably size even)

I've tried to switch away from vim but the extensibility is better than any
other editor I've looked at. Neovim + tmux makes me feel pretty productive

~~~
drcongo
TabNine is amazing. I use it with SublimeText and it constantly surprises me
by guessing correctly what I was about to type, sometimes even when what I'm
about to type doesn't exist in any of my codebases.

------
vinceguidry
Use Spacemacs. Take everything that's great about Vim, and Emacs, make the
configuration sane, and the features super-discoverable. You'll never look
back.

------
GordonS
Does anyone know what "modal editing" is?

I've read the article, and it's mentioned several times, but I've no idea what
it actually means.

~~~
dhagz
Basically, having two ways of interacting with the file: one mode lets you
execute commands to edit the file, the other mode lets you type like in a
typical GUI editor.

~~~
GordonS
While editing a file in VSCode, I can press CTRL+P, which opens a small
command box in which I can type to find a command with autocomplete - like a
souped-up version of vim's "colon prompt" (not sure what it's called!) - does
that count?

~~~
mpfundstein
No

~~~
GordonS
OK... what is the difference, as you see it?

~~~
notmainacct
The real difference is that in Normal mode, you have a very complete set of
commands bound to each key that either move the cursor from an absolute
perspective, relative to current position, or relative to syntax structure.
There are also commands that create a selection to transition you into Visual
mode (which is cursor selection) with a given syntax block already selected.
Finally, all of these commands can be multiplied out `4w` to move four words
ahead instead just one word ahead.

The real power of these is twofold. First you can build muscle memory that
lets you move around a text file, precisely select text, and edit the text as
fast as you can think. Secondly, all of the commands used to edit text can be
recorded into a macro, letting you systematically and repeatedly edit text in
a way more powerful than find and replace with high-level regex support (which
vim and emacs also have). An example macro could be jump to the next define
keyword, then jump to the next set of parenthesis (which would typically be a
function parameter)and then reverse the parameters of the function. This macro
can be repeated to reverse the parameters of every function in a file, as well
as in many files in your workspace. This is fast editing of the semantic
structure and convention in a workspace. While this is a contrived example,
This editing functionality is very useful for many tasks like re-arranging the
structure of each object in a large JSON document to fit to a new schema,
refactoring code as well as any task that requires automating many repeated
edits. Other editors and IDEs have macro functionality, but without the
composable structural editing commands in vim (these are also in emacs) you
don't quite have the same kind of power. These kind of edits would otherwise
need to be done by a separate script, but the interactivity of NORMAL mode
commands and macros let you know that it works for one case, repeat the macro
individually and check each case as you go to make sure that it worked, and
then edit the macro if the command macro needs to be modified for new
structures.

Edit: I forgot to mention that normal mode is also very fast and simple which
is much more convenient than CTRL-P for a command. 'w' for moving to the next
word. 'b' for moving to the previous words. The command chaining is also
relatively consistent for editing as well with 'ciw' for 'change inner word'
to select the entire word the cursor is on delete it and then enter insert
mode and 'ci('for the same but selecting all the text within the first set of
parenthesis that contain the cursor. Many vim emulation plugins don't even
feature these commands and only have basic modes and hjkl cursor movement.

~~~
pnako
> Other editors and IDEs have macro functionality, but without the composable
> structural editing commands in vim (these are also in emacs) you don't quite
> have the same kind of power.

That's the other way around. Modern IDEs don't work on text like vim does,
they understand the language. Using e.g. JetBrains IDEs you can do refactoring
across an entire code base in a few clicks. Something you can't possibly do
because vim (unless you use plugins) doesn't understand the semantics or even
the syntax of the language, it's just text.

------
iikoolpp
> The most limiting factor for my choice of code editors is that I need modal
> editing. After learning how to use Emacs, and then Vim, I can not imagine
> going back to the typical non-modal text editing. These editors make it much
> more comfortable to edit text (and code), and ruined every other way of
> editing for me.

Truly, v*m rots the brain.

------
ScottFree
This rant reminds me of Gary Bernhardt's talk from Strange Loop 2012[0]. In
that talk, Gary shows a true modal editor that has more than just "edit" and
"write" modes. His talk focused mostly on visual layers that could be laid
overtop of the code, but it made me think adding "debugging" and "git" modes
would be nice. I certainly wish git had a dedicated mode every time I use
fugitive[1].

[0]: [https://www.destroyallsoftware.com/talks/a-whole-new-
world](https://www.destroyallsoftware.com/talks/a-whole-new-world) [1]:
[https://github.com/tpope/vim-fugitive](https://github.com/tpope/vim-fugitive)

------
coldcode
Because no one can agree on what is "good". It's entirely subjective to each
person. One loves vim, one loves Notepad, one loves VSCode, one loves
Intellij, maybe someone loves hammer and chisel on stones. Like virtually
everything in the programming world, it's all about what gives you the ability
to do what you need to do with the least extra effort. Like any tool you need
what you need, not what someone else says you need. Arguing about what is
better is pointless but common.

------
WilliamEdward
His first topic / sub-heading answers the question for itself: people are too
fussy about editors. Everyone has different tastes when it comes to editors,
some want syntax highlighting, some like integrated command line, some just
want plaintext.

There are no two people with the exact same preference in editors, and that's
why there are too many editors and yet still a perceived lack of quality
overall.

It's also why most people end up customising the ever loving shit out of their
own editors anyway.

------
sword_smith
I like that the author has high standards for an editor. He should have. In my
opinion VSCode and VS live up to his requirements about out of the box
intellisense, inline definition peeking, and extensions that are easy to
install (VS Code being better than VS in this regard). They probably don't
live up to his model requirement, though, but I think the author could have
done a better job of explaining exactly what he wants from this editing mode.

------
dhagz
Vim has mouse support. You just need to turn it on in your .vimrc/init.vim
with `set mouse=nv` (that specifically enables the mouse in normal and visual
modes).

~~~
mpfundstein
Does that work in terminal? Afaik I had the only working in gvim.

~~~
gtf21
Works for me (iTerm2 + tmux + vim/neovim).

------
giancarlostoro
I am kind of excited for Emacs in Rust. I would love something Emacs like that
looks modern and easier to manage like VS' ability to easily drag and drop
components wherever you need them, and is very fast to boot, think of ST3,
CudaText, and co. Then all the bloatware is optional plugins.

I would say VS Code is a good goal, it has everything you need to have an IDE,
and yet you don't feel forced to use it.

~~~
nika1975
The main reason for Emacs existence is the ability to customize it as you
want. That's made possible by Lisp. It is on a whole different level than a
VSCode plugin. How does Rust enhance this experience?

I do not get the requirement to be "very fast to boot". My Emacs instance is
always running and I use emacsclient as an entrance point for external tools.
This is the typical workflow for Emacs users.

~~~
giancarlostoro
I don't want to even think about those things. I don't have to with Visual
Studio or VS Code.

------
jbergens
I think Emacs and Vim missed how popular js got. That is a reason why Atom and
VSCode has tons of plugins for everything including some Intellisense-like
completion.

------
iKnowWhyIamHere
I think I can relate to his feelings. I want vim with default Intellisense of
VS Code.

I know about coc-nvim, but I still couldn't get it to work for C++ on Ubuntu
19.04, will try again soon.

~~~
pnako
> I want vim with default Intellisense of VS Code.

Your best bet is probably CLion (it's proprietary) with IdeaVim plugin. It's
not perfect but it's probably easier to implement vim-mode into any IDE than
turn vim into an IDE.

~~~
boring_twenties
I used to use IdeaVim with IntelliJ, it was utterly awful.

All of the basic commands were wildly incompatible with vi and vim. Example: u
(undo). Not only would it add cursor movements to the undo stack, it would
also put multiple actions onto the stack as one, so you could only undo them
all at once or not at all.

That's the one I remember most -- it's been over 5 years -- but not a single
day went by without some utterly flabbergasting surprise when expecting it to,
you know, emulate vi/vim.

Somewhat ironically, about 5 years before _that_ , I used some similar plugin
for Visual Studio and that one was infinitely better. It cost $99, but my
employer paid for it, and it actually performed as advertised.

Even that didn't implement "advanced" vim commands that I like a lot -- like
:perldo -- but at least it didn't fail to get even the basics right.

In the end I don't think any IDE vim-mode can be good enough. What I think
would be best is if the IDE somehow embedded the actual vim editor.

~~~
pnako
Sorry for recommending this. I have a lot of experience with Jetbrains IDE,
but not with the plugin itself. I use vim in vim mode occasionally :)

I think the Neovim project has a goal to eventually make the editor easy to
integrate in larger applications, as a plugin, which makes a ton of sense.

~~~
boring_twenties
Well now I'm sorry that you're sorry! Wasn't my intent, if it works for you
and are happy with it, of course you should recommend it. Maybe some people
don't even care about actual compatibility, and just want a modal editor.
That's fine. I only meant to add my own experience, not discount yours.

------
payne92
TL DR; The author wants a modal editor (like vim) that's also
"modern"/graphical.

My view: this is largely a religious issue.

Editor design is like QWERTY keyboards (or beer): preferences are more
dominated by your muscle memory and what you're used to, than any objective
notion of "good" or "best".

------
frou_dh
Inane article title required for clickbait?

