I think vi might more charitably be described as a paradigm shift. It also happened to bring terminal independence to everybody by later prompting the development of termcap (like vi, brought to us by Bill Joy). Of course termcap begat terminfo, [n]curses, ...
I feel like grandparent wishing for acknowledgement isn’t really out of line. It’s “Show a little respect; you have no idea where we were before vi.”
Is that not the case? How different is vi to vim?
The differences are not huge, but even if I have a "small" .vimrc with one single plugin, I have issues using the vim.tiny installed on Debian by default.
The Vim help has a list of the differences:
The most important to me are:
- a real undo
- macros (recorded on the fly with ththe q key)
- visual mode (included the block selection mode)
- text completion (ctrl-p, ctrl-x-f)
- automatic indenting
- advanced text objects (selecting everyting between '()')
Not having one single of them would not hinder me much... but all of them at once: that hurts!
A couple of examples. In Spacemacs, the screen regularly goes blank for a while. Or if I have a file open in Spacemacs, close its window, then rename it in the OS, then reopen it in Spacemacs (by double-clicking it in Finder) it reopens it with it's old name. I'm sure there's a way to avoid this, but the fact that it happens in the first place is the issue.
As for the file rename issue, certainly if that's part of your workflow, it's helpful to figure out why it happens. I suspect it's due to the way filesystems work on Linux /Unix.
Vim does away with the hand-travel delays, but many of these ninja keystroke moves to navigate code are just what your eyes do already (but not all, such as the search function).
I haven't yet found such a solution but I do wonder how hard it would be build such a thing.
It’s interesting to me the different models for tools that address similar problems. I used to use vim, and the chords of keystrokes are still fresh in my mind, even though I switched to emacs years ago.
And now I use vanilla emacs —but that model is totally different, it’s an okay text editor but an excellent customizable user shell. It’s not a matter of better//worse, but of different philosophical approaches
1) Learning Vim increased my efficiency across multiple machines, and not just my dev machine.
2) It's extremely lightweight. Note: you still need to be careful with plugins!
3) Modal editing is easier on the wrists. Most of my time as a developer is spent navigating through code (whether editing or browsing), and Vim's normal mode keybindings are much less modifier-based.
Here it is: https://youtu.be/E-ZbrtoSuzw
I use it lots of times (not for everything, I also use Visual Studio Code), mainly because it means that I can just ssh over to a VPS and edit a file in there, without having to set up fuse or some other way to edit locally. It seems like less work to just get into files and set up a new VPS. And I know there will be syntax highlighting for everything.
And also I have kind of a sunk cost of finally learning how to do basic things over the course of many years.
But personally, I think that it is embarrassing for people who seriously espouse that modal editing is better than more modern concepts.
The reason we have hjkl for movement is because that is what the terminal was like when vi was invented. And the reason its Escape which is a little inconvenient on modern keyboards is because the Escape key on that terminal was more like where Tab is. And the reason its modal editing is because "real time editing" didn't even generally exist when vi was invented:
"Back in 1970s, terminal screen are 80 columns by 24 lines. There's no real-time editing. You edit by typing a command, then call another command to have the screen update to show the result of your command. Vi's “modal editing” is evolved from this." http://xahlee.info/kbd/keyboard_hardware_and_key_choices.htm...
nano is fine for quick edits, but the more Vim you know, the better off you'll be in that situation. If you're not a devops/sysadmin person, or you don't spend a lot of time in command-line Unix, there's no shame in not knowing Vim. But it is universally better than nano.
Most modern editors, Visual Studio Code included, have powerful refactoring abilities. Not only that, but they're usable without needing to be an editor expert - just right-clicking and selecting "Change all occurrences" (or pressing F2) does the trick.
edit: no shade on VIM and VIM macros; they're great. I'm a very experienced vim power user, but have switched to vscode with vim keybindings, and I'm very very happy with the switch.
Nano lets you do that too.
Nit: in csh, it's 'setenv EDITOR vim'
I have a couple friends that swear by Sublime Text. It costs money but its not terribly expensive, and super fast. Its vim plugin is a bit lacking though so it wasn't that usable for me.
I'm not really an advanced vim user. I have to think and remember how to do column edits, and I never yank to registers. For some reason I want to make a concerted effort to learn emacs again but the idea of not having edit modes concerns me.
The org-mode outlining and magit wrapper for git are most worthy.
I also find that because it has such a customized way of doing things it often becomes quite difficult to make your own customizations, especially if you try to follow guides written for pure emacs.
I've just started using doom emacs, another "distribution" around evil-mode. So far I really like it, it is much snappier than spacemacs and the layering and customization system is much closer to traditional emacs.
The regular key chords tore me up badly.
The performance/layers have never given me grief with spacemacs.
Best setup is vscode with vim emulation and I’ve been using vim profesionally almost 15 years now.
Funny enough, I actually liked writing prose with Vim but I’m using Ulysses as an editor for writing prose now
Perhaps, as they imply, I should dust off a copy of Microsoft Word and switch back to that!
(The typesetting part isn’t the issue. Concentration and ease of flow in the editor feel hard in vim, and LaTeX wouldn’t fix that.)
nmap ,w :w<cr>
In the end, vim doesn't stop you from defining key bindings to improve your workflow.
" save with ctrl+s
nmap <c-s> :w<CR>
imap <c-s> <Esc>:w<CR>a
nmap <D-s> :w<CR>
imap <D-s> <Esc>:w<CR>a
imap <C-s> <C-o>:w<CR>
1. You can bind save to any key combo you want. I personally use <leader>w. I find it more ergonomic, fast, and portable than command-s.
2. Every action in vim reads like a little story. You start to speak the stories to yourself. For example:
Select the entire line (V), move to the end of the line ($), move to the matching end brace (%), delete (d)
3. Then you realize you can store those stories into a macro and execute them ad hoc, and the world becomes amazing.
The things you learn are cumulative. You begin to expect the pattern to continue and more often than not it does.
Does anyone have suggestions of what worked to help learn mor Vim commands?
 Learn vim For the Last Time: A Tutorial and Primer— https://danielmiessler.com/study/vim/
 The Vim Learning Curve is a Myth—https://thoughtbot.com/blog/the-vim-learning-curve-is-a-myth
