I love both Vim and Emacs, but I think they have different use cases.
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
Emacs starts up pretty quick for me. Kind of agree though, especially about the modal editing and quickly navigating. I often start up vim when I want to edit a word or two at a specific line fast. I switch over to emacs if I end up editing multiple lines and organizing the text.
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.
When I meant customization, I didn't mean the availability of plugins. I meant the ability to change everything, and do it myself simply and quickly if needed, from within the editor itself.
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.
I agree: Vim is really held back by its reliance on default keymaps. Sure, you can remap them, but they are still the lifeblood of what Vim is. You can't change what they are.
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.
Careful running emacs as a systemd service. I did this for some time, but then one day when I rebooted the computer, nothing worked - drives weren't mounted properly, services I expected weren't there. I finally found that none of my systemd services had come up (but systemd didn't generate errors or failed messages) and yet later still discovered that it was apparently an error in my .emacs that had somehow caused a domino effect of none of my systemd services starting up.
I've gone back to just having `emacs --daemon` in my .xnitrc.
I also had errors in my .emacs many times and had no issues, until one day.
> 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'm glad I made the switch from Arch to Void. Runit is clean and simple, it does the correct job in a deterministic fashion, if something fails proper errors appear on usual logs.
When I install Gentoo or Arch, one of the first things I install is vim and one of the last things I install is emacs because that's where I do all my work.
Both editors are fully capable, it really depends on personal preferences: what they see as a minor if any annoyance: multi-key presses or two-mode editing. I use vim and it works great for me for large tasks as well. I never developed a pianist's finger agility for multi-key commands (those famous Esc-Meta-Alt-Ctl-Shift types). If I did I probably would have loved Emacs more than vim.
> Both editors [ed: vim & emacs] are fully capable, it really depends on personal preferences
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.
You keep talking about "better" editor, keybindings doesn't make an editor, emacs is as capable editor as vi is. Then you go on to talk about how spacemacs is so much better, what? All it does is add someway to structure your packages and use evil-mode(which shows that yes you can replace keybindings).
The editor in a concrete form is one thing. Like what can the editor actually accomplish in terms of features. I'm not sure which of Emacs, Vim or Neovim would win this one.
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?
I use emacs for almost everything, but for me nano is the lightweight gnu editor I use when I would use vi(m)... of course, knowing vim is important because some systems only have it. (but with emacs I can just edit files remotely anyway)
I used to be a heavy emacs user but decided to just learn vim because vi is practically available on everything whereas emacs isn't. The investment paid off big time. Unfortunately, I forgot my way around emacs, which can make it difficult on systems where emacs is the default EDITOR.
It might be more practical to learn just enough vim to be able to edit files efficiently, and stay as an Emacs expert, if you are one already.
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.
If you have SSH connection to the server then you can do all your editing on your own computer with Tramp in Emacs and it applies your changes remotely.
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.
While I agree with you, if you have SSH access then you've opened up yourself to a lot of possibilities by simply mounting the remote directory in your local.
Honestly, I've never learned to do more than the basics in Vi(m) -- for most of my career, if I needed to make significant changes, I was working locally and had access to something more modern.
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.
Is there a vim with support for large files, i.e. only reading a chunk/window of data at a time as I browse?
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
but it would be nice if I could scroll through the file in vim.
I think less does exactly what you're asking for, unless you need to edit the file. less and vim have similar keybindings. For multi-gigabyte files, you may want to disable line counting and perhaps seek ahead via command line options to make startup instantaneous.
You don't even have to disable line counting explicitly, less is kind enough to tell you "counting lines is taking a long time, interrupt to disable". So you can just ctrl-c if the file is too long and you don't want to wait.
`vim -n` should avoid the initial swap file. Or was it `-b` that triggered in-place editing?
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`.
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.
I think the problem is if you press q accidentally when you want to hit :q and then hit q again (recording @q), at this point Esc won't work and you have to hit q a third time to exit.
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.
> Target notes that in the days before GNU Emacs, it could cost hundreds of dollars to install Emacs. “So vi became enormously popular.”
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.
While I don't believe neovim is still a complete refactor, particulary with regards to stability, I also don't think it gets mentioned enough as a competitive advantage of Vim landscape.
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.
It misses out a lot of them. There are at least ex; vi; stevie; elvis; calvin; elwin; javi; lemmy; pvic; trived; vigor; vile; vip; virus; winvi; xvi; vim; nvi; and nvim.
I find spacemacs interesting, but it feels like there's not a lot of things happening in the community. The news section on the website is old (seems from 2016?), there's no user forum, commits on github are a couple of months old. Am I missing somthing?
It seems to be actively used (150+ active pull requests, ~2000 open issues), but not actively maintained, since there is a single person behind the project, who probably took a long break from it. And to be fair, it's just a modular layer on top of Emacs, so it's not like it can get outdated any time soon.
develop branch [0] is very active and the community is quite active and plentiful in real time on Gitter [1] (it's mostly friendly and helpful, so don't be shy).
I spent two weeks trying out the evil mode in my daily workflow. Some things were much more user-friendly than vim but at many points the rough edges of the vim emulation on top of emacs showed its bare spots. Finally, lack of support for a good database client bought me back to spacevim which is a similar space-driven IDE written in native vim.
> Ken Thompson: “yeah, I’ve seen editors like that, but I don’t feel a need for them, I don’t want to see the state of the file when I’m editing”
...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.
I don't interpret it as being "blinded by perspective", though. I think Thompson was (in a lighthearted curmudgeonly way) describing the virtue of having the primary buffer of your document in your head. I certainly don't. I scroll to find what I've written to remind myself what it is... I rely on the memory of the machine and use it a substitute for my own. I feel like he's describing a more disciplined way of thinking, and reminiscing about when it was strictly necessary.
> reminiscing about when it was strictly necessary.
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.
I feel almost ashamed to admit it, but I've never used vim for work. I use nano for quick edits and sublime text (or rmate+sublime text) for everything else. Maybe I haven't found the right use case yet.
vi may be guaranteed to be there, it being standardized alongside ex in the Single Unix Specification. vim does not have such guarantees. Nor do you have guarantees that vi is even the same program as vim. It can be nvi or even actual Joy vi on some systems.
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.
I made it past the first paragraph playing fast and loose with vim's heritage (it's a clone, not a porr or a fork) but when it directly referred to Bill Joy as the creator of vim in the second paragraph, it became too hard to keep reading.
I try like every editor, on a regular basis. I was heavy into Emacs for about half a year. But I always come back to (neo)vi(m) eventually.
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.
Because I learned vi back in the day (yes, before cursor keys were supported!), I never quite got used to typing that extra "m". What are the biggest improvements of vim over vi?
On many systems vi is a link to vim. My ubuntu laptop for example:
$ 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
One thing that springs to mind, I don't believe native vi supports ":split"? Does it do syntax highlighting?
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.
Thanks. They're distinct editors on macOS which I'm currently using. And no, vi doesn't have syntax highlighting so perhaps that's a big enough reason right there...
> They're distinct editors on macOS which I'm currently using
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
`vi` merely starts `vim` in compatible mode (see `:help compatible`)
† 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)
vi (and vim) are still really relevant, if you have ever tried editing config files on IoT devices such as remote condition monitoring systems over a satellite link or a mobile link.
From the article
"you’ve got to remember that I was trying to make it usable over a 300 baud modem”
8.0 was the first major release in 20 years? I find that claim highly suspect.
... 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.
Video Studio Code has become my favorite editor way ahead of Vim. I've used Vim for many years, but I'd miss the intellisense insights of VSC too much to go back to Vim.
I also actively use a Lisp/Scheme dialect on the side, but I wouldn't want to manage the complexity of Emacs.
You know this (lack of good intelligence/autocomplete) has been a thorn for him for ages. It is 2018 and I wonder why code completion/ast analysis/indexing is still not a easily usable service/daemon yet?
This is actually a common consensus among many idea developers. And is actually a pretty good idea at least in theory (practical efficiency is where it gets fun and interesting).
Given that, I would love to know why this comment was down voted?
"...It was a world that is now extinct. People don’t know that vi was written for a world that doesn’t exist anymore..."
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.
Found it interesting the VIM started off as VI Imitation, before becoming VI Improved.
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.
I preferred Sinclair Target’s own history of ed,em,ex,vi,vim [1] (recently discussed on Hacker News [2]) on which much of this article was based.
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.
what was the editor that reversed vims syntax/grammar?
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
96 comments
[ 3.1 ms ] story [ 167 ms ] threadFor 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.
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.
0: http://paulgraham.com/avg.html
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.
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.
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
but it would be nice if I could scroll through the file in 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
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
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.
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.
* http://guckes.net/vi/clones.php3
Spacemacs[1] is a combination of both of them.
[1] http://spacemacs.org/
https://github.com/syl20bnr/spacemacs/tree/develop
[0] https://github.com/syl20bnr/spacemacs/tree/develop
[1] https://gitter.im/syl20bnr/spacemacs
...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.
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...
I love vim, use it every day.
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.
The manpage on my laptop says
Full list at https://github.com/vim/vim/blob/master/runtime/doc/vi_diff.t... (which has nice syntax highlighting in vim)Nope, they're one and the same, from Mavericks† to Mojave:
`vi` merely starts `vim` in compatible mode (see `:help compatible`)† 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)
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 :-)
... 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.
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.
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?
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 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...
[2] https://news.ycombinator.com/item?id=17696023
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.