Because you only need to know one tool for every type of work you do. Except for inherently graphical tasks like drawing and diagramming.
When you use Emacs or Vim and live on the command line every project has the same workflow. You don't need to install 10 different IDEs and learn 10 different workflows for 10 different projects. You don't need to go through 117 layers of menus to apply compilation options because your IDE invokes the compiler for you. You don't need to use a mouse. No googling "how to X in PyCharm" 5 minutes after googling "How to X in Eclipse".
> When you use Emacs or Vim and live on the command line every project has the same workflow. You don't need to install 10 different IDEs and learn 10 different workflows for 10 different projects.
When I was demonstrating emacs to some co-workers last week, I opened up code in three different languages and pointed out how the comments were all the exact same color. It's little things like that. And having things like hl-todo-next/previous and flycheck-next/previous-error bound to the same keys in multiple programming languages, or binding F4/F5 to compile/recompile, and that works for any command I want to run, then I can parse through error and warning messages with next/previous-error, or cruise through blocks of code with C-M-a/C-M-e. And all of this works in C/C++, Python, Lisp, Perl, etc.
I have been using my same vim workflow now for twenty years, ever since I switched from Visual C++ 6... and, at the time, I configured some of the colors in vim to match parts of what I had been previously getting from Microsoft's editors. I thereby have had largely consistent colors for like, "a quarter of a century". Despite thinking a lot about syntax highlighting for various reasons, it honestly never once occurred to me--before reading your comment--that some (many?... _most_?!?) software developers don't have consistent syntax highlighting even across different languages much less through their career. OMG.
I think it is the combination of consistency and adaptability.
There are
a huge number of interesting features and tweaks
out there, and every once in a while one
encounters a useful gem. For example, I have
started to use Unicode more heavily in documentation,
and I am also a latex user, so now there is
a mode which lets one enter any kind of unicode
symbol by typing the latex sybol name.
Or another, I found that syntax highlighting
is neat but what is really helpful instead is
to give any identifiers in functions different
colors, which makes the data flow in the function
much more salient and quicker to understand -
including spelling mistakes. And that works in many languages.
Based on Lisp, Emacs has also very good support for REPL,
or read-eval-print-loop programming. My impression
is this is becoming more important. Anyway this is
an extremely valuable feature if one programs
Common Lisp, Racket, Clojure, Forth, or Python (noting
that Python has only partial support for that kind
of programming, but it still helps a lot).
People often brag about "advanced" features of vim or emacs like you do, but everything you say is pretty standard these days. Vscode does the same. So does Intellij.
> When I was demonstrating emacs to some co-workers last week, I opened up code in three different languages and pointed out how the comments were all the exact same color.
I don't get this. That is normal in any modern editor. What is so special about this?
To add to all these good points, also the fact that vi/emacs isn't going away on the whim of some company that comes and goes. So the effort to learn these (and any long-lived open source components) is amortized over my lifetime, not the short lifetime of a commercial tool.
Whenever I change projects or jobs I know emacs will be there as efficient as always so I can concentrate on being productive instead of on learning yet another ephemeral IDE.
I haven't even been a developer long, but I remember everyone was using Eclipse then Sublime then Atom then Brackets then VSCode. This was all within a span of 3 years.
I've been using vim for most of my career but will use other tools when pairing or working with others, the only thing I regret is not learning the intricacies of vim more.
I'm not proficient but every few months I improve more and more, and it's nice to use a tool that has been around for decades and will continue to be around for decades more.
The most important advantage of Emacs and vi are, these
are open systems, which come out of an open culture,
not just "open source" but really free software, with
no strings attached. Granted, open source is having its
successes, so companies are trying to jump onto that
bandwagon, but this has mainly the consequence that the
strings attached are less visible - like "telemetrics",
inacceptable spyware, waste of attention, artificial
obstacles to competitor languages / systems,
unwarranted and empty hype, and so on. It is important
to recognize the tone of that, and to listen to it, and
to think about it, because it can warn you before
making bad decisions.
Also, Emacs has top-notch documentation.
While basic commands are not that hard to learn, there
is certainly a lot of stuff one can learn, so much that
it takes some amount of conscious effort to learn a
good fraction of what is relevant to certain
tasks. That said, Emacs also makes fantastic use of a
undervalued property of the human brain, which is
automatic decluttering, forgotting and blending out
things which are not in use, like a diligent and
friendly housemaid which brings anything which you
haven't really used in the last year into the attic ;-)
But, jokes aside, exactly like learning the Linux
command line well, learning some Emacs is an
/excellent/ use of ones time as a programmer, because
the half-life time of the knowledge you gather is much
much longer than when you just learn the latest
IDE. Chances are that your IDE du jour will be mostly
forgotten five or six years from now. Chances are high
that the basic command-line tools and Emacs commands
you learn now will still be useful twenty and thirty
years from now.
I think you may be overly generous to Emacs. When I use Emacs, it's more I need to go through hundreds of lines of others' Emacs Lisp configurations to figure out how to do the thing I want to do or spend many times 5 minutes Googling how to do <x> in Emacs. A good example of this is Elixir's helpful coloring and tab completion in its help documents. When I tried running Iex in an Emacs terminal, it just didn't work, and after Googling, it's just a mess of solutions. It literally just works in Visual Studio Code's terminal.
I forced myself to learn Emacs for a class, and it was really quite painful. I get the power of the bindings and all that, but it's really a mess of an ecosystem, and I encountered plenty of bugs. Even then, I never got things to work just right, and it worked poorly when doing things across Windows and WSL boundaries. Another thing was that any time someone used my Emacs, they couldn't because it wasn't like their Emacs.
So I've just gotten used to Visual Studio Code because I spend more time doing the thing I wanted to do than finding out how to do something simple in the editor. I add a single custom keybinding for toggling between the terminal and the code window, which can now be synced using a Microsoft account. I just install whatever extension I want (through one extension manager) and go at it. Combine this with the extremely powerful and useful extensions of Remote - SSH and Remote - WSL that allow you to use Visual Studio Code on basically any other computer with your extensions as they work on Windows, then you have a one-stop shop for development.
Is Visual Studio Code perfect? No. Can someone be more productive in Emacs than Visual Studio Code? Yes, but likely only if they've spent an inordinate amount of time learning Emacs and Emacs Lisp. But Visual Studio Code provides a nice balance of a single environment across languages that evolves with users' needs and basically anyone can be productive in it today.
My personal preference is to use the standard IDE with whatever language I am using, and then to default to Visual Studio Code whenever there is no such standard. I also use a fair amount of visual languages that text editors do not work for.
I can't speak for Emacs, but just this week I went through my vimrc file and deleted half of the configuration. Turns out now that I've started to grok the finer points of the editor, the heap of cool mappings, functions, and must-have plugins I found on the internet are more hindrance than help.
Another thing was that any time someone used my Emacs, they couldn't because it wasn't like their Emacs.
You hit the nail on the head. I spent months forcing myself to use nothing but Emacs to get past the "this is unfamiliar and therefore hard" stage. My final conclusion after the experience was that Emacs is pretty powerful out of the box but it is absolutely a general purpose environment and you have to meld it to your own workflow to truly unlock its potential.
Even though I don't use Emacs these days, one thing I did keep was swapping capslock and ctrl on my keyboard. That is useful for so many other things and I'm never going back.
Any kind of set-up is done in textual configuration. And this is
a major plus.
That means you get quickly to see what you have configured,
you can put it into version control and check it out
on a different machine, and so on. This is a big ergonomical
difference to IDEs.
As the technical foundation, it is rock-solid. Emacs is
based on lisp which has basic text manipulation
instructions implemented in native code. This makes it
both extremely easy to configure and extend it. It is
also from a time when Linux was not yet existant, Unix
was not yet universal, and Lisp machines were a thing,
so it has a certain platform feeling - while also
having good access to the OS. It is certainly possible
to use Emacs in text mode as a login shell or as a
terminal manager.
To that adds another quality of Emacs and vi,
one which these IDE enthusiasts can not even
understand, which is that the user interface
is incredibly stable. And this means that
something you have become used to will
not change and drift under your feet
like quicksand. And in the long run, this
really saves a ton of time. That does not
mean you can't change things, rather you can
change stuff under your control, like using
the better-defaults setup.
If you learn vim or emacs, you will discover that for literally any task that is interacting with text in some form (plain text, code, spreadsheets, presentations), there is almost always an extension in these "text editors" (which really are working environments) that facilitates that work. Hence the claim that you only need to learn one tool rather than a dozen.
Right, but you only have Jetbrains installed locally. It's useless if you're SSH'ed into a remote machine (usually through a jump box for security reasons).
I've watched someone struggle for literally hours in Emacs wading through dependencies to track down an issue. He then resorted to grep and kept spending time.
The same task would be accomplished in one click in Eclipse.
I do not understand why this article has such a negative bias against vim and/or emacs users. Comparing an emacs/vim user and a dog that does not want to walk on grass seems gross. Even calling them stubborn, well... The authors claim that "Modern IDEs are magic". As a freelance devops, i don't code-for-a-living being a magician, all i want to do is editing text, most of the time there's no magic involved.
"Why are so many coders still using a keyboard?" Answer for yourself.
I have been using emacs for a decade, and finally settled on vi/vim because of its broader availability. Both are excellent editors. I have also used dozens of graphical user interfaces for development, but as a devops i sometimes find myself in an environment that does not support graphics.
Not having graphics at your fingertips may sound like a restriction, but it allows me to focus on my code rather than being distracted by color, hints, hovers, help, type ahead, code completion and the like. I do not need all that, i can freely speak my favourite programming language same as i can write a text without referring to the encyclopedia britannica every other word.
Final rant: i consider the bio "He's spend over 15 years as a technical writer" as sloppy as the whole article.
For me, the word "magic" in the context of program development is ambivalent at best. Often, it refers to stuff that some software tries to automate wildly, with the result that in easy cases it works nicely, without you having a description of what really happens, and in more complex cases it fails and turns into a mess, without you having any actual clue what happens. I think "magic" works actually only if you do have an interface which takes responsibility of actually everything, like an SSD firmware driver doing write layout for wear leveling.
And no, getting 2,000 lines of automated boilerplate for some mundane programming task isn't "magic".....
The word "still" turns a honest question into a loaded, ugly question. There's thousands of people who are starting to use vim today. You can ask, why do they? That is a relevant question. The question of why old users of these editors keep using them is mostly uninteresting.
This presumption really bothered me too. The tone of the authors is very anti-vim without ever stopping to mention that vim can be dressed up with plugins, command line tools, unix philosophy, etc.
It appears that neither of the authors are developers... the quality of the article would have been a lot better if they hadn't stereotyped vim users so much / admitted there are legitimate reasons to prefer a text-based interface over a GUI for en editor in 2020.
I'm surprised that a company like Stack Overflow would publish such a narrow-minded article on their company blog... surely they have developers internally using vim they could have talked to...
Agreed, the word "still" and quite frankly the rest of the article shows the author hasn't taken the effort to understand why someone likes something they don't like themselves.
This could have been an article written by a windows10 user who asks the question "why are so many people "still" using linux?". New people start to use linux today and quite frankly there's a lot of good reasons to use it over the newest windows. Obviously same can be said about vim.
As the parent says, this sounds like a loaded
question. In fact, it sounds just like som marketing
departmetn which wants to promote some IDE is trying to
gather reasons and possibly features which need to be
added to some "competitor" IDE, in order to gather more
market share. I write that because to me, the interest
to actual answer to the question - why people use these
open-source editores - seems somewhat thin.
But, as somebody who uses Emacs, why not use the
attention for some Emacs marketing.
Before going on, I use Emacs mostly since about 22
years. I am also occasionally using vi (mostly for
system administration) or mg (which is a very
light-weight editor with basic emacs keybindings). I've
also used a host of other tools, for example in some
work environments there was really no other alternative
than to use Visual Studio, or Eclipse, and in some the
most practical thing to use was notepad++.
So, why Emacs?
At first, and something that might be interesting to
beginners, basic editing in Emacs, such as to produce
similar results to using notepad++, is actually quick
to learn. It has a nice on-line tutorial and very good
interactive documentation. The fundamental philosophy
it has is that basic text editing is modeless, that is,
one uses a (possibly large) number of key combinations
to modify text, and the basic combinations are
universal. And this is already the main difference to
vi/vim, where the meaning of basic key commands always
depends on the mode. Emacs does have modes, however,
for advanced commands which modify different /kinds/ of
text.
Emacs supports a large number of programming languages
out-of-the-box, which includes anything you need to
write for documentation. This saves a lot of time when
setting up projects. It is also very quick to set up
additional packages and modes.
Emacs and vi/vim both are based on the notion that code
is text: They are optimized for text editing, and in my
experience this is absolutely the right thing to do. I
had the dubious pleasure to use several systems which
use code as kind of point of entry to some kind of
database or graphical system or whatever, and these
are, universally, just a pain in the ass.
Compared to IDEs, Emacs loads and starts very, very
fast. In cases where one want it even faster and don't
need that many features, one can use emacsclient, or
the mg editor, or, of course, vi. It is also possible
to use Emacs in a text terminal, which is invaluable
for remote work on servers or embedded systems, and it
also has good support for the shell's job control:
Running in terminal mode (starting with the "-nw"
option), Ctrl-Z will bring you to the shell, and "fg"
will bring you back to your Emacs session.
Sure, it's a soft prison, of keyboard-only specialized-interface goodness. but a prison, still.
I've heard chanting before, but this time it's different. It's louder. Could it be? I resolve to try a daring escape. If I can get this new C++ project set up properly, I might be out free! I've chosen an accomplice of good repute: VS Code.
After 30 minutes of figuring out which extension to add for the project, how to configure the build, I still haven't managed to get it working. What could be the issue? It builds fine in the IDE but won't find declarations and headers properly. The google oracle offers no help. Hey, mr. Magician: I can compile the project just fine myself in a terminal, why don't YOU read my Makefile and figure it out?
Too late, the vim guards arrive. They open my CMakeLists.txt parchment, and write "set( CMAKE_EXPORT_COMPILE_COMMANDS ON )". Immediately, YouCompleteMe whirrs to life and works perfectly. The guards drag me back in my old cell.
Oh well, it's not so bad here, at least I can focus. And it keeps the mouse away. Until the next time I hear people outside chanting "Modern IDEs are magic".
> That said, if you’re new to programming, a modern IDE could be helpful. With code completion, Git control, and even automatic deployment systems, modern IDEs are a Swiss Army Knife of features.
Just in case anyone reading here is as colossally ignorant as the writer, let me state for the record that emacs has those features. I don't use vim but I'm pretty sure it has them too. An accurate list of how newer IDEs benefit newbies follows:
Biggest problem with IDEs is they are a big in-your-face hurricane of features that is often too much.
As a newbie you want to create a single-line Hello World program but the goddamn IDE wants you to create a workspace, and then within that workspace create a project, and within that project create a bunch of infests and manifests and resources and XML files, and pretty soon you're lost.
> Biggest problem with IDEs is they are a big in-your-face hurricane of features that is often too much.
This is another aspect. They suck up attention, which is a scarce resource. It is just like you start a web browser to look up some documentation, and it shows a dozen of interesting sites you might want to read because the browser developers got some money from these sites, or whatever.
Good software typically has a sparse feeling (depending on which are its intended users), in the sense that it does not distract.
But this is just a symptom of a bigger issue that they are not really friendly to the developer.
For git in Vim I use the fugitive plugin[1] and I find it's really good. If you find it lacking in any way you can always combine it freely with other plugins. For instance gitgutter[2] that shows diffs in the sign column, giving you an easy view of which lines have been added, removed or changed.
There are solutions for the others too. Neovim has for example support for the Language Server Protocol[3] that gives you code completion, jump to definition and the like.
The only thing with Vim/Emacs at this point is that you have to do some configuration and find some plugins to get the IDE features you want. For me personally, as I use Vim for everything, it's not that big of a deal.
Your bias is showing. They never said that Vim/Emacs _doesn't_ have those. And modern IDEs generally make them much more discoverable and usable.
No-one is saying that "Vemacs" can't do everything that IDEs can do - they clearly can, with sufficient configuration, plugins, and so on. But the IDEs are generally "ready to go out-of-the-box"
You are technically correct that they never said vim/emacs lacks those features. A tiny bit of reading comprehension effort can illuminate the intent of juxtaposed sentences.
Well, Emacs user interface and key bindings are by experience much more stable over time, especially if you consider that in ten year's time, that "new" IDE probably is probably not going to be around any more.
That also means that some default configurations do not have a "modern" feel like copy/paste key bindings. However stability in the long term is important for users of a complex and powerful program, which Emacs is. And if you want, you can always change the key bindings to your liking.
There are also options like the betterdefaults package which modernize bindings and add features without breaking anyones flow.
Actually I disagree with the premise itself (that if you’re new to programming, a modern IDE could be helpful). There's a LOT of distraction in an IDE, and it does a lot of magic behind the scenes that you need to be aware of, because sometimes it does something unexpected and you have to be able to tell it not to. If you're learning something, you need to be able to focus on the piece that you're learning, master it, and then expand from there - that's how everything is taught, for good reason.
The great thing about both Emacs and Vim is that you can "customize any feature." All of the other things you're looking for just naturally flow out of that.
The extensibility of Emacs is a major boon. Here an example:
I never did real Emacs hacking, but I learned some Lisp
stuff over the years, a bit of Clojure, Racket,
and Common Lisp each. Now, I have a very experienced
senior coworker which was asking for help -
there was a feature which was just not working
for his flow, he had tried to configure it but
without success. Now, I looked into the
Emacs library code and that was a pleasant
experience, it is very transparent and readable
and easy to modify, so that it was not difficult
to adapt it to my coworkers's needs.
The extensibility also means that, because there are
many many people hacking on Emacs, that it stays very
up-to-date. For example, Magit which is, I
think, the best git front-end in existence. Or there is
ranger mode, (ranger is a console file manger). In this
sense, Emacs is not "antiquated", as the blog article
insinuates, but it is much more recent and modern than
any IDE. Take, as an example, git support: It took
Visual Studio about fifteen years to add git support,
in part obviously because the vendor company did not
think supporting git was helpful to the companies
objectives. In comparison to that, Emacs picked up
version control options such as subversion or git
almost immediately. As a result, Visual Studio users
were left for fifteen years without support for the
perhaps most important technical advance in
programming. You may now argue, that the "modern" IDEs
of course do have support for git, but there are surely
other things which will be missing, just because it
does not fit some companies narrative or marketing
strategy. Another brewing revolution is that
programming culture is drifting away from C++ and Java,
in parts even from OOP, which is not any more the best
option for every case, and companies which are
invested in these "technologies" (uh, what a word),
will again try to stop the clock, in order to squeeze a
bit more money out of it.
I feel like you could do a single-image rebuttal to this article, consisting of a timeline of various popular code editors/IDEs that have come and gone since 1976, and how many of them are still around.
I mean, fuck, I've only been in this industry since 2011, and that's still long enough for me to recall the "rise" of half a dozen code editors (SublimeText! Atom! Intellij! VisualStudioCode!). I imagine most people don't like re-learning their entire workflow every couple of years, and just want to get back to coding.
I'm only slightly older than Vim itself (but much younger than vi), but I've used it for virtually my whole career. The one thing the author's missing is the real reason every Vim user uses it:
Vim is not an editor. It's a language. A text-editing language.
When I'm editing, I'm thinking things like:
- change these 2 words: "c2w"
- remove everything in these parentheses: "di)"
- delete this line: "dd"
- where is this declared: "gd" (this is a custom CoC.vim mapping)
Any editor implementing that language would probably see very good adoption in Vim user circles (e.g nvim).
Readit News
When you use Emacs or Vim and live on the command line every project has the same workflow. You don't need to install 10 different IDEs and learn 10 different workflows for 10 different projects. You don't need to go through 117 layers of menus to apply compilation options because your IDE invokes the compiler for you. You don't need to use a mouse. No googling "how to X in PyCharm" 5 minutes after googling "How to X in Eclipse".
When I was demonstrating emacs to some co-workers last week, I opened up code in three different languages and pointed out how the comments were all the exact same color. It's little things like that. And having things like hl-todo-next/previous and flycheck-next/previous-error bound to the same keys in multiple programming languages, or binding F4/F5 to compile/recompile, and that works for any command I want to run, then I can parse through error and warning messages with next/previous-error, or cruise through blocks of code with C-M-a/C-M-e. And all of this works in C/C++, Python, Lisp, Perl, etc.
There are a huge number of interesting features and tweaks out there, and every once in a while one encounters a useful gem. For example, I have started to use Unicode more heavily in documentation, and I am also a latex user, so now there is a mode which lets one enter any kind of unicode symbol by typing the latex sybol name.
Or another, I found that syntax highlighting is neat but what is really helpful instead is to give any identifiers in functions different colors, which makes the data flow in the function much more salient and quicker to understand - including spelling mistakes. And that works in many languages.
There many Emacs packages that can do this, for example: https://polymode.github.io/screenshots/
I don't get this. That is normal in any modern editor. What is so special about this?
Whenever I change projects or jobs I know emacs will be there as efficient as always so I can concentrate on being productive instead of on learning yet another ephemeral IDE.
I've been using vim for most of my career but will use other tools when pairing or working with others, the only thing I regret is not learning the intricacies of vim more.
I'm not proficient but every few months I improve more and more, and it's nice to use a tool that has been around for decades and will continue to be around for decades more.
Also, Emacs has top-notch documentation. While basic commands are not that hard to learn, there is certainly a lot of stuff one can learn, so much that it takes some amount of conscious effort to learn a good fraction of what is relevant to certain tasks. That said, Emacs also makes fantastic use of a undervalued property of the human brain, which is automatic decluttering, forgotting and blending out things which are not in use, like a diligent and friendly housemaid which brings anything which you haven't really used in the last year into the attic ;-)
But, jokes aside, exactly like learning the Linux command line well, learning some Emacs is an /excellent/ use of ones time as a programmer, because the half-life time of the knowledge you gather is much much longer than when you just learn the latest IDE. Chances are that your IDE du jour will be mostly forgotten five or six years from now. Chances are high that the basic command-line tools and Emacs commands you learn now will still be useful twenty and thirty years from now.
I forced myself to learn Emacs for a class, and it was really quite painful. I get the power of the bindings and all that, but it's really a mess of an ecosystem, and I encountered plenty of bugs. Even then, I never got things to work just right, and it worked poorly when doing things across Windows and WSL boundaries. Another thing was that any time someone used my Emacs, they couldn't because it wasn't like their Emacs.
So I've just gotten used to Visual Studio Code because I spend more time doing the thing I wanted to do than finding out how to do something simple in the editor. I add a single custom keybinding for toggling between the terminal and the code window, which can now be synced using a Microsoft account. I just install whatever extension I want (through one extension manager) and go at it. Combine this with the extremely powerful and useful extensions of Remote - SSH and Remote - WSL that allow you to use Visual Studio Code on basically any other computer with your extensions as they work on Windows, then you have a one-stop shop for development.
https://code.visualstudio.com/docs/remote/remote-overview
And by the way, Visual Studio Code can do graphical tasks: https://marketplace.visualstudio.com/items?itemName=hediet.v...
Is Visual Studio Code perfect? No. Can someone be more productive in Emacs than Visual Studio Code? Yes, but likely only if they've spent an inordinate amount of time learning Emacs and Emacs Lisp. But Visual Studio Code provides a nice balance of a single environment across languages that evolves with users' needs and basically anyone can be productive in it today.
My personal preference is to use the standard IDE with whatever language I am using, and then to default to Visual Studio Code whenever there is no such standard. I also use a fair amount of visual languages that text editors do not work for.
Even though I don't use Emacs these days, one thing I did keep was swapping capslock and ctrl on my keyboard. That is useful for so many other things and I'm never going back.
As the technical foundation, it is rock-solid. Emacs is based on lisp which has basic text manipulation instructions implemented in native code. This makes it both extremely easy to configure and extend it. It is also from a time when Linux was not yet existant, Unix was not yet universal, and Lisp machines were a thing, so it has a certain platform feeling - while also having good access to the OS. It is certainly possible to use Emacs in text mode as a login shell or as a terminal manager.
To that adds another quality of Emacs and vi, one which these IDE enthusiasts can not even understand, which is that the user interface is incredibly stable. And this means that something you have become used to will not change and drift under your feet like quicksand. And in the long run, this really saves a ton of time. That does not mean you can't change things, rather you can change stuff under your control, like using the better-defaults setup.
That seems just obviously incorrect to me.
I do all sorts of things, and use all sorts of tools. Am I missing something?
Let me introduce you to graphviz.
https://graphviz.org
https://plantuml.com/
It's backed by Graphviz, but optimized for the kinds of diagrams software people typically do. Works very nicely with org mode too!
But I started using Emacs in 1992, and it still does what I need (thank you language server protocol).
Will VS Code exist and offer the same experience over a whole career?
The same task would be accomplished in one click in Eclipse.
There is a reason why specialized tools exist.
"Why are so many coders still using a keyboard?" Answer for yourself.
I have been using emacs for a decade, and finally settled on vi/vim because of its broader availability. Both are excellent editors. I have also used dozens of graphical user interfaces for development, but as a devops i sometimes find myself in an environment that does not support graphics.
Not having graphics at your fingertips may sound like a restriction, but it allows me to focus on my code rather than being distracted by color, hints, hovers, help, type ahead, code completion and the like. I do not need all that, i can freely speak my favourite programming language same as i can write a text without referring to the encyclopedia britannica every other word.
Final rant: i consider the bio "He's spend over 15 years as a technical writer" as sloppy as the whole article.
For me, the word "magic" in the context of program development is ambivalent at best. Often, it refers to stuff that some software tries to automate wildly, with the result that in easy cases it works nicely, without you having a description of what really happens, and in more complex cases it fails and turns into a mess, without you having any actual clue what happens. I think "magic" works actually only if you do have an interface which takes responsibility of actually everything, like an SSD firmware driver doing write layout for wear leveling.
And no, getting 2,000 lines of automated boilerplate for some mundane programming task isn't "magic".....
It appears that neither of the authors are developers... the quality of the article would have been a lot better if they hadn't stereotyped vim users so much / admitted there are legitimate reasons to prefer a text-based interface over a GUI for en editor in 2020.
I'm surprised that a company like Stack Overflow would publish such a narrow-minded article on their company blog... surely they have developers internally using vim they could have talked to...
Habit and sticking with something that works are, like, good things most of the time!
> This has led users to literally turn Atom into Vim, unable to let go of the past, unwilling to fully embrace the future of code editing.
> unable to let go of the past, unwilling to fully embrace the future of code editing.
W-what?
This could have been an article written by a windows10 user who asks the question "why are so many people "still" using linux?". New people start to use linux today and quite frankly there's a lot of good reasons to use it over the newest windows. Obviously same can be said about vim.
But, as somebody who uses Emacs, why not use the attention for some Emacs marketing.
Before going on, I use Emacs mostly since about 22 years. I am also occasionally using vi (mostly for system administration) or mg (which is a very light-weight editor with basic emacs keybindings). I've also used a host of other tools, for example in some work environments there was really no other alternative than to use Visual Studio, or Eclipse, and in some the most practical thing to use was notepad++.
So, why Emacs?
At first, and something that might be interesting to beginners, basic editing in Emacs, such as to produce similar results to using notepad++, is actually quick to learn. It has a nice on-line tutorial and very good interactive documentation. The fundamental philosophy it has is that basic text editing is modeless, that is, one uses a (possibly large) number of key combinations to modify text, and the basic combinations are universal. And this is already the main difference to vi/vim, where the meaning of basic key commands always depends on the mode. Emacs does have modes, however, for advanced commands which modify different /kinds/ of text.
Emacs supports a large number of programming languages out-of-the-box, which includes anything you need to write for documentation. This saves a lot of time when setting up projects. It is also very quick to set up additional packages and modes.
Emacs and vi/vim both are based on the notion that code is text: They are optimized for text editing, and in my experience this is absolutely the right thing to do. I had the dubious pleasure to use several systems which use code as kind of point of entry to some kind of database or graphical system or whatever, and these are, universally, just a pain in the ass.
Compared to IDEs, Emacs loads and starts very, very fast. In cases where one want it even faster and don't need that many features, one can use emacsclient, or the mg editor, or, of course, vi. It is also possible to use Emacs in a text terminal, which is invaluable for remote work on servers or embedded systems, and it also has good support for the shell's job control: Running in terminal mode (starting with the "-nw" option), Ctrl-Z will bring you to the shell, and "fg" will bring you back to your Emacs session.
Sure, it's a soft prison, of keyboard-only specialized-interface goodness. but a prison, still.
I've heard chanting before, but this time it's different. It's louder. Could it be? I resolve to try a daring escape. If I can get this new C++ project set up properly, I might be out free! I've chosen an accomplice of good repute: VS Code.
After 30 minutes of figuring out which extension to add for the project, how to configure the build, I still haven't managed to get it working. What could be the issue? It builds fine in the IDE but won't find declarations and headers properly. The google oracle offers no help. Hey, mr. Magician: I can compile the project just fine myself in a terminal, why don't YOU read my Makefile and figure it out?
Too late, the vim guards arrive. They open my CMakeLists.txt parchment, and write "set( CMAKE_EXPORT_COMPILE_COMMANDS ON )". Immediately, YouCompleteMe whirrs to life and works perfectly. The guards drag me back in my old cell.
Oh well, it's not so bad here, at least I can focus. And it keeps the mouse away. Until the next time I hear people outside chanting "Modern IDEs are magic".
Just in case anyone reading here is as colossally ignorant as the writer, let me state for the record that emacs has those features. I don't use vim but I'm pretty sure it has them too. An accurate list of how newer IDEs benefit newbies follows:
1. Familiar key bindings
As a newbie you want to create a single-line Hello World program but the goddamn IDE wants you to create a workspace, and then within that workspace create a project, and within that project create a bunch of infests and manifests and resources and XML files, and pretty soon you're lost.
This is another aspect. They suck up attention, which is a scarce resource. It is just like you start a web browser to look up some documentation, and it shows a dozen of interesting sites you might want to read because the browser developers got some money from these sites, or whatever.
Good software typically has a sparse feeling (depending on which are its intended users), in the sense that it does not distract.
But this is just a symptom of a bigger issue that they are not really friendly to the developer.
https://stackoverflow.com/questions/11828270/how-do-i-exit-t...
There are solutions for the others too. Neovim has for example support for the Language Server Protocol[3] that gives you code completion, jump to definition and the like.
The only thing with Vim/Emacs at this point is that you have to do some configuration and find some plugins to get the IDE features you want. For me personally, as I use Vim for everything, it's not that big of a deal.
[1]: https://github.com/tpope/vim-fugitive
[2]: https://github.com/airblade/vim-gitgutter
[3]: https://nathansmith.io/posts/neovim-lsp/
Your bias is showing. They never said that Vim/Emacs _doesn't_ have those. And modern IDEs generally make them much more discoverable and usable.
No-one is saying that "Vemacs" can't do everything that IDEs can do - they clearly can, with sufficient configuration, plugins, and so on. But the IDEs are generally "ready to go out-of-the-box"
Well, Emacs user interface and key bindings are by experience much more stable over time, especially if you consider that in ten year's time, that "new" IDE probably is probably not going to be around any more.
That also means that some default configurations do not have a "modern" feel like copy/paste key bindings. However stability in the long term is important for users of a complex and powerful program, which Emacs is. And if you want, you can always change the key bindings to your liking.
There are also options like the betterdefaults package which modernize bindings and add features without breaking anyones flow.
--
[0] - I mean primarily the sense of "being paid for it".
[1] - Well, except for Eclipse. At least as of few years ago, default Eclipse had worse overall experience than even my worst beginner Emacs configs.
Some things I want out of an editor:
* Never having to touch the mouse in any way.
* The ability to customize any feature for my current project or mindset on a whim.
* No UI, as much as possible. Show me the content I'm editing and nothing else.
* A good, extensible, set of keybindings with a bunch of features for editing of raw text
I run my project in an IDE and will sometimes use a feature, but I generally don't develop there.
The extensibility also means that, because there are many many people hacking on Emacs, that it stays very up-to-date. For example, Magit which is, I think, the best git front-end in existence. Or there is ranger mode, (ranger is a console file manger). In this sense, Emacs is not "antiquated", as the blog article insinuates, but it is much more recent and modern than any IDE. Take, as an example, git support: It took Visual Studio about fifteen years to add git support, in part obviously because the vendor company did not think supporting git was helpful to the companies objectives. In comparison to that, Emacs picked up version control options such as subversion or git almost immediately. As a result, Visual Studio users were left for fifteen years without support for the perhaps most important technical advance in programming. You may now argue, that the "modern" IDEs of course do have support for git, but there are surely other things which will be missing, just because it does not fit some companies narrative or marketing strategy. Another brewing revolution is that programming culture is drifting away from C++ and Java, in parts even from OOP, which is not any more the best option for every case, and companies which are invested in these "technologies" (uh, what a word), will again try to stop the clock, in order to squeeze a bit more money out of it.
I mean, fuck, I've only been in this industry since 2011, and that's still long enough for me to recall the "rise" of half a dozen code editors (SublimeText! Atom! Intellij! VisualStudioCode!). I imagine most people don't like re-learning their entire workflow every couple of years, and just want to get back to coding.
Vim is not an editor. It's a language. A text-editing language.
When I'm editing, I'm thinking things like:
- change these 2 words: "c2w"
- remove everything in these parentheses: "di)"
- delete this line: "dd"
- where is this declared: "gd" (this is a custom CoC.vim mapping)
Any editor implementing that language would probably see very good adoption in Vim user circles (e.g nvim).