Shameless plug: A few days ago a write a quick reference for Vim too, checkout https://github.com/p1v0t/Doctor
History and Effective Use of Vim
181–190 of 226 posts
Re: History and Effective Use of Vim
#182Earlier quoted context omitted.
> After years of a love/hate relationship with Vim (I love what it does, but have configuring it), I had an epiphany: by sticking with the defaults, whether they are my preferred choices or not, I can instantly understand how to use Vim in any environment. Which I've never found much important. If you know Vim basics (modes, basic commands, movements, etc), then you can use vim in any environment that you SSH to or h…
> But why wouldn't you want the Vim on your main driver laptop, which you use every day to not have a nice custom setup, and some good third party plugins (e.g. file search, linting, etc)? There are two assumptions I think you're making here: Assumption 1: You can do better than the defaults enough to justify the costs of optimizing. I use a pretty much default vim configuration as my primary development environment,…
I have a specific counterexample: softtabs and tabstop. vim uses tabs by default I have to be conscious of when to use tabs vs spaces. With some configuration to detect it by file type, this (for me significant) overhead is removed.
Re: History and Effective Use of Vim
#183Earlier quoted context omitted.
Nah, I've seen people downloading their preferred configs right to the production server, because they, understandably, feel more comfy with that. But, it may not be for everyone. Where I work, we are in the process of reaching some compliance targets, and all this downloading unknown stuff from unknown servers is out the window. For the best, I think.
People need to stop editing directly on servers. Vim's netrw can write out over scp, use your configured vim on your desktop to edit the files on the server.
The problem is browsing files, for me. I can't use fzf, nerdtree, nnn.vim, whatever. I much prefer sshfs and treating the remote file system like a local one.
But I'm not really familiar with netrw other than just:
:e scp://host/path/file
Re: History and Effective Use of Vim
#184Earlier quoted context omitted.
I am right there with you. I did the same thing, and now when I jump into Vim from anywhere, it's so much easier. Though I really do like having the Capslock key remapped to escape.
I much prefer mapping caps lock to ctrl. That reach is much more difficult for me
Why not both?
Re: History and Effective Use of Vim
#185Earlier quoted context omitted.
Reading about that undo bug gave me a knot in my tummy. Damn.
If it is any consolation, as a VSCodeVim maintainer, me too. We had some issues at times, a lot of them have been resolved, but that first impression is impossible to get back. Contributions have dwindled from people and I feel like it needs another kick to make it perfect.
Thanks for your work!
FWIW, since recently (can't tell you which version, but maybe a week or two back), my editor has become real unresponsive (2-5 seconds delay when I switch from Insert mode) and if I type before it switches, keystrokes get inserted as text.
Re: History and Effective Use of Vim
#186Earlier quoted context omitted.
> No, but time I spend setting up and tweaking a custom environment is time I could be spending internalizing the tools that exist everywhere and work well after the learning curve. You should be able to "internalize" the tools that "exist everywhere" in a year or two are most. If you start using vim at the university you would be done internalizing its internal tools when you graduate. You then have the rest 30+ yea…
> You should be able to "internalize" the tools that "exist everywhere" in a year or two are most. If you start using vim at the university you would be done internalizing its internal tools when you graduate. Absolutely not. I have been using vim for almost a decade at this point and still am internalizing new vim skills.
>Absolutely not. I have been using vim for almost a decade at this point and still am internalizing new vim skills.
One decade? How long can this go on? Two decades? Three? If one is in the middle of their professional career before they've mastered all the "vim skills" (or even more so, the more numerous) Emacs skills, then they'll never gonna master them all in time to matter anyway.
And the point of internal vs third party is not if internal are numerous enough, but if they're productive, convenient enough. Internally vim has tons of features, but it doesn't have a linter, for example.
In any case, things one still discovers "a decade in" are not really an argument for not setting up a good main driver vim environment with more than built-in conveniences. Those wont prevent you from learning vim built ins, and you could get immediate access to features, and in a more convenient form, that could take you a decade to chance upon as built-ins.
Re: History and Effective Use of Vim
#187> Some of the clones: > > nvi - 1980 for 4BSD > [ ... ] > elvis - 1990 for Minix and 386BSD This is incorrect; nvi is in fact a mid 1990's fork of Elvis, worked over for better POSIX compliance by Keith Bostic. > vim - 1991 for Amiga Though that was the first public release, Moolenaar had worked on it since 1988. It was based on Tim Thompson's Stevie, which had been released, in 1987 (noted in the table).
Thanks for the correction, can you give me a more precise date for nvi? I can update the article.
Thank you for putting this together. The writing quality and comprehensiveness are excellent. It's amazing to think that vim's lineage stretches back over 50 years (older than UNIX, display terminals, and Apollo 11!)
Re: History and Effective Use of Vim
#188Earlier quoted context omitted.
On a lot of machines, C-[ (control + left bracket) maps to escape. But some programs don't seem to acknowledge this? Like in firefox, doing that changes tabs, but in Emacs + evil mode it's how I "ESC."
There's an interesting reason for this related to the ASCII table and bit shifting, but I can't find a description of the exact mechanism for it. H and [ are in the same column as escape and delete respectively, and control shifts the bits in the character codes by some amount. Maybe someone smarter than me can elucidate.
This table might help explain:
00 01 10 11
00000 NUL Spc @ `
00001 SOH ! A a
00010 STX " B b
00011 ETX # C c
00100 EOT $ D d
00101 ENQ % E e
00110 ACK & F f
00111 BEL ' G g
01000 BS ( H h
01001 TAB ) I i
01010 LF * J j
01011 VT + K k
01100 FF , L l
01101 CR - M m
01110 SO . N n
01111 SI / O o
10000 DLE 0 P p
10001 DC1 1 Q q
10010 DC2 2 R r
10011 DC3 3 S s
10100 DC4 4 T t
10101 NAK 5 U u
10110 SYN 6 V v
10111 ETB 7 W w
11000 CAN 8 X x
11001 EM 9 Y y
11010 SUB : Z z
11011 ESC ; [ {
11100 FS ^ ~
11111 US ? _ DELRe: History and Effective Use of Vim
#189I'm deep into vim and have recently seen some things that colleagues are doing with VS Code. I have to admit, I'm tempted. But I'm so used to vim + tmux now, it's hard to imagine working with something different.
Can you elaborate? I'm also a vim + tmux user
Re: History and Effective Use of Vim
#190Earlier quoted context omitted.
> You should be able to "internalize" the tools that "exist everywhere" in a year or two are most. If you start using vim at the university you would be done internalizing its internal tools when you graduate. Absolutely not. I have been using vim for almost a decade at this point and still am internalizing new vim skills.
> Absolutely not. I have been using vim for almost a decade at this point and still am internalizing new vim skills. One decade? How long can this go on? Two decades? Three? If one is in the middle of their professional career before they've mastered all the "vim skills" (or even more so, the more numerous) Emacs skills, then they'll never gonna master them all in time to matter anyway. And the point of internal vs t…
> One decade? How long can this go on? Two decades? Three? If one is in the middle of their professional career before they've mastered all the "vim skills" (or even more so, the more numerous) Emacs skills, then they'll never gonna master them all in time to matter anyway.
I think you're mistaken in thinking there's a solution to this problem, or even that it's a problem.
The limiting factors here are your rate of learning and when you stop learning. Continuing to learn well into your career is a feature, not a bug.
> And the point of internal vs third party is not if internal are numerous enough, but if they're productive, convenient enough. Internally vim has tons of features, but it doesn't have a linter, for example.
I have a linter. It doesn't need to be in my editor, and I rarely make linting errors anyway. When I do make linting errors, I want it to be a bit painful so I stop making linting errors.
I'd argue that the bugs introduced by your linter are worse than the problem they solve. And the more plugins you have, the more buggy your system is due to the interactions.
> In any case, things one still discovers "a decade in" are not really an argument for not setting up a good main driver vim environment with more than built-in conveniences. Those wont prevent you from learning vim built ins, and you could get immediate access to features, and in a more convenient form, that could take you a decade to chance upon as built-ins.
Chance across? Don't plugins have the same problem, that you have to wait to chance across them? If you're actively out searching for plugins to solve your problems, you'll find them, but if you just google how to solve the problems with builtin tools, you'll find that too.
Plugins absolutely prevent you from using builtins, and frequently break the builtins to boot. You're probably right about the very basic stuff (i.e. movement, deletion, insertion) but anything beyond that is frequently broken on systems with a lot of plugins.