The ways in which we interact with computers has changed dramatically over the decades. From flipping switches on the control panels of room-sized computers, to punching holes into cards, to ultimately the most common ways that we interact with computers today, in the form of keyboards, mice and touch screens. The latter two especially were developed as a way to interact with graphical user interfaces (GUI) in an intuitive way, but keyboards remain the only reasonable way to quickly enter large amounts of text, which raises many ergonomic questions about how to interact with the rest of the user interface, whether this is a command line or a GUI.
For text editors, perhaps the most divisive feature is that of modal versus non-modal interaction. This one point alone underlies most of the Great Editor War that has raged since time immemorial. Practically, this is mostly about highly opiniated people arguing about whether they like Emacs or vi (or Vim) better. Since in August of 2023 we said our final farewell to the creator of Vim – Bram Moolenaar – this might be a good point to put down the torches and pitchforks and take a sober look at why Vim really is the logical choice for fast, ergonomic coding and editing.
First, There Was Vi
Text editors weren’t originally really much of a thing when it came to home computers, with the need to edit text and configuration files the most pressing on larger UNIX systems. This was the world in which the vi editor (short for ‘visual’) saw the light in 1976, when Bill Joy created it as a visual mode for the ex line editor that worked better on a teleprinter. Bill Joy did admit to being strongly inspired by the modal Bravo editor, which was created at Xerox PARC in 1974 for the Alto Executive operating system.
As the standard editor in BSD Unix distributions and part of the Single UNIX Specification, vi became well-known and despite it being proprietary software, demand grew for a version that would work on home computers. This turned out to be Stevie (ST Editor for Vi Enthusiasts), originally written by Tim Thompson for the Atari ST in 1987, but later ported by Tony Andrews to UNIX, OS/2 and Amiga in 1988. It was this Amiga port that Bram Moolenaar – as an Amiga user – would pick in 1991 as the basis for what would become Vim.
Initially ‘Vim’ stood for ‘Vi IMitation’, but after the project picked up speed and gained many new features that made it much more than ‘just vi’, it became ‘Vi IMproved’, or ‘Vim’ for short. Even though Bill Joy had by then joined the Dark Side with his entry in the Church of Emacs, this did not mean that the mode-based editing approach first coined with the Bravo editor at Xerox PARC was now on the ropes. Instead Vim is still the editor you’ll usually find installed by default on Unix, BSDs, Linux distributions and others, whether in its vi-compatibility configuration or full Vim glory.
Strain Modifier
Vim is the canonical mode-based editor. Perhaps the most straightforward way to describe the difference between mode-less and mode-based text editors is in the way that modifier keys are used. If you want to perform commands with a mode-less editor, you have to use the Alt, Ctrl, Shift, Meta, or Cmd and some of the alphanumeric keys simultaneously to form the key combination that triggers the desired command. Depending on the number of these commands are configured this can mean simultaneously hitting a mere two keys all the way up to five or more in some kind of claw-like death grip. In the case of Emacs the common issue with a sore finger is referred to as an ‘Emacs pinky‘ from overextension to the Ctrl key.
With a mode-based editor, you hit the configured key (like ‘Esc’) to leave the Insert Mode and enter Command Mode where you type out the string with the command. From a repetitive strain injury (RSI) point of view, it ought to be somewhat obvious that the latter approach puts less stress on one’s hands and wrists as they can remain mostly on the home row, rather than having to contort continuously to reach for modifier keys to form uncomfortable combinations, or even shift your position for that bane of ergonomics: the mouse.
Beyond the inevitability of accessing the Shift key now and then in order to capitalize a letter here and there, or to hit Caps Lock for that bit of SQL syntax, your hands should remain on the home row when using a mode-based editor like Vim, with your weak pinky rarely having to exert a trembling reach all the way over to the Alt and Ctrl keys. When you are done typing in whatever text had to be typed in Insert Mode, you move your left hand slightly over to hit the Esc key to enter Command Mode, which is also a nice change of position that allows for stretching your hands some.
Vim As IDE
Although Vim started as a text editor, it has over the decades collected many features which are generally associated with integrated development environments (IDEs). This include syntax highlighting, code folding, integration with toolchains and a robust extension ecosystem that allows a user to turn a basic Vim installation into an IDE for whatever target language and environment they need.
In order to get started with configuring Vim as an IDE, you only have to follow one of the countless tutorials you can find all around the internet, owing to just how many people use Vim exactly for this purpose. Some mention trying out countless other IDEs and editors, only to come back to Vim. One thing that is highly attractive here is how transparent and configurable it is. You can quickly check and configure settings in the plain text configuration file, and share these settings with others, or simply back up your entire Vim configuration, which is very convenient when switching between systems.
Finding additional plugins for Vim can be a bit of a chore if you’re looking for something specific, but the official scripts database on the Vim site, as well as as sites like Vim Awesome can help with sifting through what’s available. There are also plenty of recommendations by Vim users on which plugins they figure are the best for developers and sysadmins. Although perhaps not as glitzy and user-friendly as something like Visual Studio Code, Vim will happily run on the command line, even inside a screen session via SSH on a remote server, without requiring a gigabyte of RAM and lugging a browser-sized attack surface along with it.
:wq
For the average computer user, vi and Vim, Emacs and mode-based editors are something that they will likely never come across in their daily, Windows and MacOS-based experience. To them these sound and look like tools used by hackers, as they sit in darkened rooms in front of multiple screens with text busily scrolling past in terminals. Yet when the Editor War first began to pick up speed, that was basically all that computing was like, whether in DOS, CP/M, UNIX, or the various BASIC runtimes including that of the pre-MacIntosh Macs.
In that era nobody was quite certain what the best way to create a user interface was, with even the GUIs of Windows 1 through 3.xx looking quite bizarre to today’s generations. These days we have more or less settled on a few standard ways of interacting with computers, but as the ongoing strife between the Church of Emacs and the Enlightened of Vim shows, nothing is ever fully settled, even as both sides bring their best arguments to bear.
Regardless of what the future of computing will look like, we all owe Bram Moolenaar a thanks for his role in giving us Vim, and kickstarting the community around it.
Before the PC, and IBM keyboards, the Ctrl key was where the caps lock key is.
Pinky strain want a problem.
(I had a co worker who remapped the Ctrl key to the caps lock key, no one else could use his keyboard, too much muscle memory)
On the ADM-3, escape was just above ctrl, where tab is on most modern layouts.
https://en.wikipedia.org/wiki/ADM-3A#/media/File:KB_Terminal_ADM3A.svg
Similar to your coworker, all my machines have caps swapped with escape. Lots of vimmers make that swap. Maybe the one thing vim and emacs users can agree on is that caps lock is completely useless.
In high school, I modified my Casio fx-180p pocket calculator so that the layout on the top two rows were 01234 and 56789. The other buttons were evenly distributed along the bottom two rows. Noone ever asked me more than once to borrow my calculator when they had forgotten theirs at home. :-D
Vim also supports Alt+ while in edit mode, which will switch to normal mode and execute without forcing you to reach for the Escape key.
None of the IDE vim modes seem to support it though, for obvious reasons.
VI over Emacs? No way!
Way back in 97 when I installed Linux for the first time it was necessary to tweak all sorts of config files and even pick a temporary kernel that got you just enough functionality to download and build a better one that supported all your hardware. All that just before booting off the HD (as opposed to the very minimal install floppy).
Anyway, I had no experienced user to go to for help and those floppy installer environments were REALLY bare with no manpages and some ancient terminal. Long story short.. backspace didn’t work. But they did have vi and emacs.
So.. at first following directions that assumed one would use vi I managed to figure out that C-b would move back a space and then del would delete the character. But it wasn’t something that stuck in my memory, not along with ‘i’ for insert mode, C-w and C-q. That all seemed pretty dumb when I discovered that backspace magically just worked in emacs and I could get a menu with F10.
And that was it. Eventually I learned Emacs key sequences and lost dependence on the menu. I never suffered from any finger pain, not from using emacs anyway. Swiping on my phone… now that aggravates my thumb but emacs sequences are fine. After taking the effort to learn my way around one complex editor.. why invest the time in another?
Plus I enjoy having IRC in one frame while coding in another. I don’t care that it’s not the ‘Unix Way’. I enjoy it.
heh in the 1990s, i didn’t have the disk space *or* RAM for emacs :)
i definitely appreciated when the install disks and recovery disks i used started coming with simple modeless editors. i don’t even really know what they were called, i know every time i use one it seems like it’s a different editor. but it’s always basically at heart pico, with visual editing, arrow keys, modeless, something like ^X to save-and-quit, and a cheat sheet along the bottom row of the screen.
i eventually learned nvi, and haven’t looked back…but i am *still* dismayed when i wind up on a boot disk or pseudo-embedded environment using some pidgin vi like the one that ships with busybox. it’s got all the disorientation of vi for new users and on top of that it doesn’t support any of the vi features i actually like.
It’s not really an issue today, but anyone who has had to perform sysadmin work with other Unix variants over the past few decades would have chosen vi for that same reason. Every variant I ever saw had vi installed by default, albeit often a rather stripped-down version. None had emacs by default – if that behemoth was even available for the variant in question. (And don’t forget that nominal availability didn’t always mean that you could practically get hold of the install media).
Today, we are in a very different place. Linux is the unix-like OS of choice everywhere, and sane sysadmins today use DevOps techniques reducing to the absolute minimum the amount of on-server command line interaction. The editing now is done on the workstation, where personal preference can take precedence.
I used vi back in the day when I had to. Forgot a lot of it now. And I am talking back in the day of Ultrix, SCO, AIX (Ain’t Unix), etc. But I used emacs when I could
A bit earlier than you, but I went the opposite direction for similar reasons, I found what worked and that shaped what I was initially able to learn more about.
Are you sure about Vim being the default editor? Seems on Debian based distros the default editor is nano, and I have to install Vim. I intensely dislike nano.
Well it is the standard in BSD not gnu/linux or gnu/hurd in other words Debian is not BSD, but some sort of vi (usually vim) is still available.
on BSDs it is more likely to be an a more minimal vi like nvi or ovi
The vim-tiny package should be installed on all debian systems by default. It’s basically vim in vi mode, and as such you invoke it with “vi”. If you want real vim you have to install that separately. Tiny-vim is also used for visudo.
We can all agree we don’t like nano, at least! :)
man… I know I’m usually the weird one in a group, but Nano is all I use ever since I was first introduced to it for basic file editing; it works and isn’t cluttered with features that I probably won’t use.
vim-tiny is installed by default in the debian base installation, even when installing from netinst, with no tasks selected. It’s vim compiled with a minimal subset of features, solely to provide the vi binary for the base debian installation.
While it’s not quite up to being used for full ide work (no syntax highlighting or syntactic formatting), it’s more than enough for most remote sysadmin work. And, unlike classical vi, it retains vim’s ability to handle arbitrarily large files (and arbitrarily large lines).
The default used to be ed. But maybe that was before linux.
VIM is particularly efficient if you can touch type and know a reasonable number of navigation commands. I have many times sat frustratedly watching someone editing source code in notepad++ or VisualStudio or Eclipse knowing that what I had to sit and watch for 10+ minutes, I could have bashed out in under one minute (appropriately usually within a bash terminal!)
Heh, I’ve watched someone doing regex searches or replacements and diffing files in the terminal when I’d have been able to do it faster in notepad++ without having to squint and go line by line through pages and pages of undelineated monochrome text. I think a good gui plus keyboard shortcuts can be operated at essentially the same speed as if you typed out a series of commands as fast as humanly reasonable, except it can give you more visual feedback and may make it less awkward to express certain sequences of actions. At the cost of not being directly convertible into a script, of course, and with the caveat that some actions are very straightforward in the terminal exactly because they’re expected to be done there, sometimes by scripts.
That’s basically what the Apple usability studies showed back in the day. The interesting bit was that people who used CLI rated themselves as being more efficient, because they were judging the amount of work accomplished by the amount of effort they were putting into it.
ed is the standard text editor on Unix systems:
https://www.gnu.org/fun/jokes/ed-msg.en.html
For terminal-based editing, I will stick to Midnight Commander’s mcedit for the foreseeable future. I can never remember enough commands to use vim; not sure if I ever tried emacs. The nice mcedit TUI provides the easy exploration of a GUI, while still working over SSH or serial.
Yes, l am an ex- Windows user, still overly dependent on GUIs.
I use vi or vim ONLY when I will be staring at the screen diligently, such as when modifying configuration files. Vi’s modality has cost me too much, too many times. Typically, I will be touch-typing, copying text from a paper document or a different computer, and by the time I look back at the vi screen to discover that I wasn’t in insert mode, it has done damage I have no hope of fixing. Too many times.
I THOUGHT I had found something in gedit, because I had versions that ran in Linux, MacOS, and Windows, but MacOS’s zeal for obliterating all things 32-bit put an end to that.
That strange, you touch-type but don’t look at your editor back&forth? Or even look that you are well set up before typing ?
Otherwise, just put “startinsert” in your vimrc and even remap ESCkey to avoid to go back by old-muscle-memory to ‘normal’ mode, create a mapping for pasting in insert mode etc, etc…
personally, I have a very good typing speed but I do check before starting to type or after pasting something be it in vim or other wyswyg UI.
RIP Bram!
i don’t get it…if you don’t like vi, just don’t use it ever? the worst thing would be to sometimes use vi and sometimes use a modeless editor. switching back and forth would definitely give me the kind of keyboard confusion where i’d be typing text into command mode :)
vim has an undo stack. next time you paste in command mode, just hit ‘u’ until you get back to before you pasted.
Yeah, I know. Not that simple, knowing how much to undo.
use this plugin then: https://github.com/mbbill/undotree
but really, just give an eye check to what you are typing :)
uu not being undo-redo disqualifies vim from being a vi
Yes indeed, vim has an undo **stack**. vi has only one level of undo.
Thanks Bram (and rest in peace)
Moving the control key to caps lock is only a partial solution for emacs pinky. The full solution is to move the crtl and alt keys inwards into the excess space used by the space key. Then you can access the ctrl and alt keys with your thumbs. Your thumbs happen to be among your strongest, most agile and most independent fingers which makes them perfect for modifiers. You can try it on a lot of laptops with the right alt and ctrl and left alt often shifted inwards to make space for the arrow keys and fn key.
This is why I especially like split keyboards with multiple buttons for the thumbs (e.g. Kinesis and Ergodox, among others).
My left thumb can Backspace, Delete, Ctrl, Alt, Home and End, my right thumb can Space, Enter, Ctrl, Win/Meta, Page Up and Page Down. On my Ergodox I have three layers defined, basically it’s another kind of modal interface, but one that doesn’t depend on application or OS support.
It takes a few weeks to get typing speed up to where it was on standard non-split keyboards (partly because these are also ortholinear) but my pinkies don’t suffer near as much now. Also I’m a vim user.
If you’re writing enough code that you need to optimize your text editor, then you’re writing too much code. If all programmers were strictly required to use only notepad, we’d probably have much less software bloat.
i disagree. i started on an anecdote but i’m gonna go back to first principles instead….code always has defects from its history (“bloat”)…and i’ve found as i get older that the way i fix it up is i iteratively re-factor. i make sequential tiny changes that i can be confident are correct, and after dozens of them in a chain, i’ve accomplished a major rewrite. i find it a liberating alternative to my naive original approach (just rewrite everything) and my more conservative reaction to the flaws of that approach (accept that you can’t really change anything because the problem is too big to rewrite it without breaking it). so for example, if there are 100 copies of an idiom, i visit all 100 of them and make one transformation (or inspection) at a time to simplify it until they’re all uniform enough to replace all of them with just a function call.
but it is a very typing-intensive way to interact with code. in the early stages of it, i am making rote edits at 100 different sites. but at the end of it, i might have deleted 1000+ lines of code. i definitely benefit from “:map e c3lABC^V^[lldf)$n” sort of aids in vi. and at every point i am really making good use of the search function (and/or grep) to try to characterize the different sites. there’s no time when you need an efficient interface more than when you’re working with something that has already bloated.
fwiw this is exactly the kind of work i simply can’t do on a phone thumb keyboard. i’m actually pretty comfortable writing new code on one of those things though.
p.s., talk about your write-only scripting languages! :)
Tip from an embedded C/C++ coder with 15 years of experience: doesn’t matter if you’re working for big corporations or little startups – no one cares if you refactor code. Instead of fixing someone else’s botch job you could read a book, watch funny cat videos or get a cup of tea. It’s still 8 hours but you don’t burn your body with unneeded stress.
(Doesn’t apply if you’re self-employed and working on your own stuff.)
hahah yeah but it depends on your environment, how much benefit you’ll personally get out of cleaning up the code
> fwiw this is exactly the kind of work i simply can’t do on a phone thumb keyboard. i’m actually pretty comfortable writing new code on one of those things though.
You’re a stronger man than I. I’ve tried on numerous occasions to use my phone keyboard, both with and without using Neovim as the editor, to write code on a phone, and the few times I haven’t simply given up in frustration I’ve spent half an hour coding something that would take me five minutes on a physical keyboard. I even downloaded an alternative onscreen keyboard app to make using Vim keybindings less painful, but to no avail.
Nah, that’s not the point. The point is that you want the interface between you and the text to be as low friction as possible. That’s what vim really excels at.
Speaking as someone who found vim and never went back, vim simply fits the way I think.
However, I’ve worked with all kinds of people, and there’s no such thing as a silver bullet. You need tools that work the way _you_ work, and not everyone thinks in a modal fashion.
Most of the people I know who religiously use vim were people who already think that way, and simply finally found a tool that fit their minds.
As such, I’ve taken to introducing newbies to vim, with enough exposure for it to be no longer new to them. From there, if that’s how they think, they’ll embrace it on their own. If they don’t, no amount of forcing it will ever make it work well for them.
And this seems to be true of other powerful editors. A poor impedance match between the mind and the tool creates heat and resistance. With power tools, the effects of the mismatch are simply more troublesome.
nethack — The answer to getting everyone in the group up to speed on vi(m).
:-)
This actually does work fairly well :)
And it serves as a pretty good filter, too. I have found that most people who don’t find nethack fun are also not attracted by any of the classical unix workflows or tools, anyway. It’s hard to grok something you don’t find fun enough to voluntarily spend time on.
Different horses for different courses, but throwing someone at a classical unix for a while has been a reliable way to filter out the mules I can’t use for my tasks.
This is a silly troll comment that makes little if any sense. Writing code is what I do. Saying I am writing too much code is like saying a major league football player is playing too much football. The statement doesn’t even make sense.
I think you mean the National Football Association.
A surprising number of people only write code to get paid. As such, they steer away from any solution that requires them to do more of it without getting more dollars.
When I try to convince them that a good way of polishing skills is by doing more work that uses those skills, and that this improves their value and earnings, they tend to get offended. Apparently it’s “not fair” that they have coworkers who have no life and who get paid for doing what they’d do for fun anyway. I’d invite them to join the dark side with the rest of us, but they always leave after a few months, so that would just be a waste of cookies :)
I have been using Emacs since, maybe, 1980. Give or take a year. I don’t remember when I first got access to the VT100’s rather than the Decwriters and ASR33’s. I’ve used vi and vim, and really don’t like the modality.
Then again, I on;y moved to TeX and LaTeX from the assorted Roff’s after y2K….
I first started using emacs in 1984 (cue Big Brother videos). Never got carpal tunnel syndrome.
Modal editors require you to remember what mode you are in! Oh, I thought I was typing code and just deleted it instead. My bad.
Like TECO, back on the DecSystem10. Oh, t (type the current line) and y (yank the next buffer into memory and OVERWRITE what was there) are right next to each other on the keyboard! The big question was, what would your name do as a TECO command?
Without modes, I know exactly what will happen when I type. With modes, I have to be sure what mode I am in.
It says “Insert” at the bottom of the screen when you switch modes though…
Technically, that’s a vim feature, and only shows up in nocompatible mode if configured.
The default configuration on most modern installs does usually do this, though.
I started with Emacs in the late 70’s was a on a weird DEC system that might have had TECO on it and had a terminal where you had to know your ASCII (^H,^I, ^J, ^L, ^M, etc.) as the keyboard didn’t have return, enter, backspace, tab, etc. Anyways I learned Emacs at the same time. Later I used an Atari Macro Assembler and the keystrokes were mostly the same, then gnu Emacs on OS9/68K and later Unix systems. I did need to learn vi for Unix but never really used it in depth. It was great for access to remotes over dialup as I could escape out of input mode and not worry about file corruption. I still use Emacs (and org-mode), I even have it on my work Windows machine.
I use nano when I don’t want to teach my coworkers complex commands. But when I need to get work done or when I need to do a demo.
Yeah, but Teco was modal like vi, and no control characters were used. It was a meme-like-thing at the time to see whose name, when typed into Teco, would have the most destructive power.
There is also Kakoune and Helix.
They use modal editing but it works very differently to Vim… verb follows motion so you always see what you are changing!
I tried Vim or Vim-like navigation/editing many times and consider it highly unpractical whreas trying Helix was like stepping into a fairytale.
Moreover Helix people have nothing against getting a proper GUI in the future. (I personaly think that limiting yourself to asciiart is just that.. art and deviation of nostalgic old farts).
For me, one advantage of vim is that my local work environment is simply ssh. A graphical environment doesn’t have that benefit, and few graphical environments provide usable results when working over very high latency links. Add in low bandwidths, as some of my environments require, and it might take hours to transfer the file locally before editing it, versus a couple of minutes to change the file in situ.
Although, to be honest, in the REALLY-constrained environments, it’s much faster to use ex than vi(m)… and vim’s ex mode is pretty broken. Fortunately, nvi and vim will coexist, and nvi’s ex mode works without causing brain spasms even over 300 baud links at 1500 ms round trip delay.
I have a deep dislike for both VIM and Emacs. In the console I use nano, in the GUI either SciTE (the reference implementation of the scintilla syntax highlighting library, what makes notepad++ do purdy colours) or kate, whatever my mind feels like.
The biggest reason to use neovim for me is not modal editing (for that, I could probably get by with vim mode in another editor) but extensibility. In a couple of lines of lua, I can do almost anything. Translate a comment using a local translation engine, look up the DOI under my cursor and insert the corresponding biblatex block using doi2bib, etc. TJDeVries, a core maintainer of neovim, coined the term PDE, Personalized Development Environment. It’s powerful because it’s yours.
In this video, he shows how to listen for the save event, run your code, and put the output into another buffer in like 20 lines of lua.
https://www.youtube.com/watch?v=9gUatBHuXE0
i learnt vi because it was reliably available on the different unices i had to work across in the 90s and still use it today without ever really bothering with all the vim extras. Modal editting seems pretty natural if you spend a lot of time in spreadsheets, which is where non-hackers will more commonly encounter the modal approach.
“I’ve been using Vim for about 2 years now, mostly because I can’t figure out how to exit it.” – I Am Devloper
shift-ctrl-F2 and killall -9 vim. Obviously.
Actually had to do that (the second part, possibly grep’ing the pid and specifically killing it) due to a lack of ECC on serial modem lines in the late 90’s where someone had cheaped out and used the absolute bare minimum in cabling. Kept getting vi sessions on SCO taken out by line noise.
Your comments on serial cabling don’t compute. Adding more bits on a serial line is done serially, still using one wire. Error correction would be handled by protocols, not more wires. Maybe you meant lack of shielding? Though that only helps a certain type of interference.
:!sudo killall -9 vim
(cue screaming)
:P
I have been using vi since edition 7 unix on the Interdata 8/32 where I first discovered it. At this point it is part of my being and changing to another editor is just out of the question. Is emacs better, would I be more productive using it? Would it be worth the time finding out? I don’t think so. Maybe I am missing out.
Vi (vim of course these days) has certainly stood the test of time. That says something. What I should do is to spend some time learning some of the cool things vim makes available. Syntax highlighting is worth its weight in gold and catches all kinds of typos and mistakes — very handy — but that is just the tip of the iceberg. I have been delighted that Android Studio for example has a nice vim plugin that lets my deeply ingrained vim muscle memory (or whatever it is) work for me. I don’t need to think — things I want to happen just happen. I suppose that is how it is with musicians — they think music and their fingers do magic and music happens.
You know, back then, there was no emacs. Having any kind of “screen editor” was like a miracle of sorts if you were used to using ed or ex for things (or “SOS” on DEC Tops-10 machines). We used to think that SOS was wonderful (and it was). So I never have been faced with the opportunity of choosing between things like vim, emacs, and nano. So I just keep using vim and am pretty happy once all is said and done. I don’t want my editor to be a religion or a programming language.
I admit to laziness is not learning more than perhaps 20 percent of what vim can do (that being my estimate of the basic vi content of the current vim). I don’t want new tricks (like a dog learning to walk on two legs), but learning things that are actually useful in day to day productivity would be nice)
As far as “my editor can beat up your editor” sort of battles, I am reminded of some story from old west days of a young kid challenging some gunfighter with a reputation with “I’m faster than you”. The old gunfighter shrugs and says, “yeah, I suppose you are” and refuses to take the bait.
Spacemacs: The best editor is neither Emacs nor Vim, it’s Emacs and Vim! (Spacemacs.org)
Well, “best” is subjective. And for most of my usages, “best” requires the ability to function over long, high-latency tty-only links without requiring disk, memory, or io resources on the remote end. In some of those cases, actual vim(even the tiny version) is a bit too heavy (and has had most of its low-baud serial optimizations stripped out).
But, insisting that _my_ “best” should be _everybody’s_ “best” would be about as stupid as insisting that _everything_ must taste like coffee :)
A few years ago someone suggested using vim without plugins. I tried it for a bit and carried on with the practise of not using plugins. I do have a small .vimrc file though. It makes setting up for new machines much easier, of course. I tend to hop around machines a lot.
My conclusion is that plugin-less is the way to go. Vim is not emacs. Do things the vim way, not your way. You don’t need those plugins!