A Look at Vim, a Text Editor for the Ages
thenewstack.io
thenewstack.io
For example, I find it much more productive to use Emacs for writing heavy tasks, where you'll spend a lot of time in the editor. Such as coding, writing notes, a book, an article, a paper, etc.
To me, these tasks suffer from having to switch back and forth between modes, and emacs just provides more features for them and can be customized endlessly to your specifics.
Vim on the other hand shines for quick edits, touch ups, or reading, viewing and analysing use cases.
Its best feature is performance. It starts fast, runs fast, can handle big files, consumes little memory and is small in size. This is ideal on a server, or as a default editor. I wouldn't want to have Emacs for these, it's too heavy.
For editing small parts of an existing file, the modal editing is also best. It makes navigation front and center, which is what you want, quickly find the part to edit, and quickly edit it, done.
I personally like it this way. I don't actually want Vim to grow to approach Emacs in customization. I also don't think anything can, the fundamental design of Emacs as a Lisp REPL with an editor loaded into it just can't be beat for that.
$ alias cs='emacsclient -nw'
$ emacs --daemon
$ cs notes.txt
I have emacs running as a systemd service, so I never notice its real start time.
> I don't actually want Vim to grow to approach Emacs in customization.
It already has. The difference is that it doesn't come with very many packages, and packages aren't all written in elisp.
Neovim will end up with a similar amount of packages eventually. A lot of those packages will be written in Lua, making them relatively fast and lightweight.
(Neo)Vim doesn't lend itself to total customizability, since its foundation is dependent on its default keybindings.
There's only two editors I know that give you that, Emacs and Atom.
That said, I didn't try neovim, but it just seems like Vim with Lua plugins. Kinda similar to how Sublime Text can have Python plugins.
Even emacs has this problem: there is a general set of consistent keymaps that are set by a wide variety of emacs modes. It's certainly not a trivial task to change, or get rid of them.
I've gone back to just having `emacs --daemon` in my .xnitrc.
In case you are interested, I followed the instructions here: https://nixos.org/nixos/manual/index.html#idm140737316012272
I imagine it is a very common practice for NixOS users to run emacs as a systemd service.
> I don't see your experience as a reason to not to do it this way.
That's fine. I simply offer it as a cautionary tale. It's possible that systemd on Nix handles things more gracefully than systemd on Arch (though it seems unlikely).
I think that Paul Graham's Blub Paradox[0] applies to editors and operating environments as well as to programming languages: someone using an editor or environment which sits at a particular level can look down at lesser editors or environments and see how much more productive his is, but when he looks up at other editors or environments he just thinks they don't make sense — at best they solve problems he's never had, and at worst they are just plain weird.
The troublesome thing is, vi is in many ways a better editor than emacs is, but emacs is definitely a better operating environment than vi, vim or neovim is, so you're kinda stuck. If you want a great editor, then you want vi — but then you're stuck with a terrible, sub-par editing environment. If you want a great environment, emacs is hands-down the best — but you're stuck with a hand-hurting morass of keychords. I honestly don't believe it's a personal preference to state that vi's text-manipulation language is better than emacs's, but I also honestly don't believe it's a personal preference to state that emacs is a better, more extensible environment than vi, vi or neovim.
Spacemacs is a really interesting experiment in merging the two, adding the text-editing language of vi to the operating environment of emacs. It's probably the way of the future, although there are just enough rough edges that I ended up returning to emacs.
Why did I do that, when vi is the better editor? Because as important as editing text is, emacs provides an entire environment for computing. It's the ocean in which I swim, the forest in which I hunt, the field where I sow my corn and the air I breathe. Less poetically, Magit & Org mode are awesome; four decades of contributed code mean that just about anything I want to do has been implemented; elisp means that anything that hasn't is easily implementable.
It also depends if you assume out of the box feature set, or potential feature set. Like with added plugins and customization. I feel Emacs has the potential for many more features, and does have more in my experience, but not out of the box. Vim has a slight edge out of the box.
The other thing is the editing UX. The modal editing Vs key-chord editing. That's where I feel there is no all around winner. I find modal is great for small edits as I said. And single mode with key-chord I find better for long writing sessions, where you actually type a lot.
Are you saying you find modal to be best at both of these use cases?
You can use it with Vim key bindings, but get the customization offered by Emacs.
I also suggest trying it in Holy mode. What it does well is make commands mnemonic, more similar to Vim, but they just all start with M-m (Alt+m)
So you would do something like M-m b N to create a new buffer. Or M-m w / to split the frame in two windows horizontally.
This I find saves you to modal switch overhead, but maintain the simpler keystroke commands.
Spacemacs[1] is a combination of both of them.
It doesn't have to be one or the other; the brain is surprisingly elastic. After a few months of training I can edit files efficiently in vim and Emacs with both querty and dvorak keymaps. That's 4 different mappings to keep in your head, but surprisingly I can do it, and I'm not particularly fast at learning new stuff.
So emacs being installed on a server or not is not really a reason to drop it, because you are not restricted to tools on the server.
https://www.gnu.org/software/emacs/manual/html_node/tramp/Co...
But pretty much everyone needs to be able to, say, open a file and change a DB connection string in vi. It's like a survival skill.
I only started using emacs in the last few years, which is super weird for someone my age (48). It was orgmode that sold me, and once I was using it for that, it was easier to do other things in it, too.
instead of d2w (delete two words) you could type something like w2d (words, two, delete). This way you can select first, modify later and most importantly guide visually before execution.
I think you where able to type something like w2u3d (words, two, no undo it's actually 3 i see now, yes delete those).
I wished evil emacs did that. I mostly use org-mode and do little programming and I constantly get the number of words to delete wrong.
edit: I think I just need to learn to use visual mode more and be quire alright already
It has excellent discoverability and learning curve.
And every time I use it I'm reminded that there is this devops/automation movement against interactivity with systems and that this editor is symbolic of (and best suited to) an operator culture..which is also dying if not defunct.
I haven't even considered there was an emacs before gnu emacs.
... Ctrl + F neo ...
Damn, no mention of neovim. I was hoping they'd have mentioned it. Feels like an oversight given the completeness of the rest of the pre-vi, vi, and vim history.
With it, Vim now basically has very robust, modern, async, understood-by-many-contributors, sanely-scriptable, extensible, embeddable version that'll propel it far into future.
I'm bullish on Vim.
Main reasons for me are that it is fast, easy to use and I can move around and edit at a tremendous speed. It’s like working on a block of marble, carefully crafting.
Which is why a work colleague of mine for years maintained the habit of using vim with the arrow keys unmapped, so that the kinaesthetic memory would work if xe hit a system such as that.
* http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...
1) Learn what's going on, press q to start macro mode, and then press a letter to name your macro. Do stuff and when you're done press q again. You can then repeat that macro with @x where x is whatever letter you named your macro. @@ repeats it, and 74@x does it 74 times. It's (very occasionally) awesomely powerful.
2) echo "noremap q <nop>" >> ~/.vimrc
<li>
</li>
<p>
</p>
I/*<esc>A*/<esc>
gcc
When taking a second to think about it it's quite obvious but in the spur of the moment I sometimes get stuck hitting Esc multiple times before realising I'm in macro-recording mode and hit q to exit.
I've also seen many new vi-users get confused when they accidentally enter macro recording. This could probably be improved with some clever hinting (maybe change hint to "recording @{key}, hit q to exit/stop recording") and maybe some hint when hitting q only once indicating that you're about to start a macro sequence.
My use case is that I sometimes need to inspect large CSV files and vim will take a long time and then abort saying that it couldn't complete loading the file.
I guess I could use
head -n 100 data.CSV | vim
You might want to tune `set syn_maxcol=256` to avoid highlighting or disable syntax completely. It might help to set the filetype to something else for CSV. If plugins slow you down use `-u NONE`.
> head -n 100 data.CSV
You could do something similar with
sed -n '101,200p' data.CSV | vim - split data.CSV; vim x*
I think the article really meant "A look at VI", since it was about VI, despite starting with "Vim creator Bill Joy told Linux Magazine." Given that Bill Joy created VI, not VIM, and the article goes on to discuss VI primarily.
There were a few interesting things that I learned from this article:
* lower case letters had only recently been added to terminals. I had always presumed that terminals used the same technology as typewriters, i.e., use the Shift key for switching between upper and lower case.
* vi was designed to be “usable over a 300 baud modem”. I’ve found that this aspect makes vi/vim useful over slow network connections – or when a remote server has runaway processes resulting in SSH being slow and unresponsive. It’s not always true that this is a “world that doesn’t exist anymore”. That world still pops into existence for brief moments of (stressful) time.
[1] https://twobithistory.org/2018/08/05/where-vim-came-from.htm...
I also actively use a Lisp/Scheme dialect on the side, but I wouldn't want to manage the complexity of Emacs.
1) Add a LSP plugin to your editor
2) Start a LSP server
...and get pretty much state of the art code completion in whatever editor you use.
Given that, I would love to know why this comment was down voted?
... search ...
Judging by the timestamps on the vim ftp server, 7.0 was released in 2006. 6.0 in 2001. 5.0 in 1998. That's about how I remember it, although I don't think I got on to the 5 series until after 2000. Anyway, that's four major releases in 20 years.
> This the first major Vim release in ten years.
$ which vi
/usr/bin/vi
$ file /usr/bin/vi
/usr/bin/vi: symbolic link to /etc/alternatives/vi
$ file /etc/alternatives/vi
/etc/alternatives/vi: symbolic link to /usr/bin/vim.nox
The manpage on my laptop says
There are a lot of enhancements above Vi: multi level undo, multi windows and buffers,
syntax highlighting, command line editing, filename completion, on-line help, visual
selection, etc.. See ":help vi_diff.txt" for a summary of the differences between Vim
and Vi.
Nope, they're one and the same, from Mavericks† to Mojave:
$ ls -l /usr/bin/vi
lrwxr-xr-x 1 root wheel 3 24 Jul 10:56 /usr/bin/vi -> vim
† I actually booted a fresh Mavericks VM just to be sure, but I'm quite certain it's also the case way back to at least Tiger (which is the first OS X I ever had)
I use Microsoft Code with Vim extension and RStudio with Vim option turned on. I am very happy with MS Code and sort of with RStudio's take.
From the article "you’ve got to remember that I was trying to make it usable over a 300 baud modem”
Awesome piece of design. Thank you :-)
I love vim, use it every day.
...Indistinguishable from XKCD
I don't think this is one of those "it's obvious in hindsight" things either. I think he must have been blinded by his own perspective, a perspective that was both inevitable and necessary at the time when there was basically no text editors.
Only direct reference I could find to the (secondhand) quote - http://web.archive.org/web/20080103071208/http://www.dcs.qmu...
Yes this is what I meant by "a perspective that was both inevitable and necessary at the time when there was basically no text editors." although I should have known that suggesting thompson was wrong in the most understanding way possible will attract downvotes here.