It’s message of the day but with ViM tips. It worked fantastically for getting small tips throughout my day that allowed me to consume and learn without necessarily dedicating any tangible amount of time to it.
All extensions have to run on the same thread in a background process and intercepted keystrokes are passed to that process over IPC. So if other extensions (like the TS language tools) are tying up the extension host process, the Vim extension can't respond to your keyboard input until other extensions yield.
Performance issues come and go but for awhile I was stuck waiting for several seconds any time I typed a < after an identifier.
A lot of us have tried to demand a separate process for extensions that intercept keystrokes to solve this issue permanently. But the maintainers don't really care.
I'll accept this premise.
> a good thing since Emacs is moribund
And here we part ways.
You might be living in a bubble.
> A highly programmable, cross-platform editor with zillions of extensions/modes that support all sorts of languages and environments.
Agreed; I think you're actually underselling how helpful it is that it's apparently a lot easier to get started with than emacs or the vi family. Power tools with a lower learning curve is a good thing.
> People complain about its resource requirements and performance, just like they did with Emacs.
And they're right to do so, especially with Moore's law wearing thin. Besides which, emacs (and n/vim, for that matter) are still around, and are just as functional in a much smaller resource footprint.
> Vi(m) users are the natural enemy of VSCode, just like they were the natural enemy of Emacs, continuing their long proud tradition of being wrong about everything.
LOL, that's... semi-fair, even if you're on the wrong side, of course;)
> I think that's roughly where it fits 'philosophically'.
I think it's fair to call VSCode "EMACS but with JS", but I think you're really glossing over the issues that it has in practice; maybe with a decade of maturation it'll be on par, but today I would argue that it is a resource hog, and still suffers from some poor design choices (such as letting extensions trample eachother, per the upthread discussion).
The difference between VSCode and Emacs is the difference between an extensible editor and a software omnitool intended to be extended, shaped, and refined as you work with it. Writing short programs in Emacs Lisp, seeing their effects immediately in the live editor environment, and then (should they prove generally useful) refining them into full-fledged modes or commands is quite a bit different than writing a packaged extension.
There is, still, nothing like Emacs in the editor world today. As much as Visual Studio Code gets right, it has a long way to go to get within spitting distance of Emacs in terms of adaptability and power (to say nothing of resource consumption).
If it work for you good, if not, fine. Just don't get crazy about it. It's just an editor!!
Why do you think that Vim users were/are wrong about everything?
But I think Vim bindings in an IDE or Vim with a LSP plugin is the killer combo.
The alternative used to be writing code over VNC (not fun!), but we’re now moving towards VS Code Remote. I don’t see myself changing to it anytime soon, though.
e.g. Would anyone take a plane that has modal cockpit buttons?
The big thing that classic vi got wrong with modes from a usability perspective is that changing modes is mostly invisible. In vim, however, you can configure it to change the cursor shape in different modes, and this is a pretty effective cue. (It's also the default behavior in gvim.)
(But ok, thats maybe just me - thought this is a common experience, and I just wouldn't like to sit behind a pilot doing the same...)
- Has plugins for anything.You're doing C++, just install C++ plugin and you're good to go. Want vim key bindings there's a plugin for that as well. I use a plugin that can scrape competitive coding websites and automatically create tests for a problem.
- Git, snippets, etc all modern IDE features built-in.
- It is also found on many websites as an editor.
- Since it's electron. System requirements are on the higher end.
Idle, it takes up a third of a gig of RAM on my laptop. Language server extensions are responsible for the majority of the load users encounter. That's certainly a good 2-3 times more than Sublime Text, but it's not going to be a deal breaker for a majority of people.
sharing part of OP's sentiment. in fact, i flipped the table a few weeks back because an extension downloaded a tool to my system and guess what? the installation got stuck. and guess what? my text editor hung!
all i wanted was to edit text. i didn't even ask for an extension. i was presented with one that supposedly would make my text editing experience better.
* Tons of quality extensions, incredibly easy to install and manage
* Good color schemes
* ssh extension - remote vscode with all your plugins, themes, etc. with basically zero setup
* integrated terminal
I have no doubt that you can get a better vim setup, but getting vim fine-tuned takes a while for me and figuring out what I like. VSCode is convenient and easy, and works on everything, no suprises. Don't have to worry about fonts, terminal colors, config files, etc. I do think the vim plugin for VSCode is garbage compared with the terminal.
The worst behaviour of any editing environment is a lagging keyboard response.
In this COVID-19 era I've found myself working remotely over VPN and on some occasions the response times become very slow.
The most noticeable observation for me is how frustration writing code becomes whenever my editing environment slows over that lagging VPN.
Tasks that are normally subconscious suddenly turn into mental challenges as you find yourself constantly checking if these subconscious actions actually complete.
This is using a real neovim instance rather than emulation, and performance is excellent for me.
This issue is described in the link but I thought it deserves highlighting
On Mac/Linux I just use neovim with coc, which works beautifully.
I just switched after using vs vim and got much better performance.
I had neovim installed anyway for the EX commands