For me, vim is a combination of genuine improvements in vi’s core editing behavior (cf), frustrating (to me) bits of trying too hard to be smart (which I mostly disable when I run across them), and an extension mechanism I ignore but people use to make vim into a superintelligent editor with things like LSP integrations.
Some of the improvements and additions to vi’s core editing may be things that Bill Joy either didn’t think of or didn’t think were important enough. However, I feel strongly that some or even many of omitted features and differences are a product of the limited environments vi had to operate in. The poster child for this is vi’s support of only a single level of undo, which drastically constrains the potential memory requirements (and implementation complexity) of undo, especially since a single editing operation in vi can make sweeping changes across a large file (consider a whole-file ‘:…s/../../’ substitution, for example).
↫ Chris Siebenmann
I have only very limited needs when it comes to command-line text editors, and as such, I absolutely swear by the simplicity of nano. In other words, I’m probably not the right person to dive into the editor debate that’s been raging for decades, but reading Siebenmann’s points I can’t help but agree. In this day and age, defaulting an editor that has only one level of undo is insanity, and I can’t imagine doing the kind of complex work people who use command-line editors do while being limited to just one window.
As for the debate about operating systems that symlink the vi command to vim or a similar improved variant of vi, I feel like that’s the wrong thing to do. Much like how I absolutely despise how macOS hides its UNIX-y file system structure from the GUI, leading to bizarre ls results in the terminal, I don’t think you should be tricking users. If a user enters vi, it should launch vi, and not something that kind of looks like vi but isn’t. Computers shouldn’t be lying to users.
If they don’t want their users to be using vi, they shouldn’t be installing vi in the first place.
I learned vi in college and used it often in the golden age of UNIX. vi is guaranteed to be on every UNIX system. Yes one level of undo. On a PDP-11 or a 68000 based system you don’t get a lot of RAM so this makes sense. Back in the old days one level of undo was really all you got. I still use vi when emulating PDP-11 on SIMH.
> as such, I absolutely swear by the simplicity of nano
In the same category of simplicity (for when I actually use a terminal editor), my fav is: https://github.com/gphalkes/tilde
“Blasphemy!”
I was a nano user too (or was it pico? year 2001). Until I had to work on a Sparc workstation which did not have that luxury (I finally was able to get it running after manually gathering and compiling all source packages necessary, but)…
Then I realized between Sparc, multiple labs, and IRIX… I would have a difficult time if I did not learn a proper editor.
At that point I opened up vimtutor and the rest is history.
Even today in any IDE I use, let it be vs code, antigravity, visual studio, or anything else… the first thing I do is switch to vim mode.
Why?
It is extremely more productive compared to primitive editors. Especially when bundled with modern IDE and “language services” (clangd)
There was “joe”, a very lightweight editor that you could compile anywhere.
I’ve been using it since 1992 and avoiding using “vi” whenever possible.
Of course, at some point I had to memorise basic vi commands, but I’m glad that I found joe.
https://joe-editor.sourceforge.io
Assuming you actually have a compiler, which many unixes didn’t include by default (often it was a costly extra), and most embedded devices also lack.
As an old Word Star (look it up) user, there was a time when I looked at Joe. But, for me, those old CP/M days were before my Unix days. So, “vi ftw!!” In the earlier days of Linux, I recommended “vi” (or vim) since it was likely you’d be using Linux along side multiple Unix systems. Now that the Linux takeover is effectively complete…. use whatever suits you.
Back in the 1980’s (DOS programming) I had been using qedit.
From early 1990’s (Linux programming) used {vi, emacs. joe, nedit, etc.} and selected the “joe”-editor as my “goto”-terminal-based-editor for my software development needs.; I dropped the “Ctrl-K” prefixes for more direct access to keyboard commands (similar to my DOS editor experience years earlier).
I use “joe” as the preferred text file viewer/editor for midnight-commander visual-shell.
The “joe” editor coupled with suckless.org’s “tabbed” program provides a powerful multi-editor setup.
As time progresses, there’s that itch to try other existing/newer terminal-based editors (nano, pico, tilde, etc.), but I always returned back to “joe” edtor,
Even with it’s non-subtle learning-curve, I like joe’s syntax highlighter and have prepared custom syntax highlighter files for non-C-C++-languages I use (I use “joe” editor for C/C++ coding); i.e. VRML, AWK, REXX/OOREXX, Julia, Icon, Modula-3 languages.
With a relatively small C source-code footprint and builds with trivial library dependencies, implementing “mods” for “joe”-editor is convenient. A useful “mod” I implemented was support of “X selections” (i.e. clipboard in X-Window system); e.g. whilst “joe”-editor running in an xterm, any highlighted block of text, especially a multi-page scrollable block of text, can be copied to X-Window system clipboard and subsequently any other X-Window-client program (e.g. another “joe” xterm-window) can paste this text from the clipboard.
Vim symlinked to vi isn’t actually lying. When argv[0] is “vi” instead of “vim”, Vim starts in vi-compatible mode, aside from a few things like multilevel undo (and I’m pretty sure even busybox vi has that these days). You have to run “:set nocompatible” to turn on the full power version.
runciblebatleth,
Yes
Vim has many useful “modes” like “vi” compatibility as you said. But also “vimdiff” which is a nice way too consolidate differences between files, “view” which is a read only viewer mode, and of course “vimtutor” for those who are yet to experience greatness.
It isn’t tricking users if it’s documented, expected behavior.
When vi is a symlink to vim, vim launches in a vi-compatible mode in which vim extensions are disabled. This is how most commands that are upgrades to old UNIX commands operate. bison does the same for yacc, bash and dash do that when launched with sh, etc.
This also helps make users portable across different versions, so if you have the EDITOR environment variable set to vi, it’ll work regardless if you have vim or neovim installed.
When I was in university I started learning UNIX on a FreeBSD 2.1.2 server. I had also access to a Linux server (aptly named student) that had pico (nano didn’t exist yet), a colleague of mine asked the teacher why the FreeBSD server had no pico as student had it, and why did we have to use vi.
His answer stuck to me: “Because vi is guaranteed to exist in every UNIX and UNIX-like operating system.”
We had no choice but to learn the basics of vi. Nowadays, I always use vi (mostly vim, actually) for all but the most complex development tasks.
vi is not difficult for basic editing. Of course, all those single and double keystrokes can be daunting for a new user, but it’s worth the effort of learning it, specially if you want to work in IT, as I do.
AntonioTrindade,
I learned the importance of picking up vi as well. vim is preferred when available. However either way I don’t much like ESC driving editing. I find the need to toggle modes to be inefficient. Of course it becomes muscle memory, but still it’s obvious it was designed for more primitive input and it worked reliably over telnet. Today terminals are much more capable but vi still stuck around as the standard.
I am still using vim, with plugins, very customized. Got bars, colors, menus, mouse, syntax checkers. years and years of customization of my .vimrc.
sorry, you can’t teach an old dog new tricks.