I'm a lot faster on it than anything else... I especially dislike those editors that show all of the commands on the screen. I'm not using it as an ide (although I worked with someone that did and his code sucked). I'm just logging in by ssh, editing a configuration file, and logging out.
I've used vim instead of vi for decades and haven't seen an issue with speed.
I went into the article expecting some nonsense about how I should be using vscode or whatever, but this was just about how having vim as the default editor is far better than having vi.
Vi is primitive and clunky not because it's a bad design, but because it's from 1976 and computers have changed a lot since then. It dates from a pivotal point: when glass terminals had replaced teletypes.
Glass terminal means with a screen, so any point on the screen could be changed at any time. Screen means a CRT, and that means specifically text-only and single-colour.
But before microcomputers, before a mass market in software that individual people could get and use on their own computers. Vi was from the end of the era of computers that cost as much as a house and so which you had to share.
So, terminals with screens were becoming common enough that an editor designed for them caught on.
But it was before microcomputers, where the computer was so closely coupled with the screen and keyboard that soon they were built into the same casing.
Screen + keyboard + computer in one unit == Commodore PET.
Keyboard + computer in 1 = Apple II
Keyboard, screen, and computer all sold together: TSR-80
All 1977, the year after vi appeared.
Computers with their own keyboards, or in their own keyboards, led to keyboards designed alongside the computer's OS.
Before then terminals were printers with typewriters: instead of just printing, the keyboard sent codes to the computer, and the computer sent them to the printer. Replace printer with screen, this still happened.
A mass market in software for individuals led to UI conventions and keyboard improvements.
Typewriters only have Shift and Tab. But as glass terminals went mainstream, then microcomputers which came with their own dedicated keyboards, they sprouted lots more keys.
Vi is from the early stage: it expects "Esc" and there's a combo for that.
What came right after it was Ctrl and Alt... and at first they went a bit crazy and there was Meta and Hyper and so on too.
To this day, the meaning of "meta" has not been agreed. Emacs and relatives mean one thing, KDE and relatives mean a different key.
Along with these keys, and a way to represent them as bits in a byte, nicknamed after a very young Niklaus Wirth -- "Bucky bits".
(I am guessing this is from him having European teeth not as even and straight as American kids who if they were from families rich enough to send them to university, all had braces.)
Along with all those keys came arrow keys and forwards and backwards delete keys, and rows of F-keys.
And it shows because vi doesn't use all this. It uses letters and Ctrl and nothing much else.
Once all the keys were they, software started to use them. Result, a Cambrian explosion in UI diversity. That's the era Emacs is from.
Then, next, came a great extinction event, as most of the dozens of weird 1980s computer makers went broke, and the industry standardised on CP/M replaced by MS-DOS, and PC clones, plus off to one side a few makers of GUI computers: Apple, Atari with the ST, Commodore with the Amiga, Acorn with the Archimedes.
And a matching great extinction event in UI design, as IBM-lauout keyboard became the standard and GUIs standardised software UI. DOS standardised UIs on CUA as it fought to stop Windows taking over.
It failed. Windows uses CUA. GUIs and CUA killed modal editors and weird UIs.
The Unix world stayed on minicomputers and their single-user descendants, workstations. It avoided all this standardisation. Keyboards stayed weird, UIs remained chaotic.
That's why vi is still weird, and so is Emacs in totally different ways.
The sad thing is this:
Those standardised UI are good ones backed by millions in R&D spend. They are better UIs than vi -- any vi.
Vi users like the rich keyboard controls, and won't move. But CUA editors have equally rich keyboard UI and if you know it you can drive all GUI apps with the same UI. This is massively useful. You can drive the whole OS and all its apps at the speed and control and power of a Vim user who's been practising for a decade.
And it hasn't gone away because this is also the UI that all blind and visually-impaired users use, and those with serious motor coordination problems.
But the Linux shell came straight out of minicomputers and workstations and never got standardised like this.
I've been mostly using emacs past 30 years ie. about the time when system memory wasn't any more constraint which while single user was about 8MB at least. But I did earn my living before that about 7 years mostly using vi as most usable editor in the system and that 8MB was luxury most of that time.
But even emacs IMHO was and is vastly superior, vi still had it niche fast small edits and especially before log based transactional filesystems. After power outage or bad brownout event system crash there was great chance you got to fixing filesystem with fsck (which did often take lot of time) and worst cases finally debugfs trying to fiddle bits that you get fsck fixing rest.
Bringing system up with old system could be tedious. Before you get system enough up single user mode and just root fs mounted you had to resort you way forward using those modest tools you had there. It was really great if vi did work, but it too required sometimes more memory than you had before swap was active. If not, then ed was your friend, ex is just vi without visual mode.
For a long time vi was also able to edit very large files. It did not require reading whole file in memory before it allowed editing as for example emacs did (or mmap's it memory later).
These days I use vi for quick edits like someone above mentioned and like it more than any later replacement (nano etc) if emacs is not there, not worth installing it for just quick change or when can't install on (embedded) or someone else's system for any reason.
Vi is often available also *bsd based appliances which I've been using like Junos, Netscalers, etc.
IDE vim support suffers from three problems. First, performance. I have yet to try an IDE that can match the responsiveness of vim. You can obviously tank vim’s performance with plugins, but you don’t have to. Second: clutter. Modern displays are gigantic, and yet most IDE users don’t have more than 40 lines of code on the screen at a time. The rest is occupied by a file picker, command palette, integrated terminal, LLM chat interface, and so forth. You have to go to some effort to reclaim those pixels; big context is not yours by default. Third: uncanny valley effect. Vim implementation is usually incomplete, especially when it comes to ex-style colon-prefixed commands. It’s jarring to run into a spot where your muscle memory doesn’t work.
In short, IDE vim support does not measure up to the experience of using the real thing.
vi is not available on modern systems, people are using clones like (neo)vim or Emacs with evil-mode. And those clones also have modern features too, pushing them to IDE-level of tooling. Proper IDEs are often still a tad superior in being an IDE, but their vi(m)-modes are very lacking in comparison. So at the end it comes down to where you set your focus, and often the vim-side wins over the IDE-side.
They are not meant to be modal, they do not implement Vim meaningfully, they just map a few keybinds. Extremely few have ever tackled trying to implement Ex.
Trying to map vim onto an IDE misses the point, as you'd want to remove most of the IDE getting in the way of actually sitting down and programming and getting shit done.
Thanks for the advice, but I predominantly use vi on remote systems for rudimentary config editing. It is perfect for this, as is tiny, present out of the box on many distros, and I do not need to switch my brain between nano and vim navigation.
I think it would be helpful if the article had outlined the cases when users do get classic vi. I mean, for me vi is a pretty new thing (I began with ed), but I don't use systems that have code written by Bill Joy. They're all running vim which is what the OS gives me. Is this a BSD thing?
OK cool, should I switch to nano? I need to be able to ssh into an arbitrary machine of whatever distro started by someone else, on another continent and edit a config file before restarting a service that is currently shedding millions of connections a minute.
Or further, I don't know about other distros, but Arch doesn't even package vi (in the main repos) - it's a package group (or some implementation I'm not sure off the top of my head) consisting of vim and vi-compat.
I was honestly embarrassed to admit that I have no idea what I've been using on my Ubuntu server for the last 10 years. The way to find out if I'm using vi or vim is to enter command mode (by pressing “:”) and run “version” I'm using vim ;)
I'm struggling to think of the last time I saw a commercial unix -- we still had solaris on some new machines until about 2006 - the last I remember was the x4500 with ZFS.
Our sun sysadmin contractor (whose full time job it was to look after about 10 solaris machines) was a big fan of ksh at the time.
I used a Sun workstation as late as 2008, but by that time it was ancient and kept around only for the expensive engineering software that wouldn’t run anywhere else. Even at the time, using CDE felt like a blast from the past. I didn’t dig too deep because I wasn’t using it for long, but I’m pretty sure the vi was original.
Unironically yes, switch to nano. It is an excellent and vastly underestimated editor.
(though admittedly, with a somewhat unfortunate default config, at least for modern environments)
It has been my editor of choice over vim for many years now, and I'm super productive on it (though at this point, partly this stems from me having developed my own set of custom macros and helper utilities over the years).
> Hot take: basic vim (without plugins) is mostly what vi should have been in the first place, and much of the differences between vi and vim are improvements.
i've been using nano for server stuff since ever. i could never understand why anyone would us vi/m with its bs shortcuts, making BASIC text editing into a complete **.
Speed (both in the CPU/memory usage and in speed of editing using advanced commands), backwards compatibility with older servers, ubiquity (guaranteed it is on every server you touch), insane feature count vs Nano, and my fingers mostly stay on the home row.
Its major downfall is the commands are hardly intuitive, but I forced myself to learn it by doing everything in Vim (including shopping lists) and it now feels comfortable.
Then you have situations where you have no choice. I work for a company with over 100,000 servers and they only install Vim and disallow us installing anything else.
Not that we would have time; we’re in and out of each server in five minutes then on to the next ticket.
I won't deny that vim has an "insane" feature count (particularly with plugins), but people who claim this kind of comparison typically vastly underestimate nano's own feature count and flexibility / extensibility.
And I'm surprised this usually comes as a surprise to people, given nano provides the ability for both internal (i.e. macros) and external scripts to manipulate its buffer. In principle you could even run non-interactive vim commands through nano if you really wanted to.
I can see both having a place: vi/vim for more elaborate features and editing capabilities, and nano for the quick "I need to change that one little thing in my config file" fix. I prefer nano over vi every time, but I barely work over ssh more than once a month. There is simply no need for me to know more about vi/vim.
It doesn't hurt to know some basic vi/vim commands though, as you will mostly encounter them pre-installed on even the most exotic distribution.
> i could never understand why anyone would us vi/m with its bs shortcuts, making BASIC text editing into a complete *.
I could never understand why anyone would use nano with its bs shortcuts, making basic text editing (in contrast to basic linear text writing, which even a non-modal editor like nano can do decently) into a complete *.
This is dumb. Sure, some people don't get modal editing. Others don't get how you could live without. It is almost as if people work differently and have different preferences.
Emacs is a bit special in that the "canonical" way of editing a remote configuration file with it is probably using TRAMP, i.e. connecting your local emacs via ssh to edit the remote file as if it was local.
Vim is the exception, not the rule. Most people don't want a mental model just to type a sentence. Instead of the snark, you could just admit that your preference doesn't align with the median user.
> Most people don't want a mental model just to type a sentence.
"Just typing a sentence" is what I was referring to with "basic linear text writing", for which modal editing indeed does not bring much of a benefit. That's not text editing though.
> Instead of the snark, you could just admit that your preference doesn't align with the median user.
? I explicitly wrote that people work differently and have different preferences. What was snarky about that?
Besides, the median user does not edit configuration files via ssh, so they are hardly relevant here. The median user does not even know what a terminal is. If this was about the median user, then we would be discussing Word vs. Notepad, or whatever.
I'm a lot faster on it than anything else... I especially dislike those editors that show all of the commands on the screen. I'm not using it as an ide (although I worked with someone that did and his code sucked). I'm just logging in by ssh, editing a configuration file, and logging out.
What's the link between your ex-coworkers bad code and VI again?
I've used vim instead of vi for decades and haven't seen an issue with speed.
I went into the article expecting some nonsense about how I should be using vscode or whatever, but this was just about how having vim as the default editor is far better than having vi.
As my beard greys, I find that a reasonable take.
have you tried vim or neovim?
Vi is primitive and clunky not because it's a bad design, but because it's from 1976 and computers have changed a lot since then. It dates from a pivotal point: when glass terminals had replaced teletypes.
Glass terminal means with a screen, so any point on the screen could be changed at any time. Screen means a CRT, and that means specifically text-only and single-colour.
But before microcomputers, before a mass market in software that individual people could get and use on their own computers. Vi was from the end of the era of computers that cost as much as a house and so which you had to share.
So, terminals with screens were becoming common enough that an editor designed for them caught on.
But it was before microcomputers, where the computer was so closely coupled with the screen and keyboard that soon they were built into the same casing.
Screen + keyboard + computer in one unit == Commodore PET.
Keyboard + computer in 1 = Apple II
Keyboard, screen, and computer all sold together: TSR-80
All 1977, the year after vi appeared.
Computers with their own keyboards, or in their own keyboards, led to keyboards designed alongside the computer's OS.
Before then terminals were printers with typewriters: instead of just printing, the keyboard sent codes to the computer, and the computer sent them to the printer. Replace printer with screen, this still happened.
A mass market in software for individuals led to UI conventions and keyboard improvements.
Typewriters only have Shift and Tab. But as glass terminals went mainstream, then microcomputers which came with their own dedicated keyboards, they sprouted lots more keys.
Vi is from the early stage: it expects "Esc" and there's a combo for that.
What came right after it was Ctrl and Alt... and at first they went a bit crazy and there was Meta and Hyper and so on too.
To this day, the meaning of "meta" has not been agreed. Emacs and relatives mean one thing, KDE and relatives mean a different key.
Along with these keys, and a way to represent them as bits in a byte, nicknamed after a very young Niklaus Wirth -- "Bucky bits".
(I am guessing this is from him having European teeth not as even and straight as American kids who if they were from families rich enough to send them to university, all had braces.)
Along with all those keys came arrow keys and forwards and backwards delete keys, and rows of F-keys.
And it shows because vi doesn't use all this. It uses letters and Ctrl and nothing much else.
Once all the keys were they, software started to use them. Result, a Cambrian explosion in UI diversity. That's the era Emacs is from.
Then, next, came a great extinction event, as most of the dozens of weird 1980s computer makers went broke, and the industry standardised on CP/M replaced by MS-DOS, and PC clones, plus off to one side a few makers of GUI computers: Apple, Atari with the ST, Commodore with the Amiga, Acorn with the Archimedes.
And a matching great extinction event in UI design, as IBM-lauout keyboard became the standard and GUIs standardised software UI. DOS standardised UIs on CUA as it fought to stop Windows taking over.
It failed. Windows uses CUA. GUIs and CUA killed modal editors and weird UIs.
The Unix world stayed on minicomputers and their single-user descendants, workstations. It avoided all this standardisation. Keyboards stayed weird, UIs remained chaotic.
That's why vi is still weird, and so is Emacs in totally different ways.
The sad thing is this:
Those standardised UI are good ones backed by millions in R&D spend. They are better UIs than vi -- any vi.
Vi users like the rich keyboard controls, and won't move. But CUA editors have equally rich keyboard UI and if you know it you can drive all GUI apps with the same UI. This is massively useful. You can drive the whole OS and all its apps at the speed and control and power of a Vim user who's been practising for a decade.
And it hasn't gone away because this is also the UI that all blind and visually-impaired users use, and those with serious motor coordination problems.
But the Linux shell came straight out of minicomputers and workstations and never got standardised like this.
Do people really still program in vi when most IDEs have excellent Vim support?
Yes, I only open an IDE to run a debugger when needed. The vim support isn't exhaustive and it's jarring whenever a command doesn't work.
This is about Vi though and that's certainly more rare. For me that's only used over a rare ssh with vim not available but vi present
Well it depends, on still using.
I've been mostly using emacs past 30 years ie. about the time when system memory wasn't any more constraint which while single user was about 8MB at least. But I did earn my living before that about 7 years mostly using vi as most usable editor in the system and that 8MB was luxury most of that time.
But even emacs IMHO was and is vastly superior, vi still had it niche fast small edits and especially before log based transactional filesystems. After power outage or bad brownout event system crash there was great chance you got to fixing filesystem with fsck (which did often take lot of time) and worst cases finally debugfs trying to fiddle bits that you get fsck fixing rest.
Bringing system up with old system could be tedious. Before you get system enough up single user mode and just root fs mounted you had to resort you way forward using those modest tools you had there. It was really great if vi did work, but it too required sometimes more memory than you had before swap was active. If not, then ed was your friend, ex is just vi without visual mode.
For a long time vi was also able to edit very large files. It did not require reading whole file in memory before it allowed editing as for example emacs did (or mmap's it memory later).
These days I use vi for quick edits like someone above mentioned and like it more than any later replacement (nano etc) if emacs is not there, not worth installing it for just quick change or when can't install on (embedded) or someone else's system for any reason.
Vi is often available also *bsd based appliances which I've been using like Junos, Netscalers, etc.
IDE vim support suffers from three problems. First, performance. I have yet to try an IDE that can match the responsiveness of vim. You can obviously tank vim’s performance with plugins, but you don’t have to. Second: clutter. Modern displays are gigantic, and yet most IDE users don’t have more than 40 lines of code on the screen at a time. The rest is occupied by a file picker, command palette, integrated terminal, LLM chat interface, and so forth. You have to go to some effort to reclaim those pixels; big context is not yours by default. Third: uncanny valley effect. Vim implementation is usually incomplete, especially when it comes to ex-style colon-prefixed commands. It’s jarring to run into a spot where your muscle memory doesn’t work.
In short, IDE vim support does not measure up to the experience of using the real thing.
vi is not available on modern systems, people are using clones like (neo)vim or Emacs with evil-mode. And those clones also have modern features too, pushing them to IDE-level of tooling. Proper IDEs are often still a tad superior in being an IDE, but their vi(m)-modes are very lacking in comparison. So at the end it comes down to where you set your focus, and often the vim-side wins over the IDE-side.
IDEs do not have "excellent Vim support".
They are not meant to be modal, they do not implement Vim meaningfully, they just map a few keybinds. Extremely few have ever tackled trying to implement Ex.
Trying to map vim onto an IDE misses the point, as you'd want to remove most of the IDE getting in the way of actually sitting down and programming and getting shit done.
Thanks for the advice, but I predominantly use vi on remote systems for rudimentary config editing. It is perfect for this, as is tiny, present out of the box on many distros, and I do not need to switch my brain between nano and vim navigation.
I think it would be helpful if the article had outlined the cases when users do get classic vi. I mean, for me vi is a pretty new thing (I began with ed), but I don't use systems that have code written by Bill Joy. They're all running vim which is what the OS gives me. Is this a BSD thing?
The BSDs use nvi which is a clone of vi from about 1990.
You might encounter Bill Joy’s vi on a Solaris or illumos machine.
Sacrilege:wq!
He's right man ^X^S
WTF, why isn't my terminal responding
ZQ
ZZ because I like my changes!
:exit
Because its nice to sound it out .. "colon .. exit" ..
Proof that shift contains fiber and caps lock sleeps on the job.
OK cool, should I switch to nano? I need to be able to ssh into an arbitrary machine of whatever distro started by someone else, on another continent and edit a config file before restarting a service that is currently shedding millions of connections a minute.
What else should I use?
This article is arguing against vi, most systems install vim by default.
Or further, I don't know about other distros, but Arch doesn't even package vi (in the main repos) - it's a package group (or some implementation I'm not sure off the top of my head) consisting of vim and vi-compat.
Most systems meaning Linux and macOS. FreeBSD, NetBSD, and OpenBSD use nvi, and BusyBox (Alpine Linux core userland) uses tiny vi.c.
Very true! I spent a few months using OpenBSD and nvi as my primary environment, and actually ended up pretty productive with it.
vim is so ubiquitous that most people don't realise vi is symlinked to vim pretty much across the board
I was honestly embarrassed to admit that I have no idea what I've been using on my Ubuntu server for the last 10 years. The way to find out if I'm using vi or vim is to enter command mode (by pressing “:”) and run “version” I'm using vim ;)
Yeah
The exception is when you go do some work at server using a commercial unix and that is not how it's set up (in fact they don't even know about vim)
sigh but ok that story is dated and that behavior was already dated at that time
> but ok that story is dated
I'm struggling to think of the last time I saw a commercial unix -- we still had solaris on some new machines until about 2006 - the last I remember was the x4500 with ZFS.
Our sun sysadmin contractor (whose full time job it was to look after about 10 solaris machines) was a big fan of ksh at the time.
I used a Sun workstation as late as 2008, but by that time it was ancient and kept around only for the expensive engineering software that wouldn’t run anywhere else. Even at the time, using CDE felt like a blast from the past. I didn’t dig too deep because I wasn’t using it for long, but I’m pretty sure the vi was original.
Your date range is correct ;)
But some companies are even slower to migrate
Anyway I don't know how the builtin shell was called, maybe simply sh but it was also a big no no for me
Unironically yes, switch to nano. It is an excellent and vastly underestimated editor.
(though admittedly, with a somewhat unfortunate default config, at least for modern environments)
It has been my editor of choice over vim for many years now, and I'm super productive on it (though at this point, partly this stems from me having developed my own set of custom macros and helper utilities over the years).
In a world where emacs exists, why use something else?
Because emacs requires 8 meg of ram, and even then it's continuously swapping?
Because it's not installed by default.
> Hot take: basic vim (without plugins) is mostly what vi should have been in the first place, and much of the differences between vi and vim are improvements.
Literally second paragraph.
Have you tried Claude Code for this use case? I have found it effective for editing remote configs.
Then: Do one thing well. Every megabyte matters. Personal webspace and shell accounts. Unix herding. Vi vs vim. Vim vs Emacs.
Now: Which React Yoga Bun TypeScript Tailwind Node vomit is better for shipping 250k unchecked LOC? Florp Code or Blorp Codex?
We mourn our craft.
https://news.ycombinator.com/item?id=46926245
seems like a security risk
seems like marketing to me...
>Have you tried Claude Code for this use case?
Surely you're being sarcastic... aren't you?
Aren't you?!
Don't knock it until you try it. For example:
"ssh username@ip and configure logs to be persisted for only 1 week."
ed?
https://i.vgy.me/Q5qIIP.png
i've been using nano for server stuff since ever. i could never understand why anyone would us vi/m with its bs shortcuts, making BASIC text editing into a complete **.
Speed (both in the CPU/memory usage and in speed of editing using advanced commands), backwards compatibility with older servers, ubiquity (guaranteed it is on every server you touch), insane feature count vs Nano, and my fingers mostly stay on the home row.
Its major downfall is the commands are hardly intuitive, but I forced myself to learn it by doing everything in Vim (including shopping lists) and it now feels comfortable.
Then you have situations where you have no choice. I work for a company with over 100,000 servers and they only install Vim and disallow us installing anything else.
Not that we would have time; we’re in and out of each server in five minutes then on to the next ticket.
I won't deny that vim has an "insane" feature count (particularly with plugins), but people who claim this kind of comparison typically vastly underestimate nano's own feature count and flexibility / extensibility.
And I'm surprised this usually comes as a surprise to people, given nano provides the ability for both internal (i.e. macros) and external scripts to manipulate its buffer. In principle you could even run non-interactive vim commands through nano if you really wanted to.
That’s a fair point, but the rest are still relevant. I simply cannot use Nano at my job but once you learn the basics Vi is not bad.
I can see both having a place: vi/vim for more elaborate features and editing capabilities, and nano for the quick "I need to change that one little thing in my config file" fix. I prefer nano over vi every time, but I barely work over ssh more than once a month. There is simply no need for me to know more about vi/vim.
It doesn't hurt to know some basic vi/vim commands though, as you will mostly encounter them pre-installed on even the most exotic distribution.
> i could never understand why anyone would us vi/m with its bs shortcuts, making BASIC text editing into a complete *.
I could never understand why anyone would use nano with its bs shortcuts, making basic text editing (in contrast to basic linear text writing, which even a non-modal editor like nano can do decently) into a complete *.
This is dumb. Sure, some people don't get modal editing. Others don't get how you could live without. It is almost as if people work differently and have different preferences.
I get why OSes come with nano as the default editor, but it's so confining and slow to use when you're used to vim (or I'm sure emacs)
Emacs is a bit special in that the "canonical" way of editing a remote configuration file with it is probably using TRAMP, i.e. connecting your local emacs via ssh to edit the remote file as if it was local.
Vim is the exception, not the rule. Most people don't want a mental model just to type a sentence. Instead of the snark, you could just admit that your preference doesn't align with the median user.
> Most people don't want a mental model just to type a sentence.
"Just typing a sentence" is what I was referring to with "basic linear text writing", for which modal editing indeed does not bring much of a benefit. That's not text editing though.
> Instead of the snark, you could just admit that your preference doesn't align with the median user.
? I explicitly wrote that people work differently and have different preferences. What was snarky about that?
Besides, the median user does not edit configuration files via ssh, so they are hardly relevant here. The median user does not even know what a terminal is. If this was about the median user, then we would be discussing Word vs. Notepad, or whatever.