History and Effective Use of Vim
begriffs.com
begriffs.com
If you abandon the urge to pimp out your Vim with a billion plugins, and just use it raw, it's a kind of editor Nirvana. Let go of your desires and live without want :)
Of course, that's just me. I understand why someone would want to turn Vim into their personalized powerhouse editor with IDE powers, with their .vimrc a 'git pull' away.
But I've learned to live with the humble defaults, and it's made life easy.
Though I really do like having the Capslock key remapped to escape.
Then you can easily use ctrl with your left thumb.
Now I type at 100wpm and using Vim gives amazing productivity.
nvi had more direct lineage to true vi, Keith Bostic was in the Bill Joy headspace, but it kind-of got stuck. Vim diverged in ways which used to annoy me but I've come to accept.
I won't mention "the other editor family" here but it is interesting to see the things in that one, which I miss in this one (for me at least) which are principally the ability to cut-paste regions, and a set of things which became screen and tmux. Now there IS screen and tmux, that matters less.
Not having 2D region cut-paste is a small price to pay for the joys of a modal editor.
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 < \ |
11101 GS = ] }
11110 RS > ^ ~
11111 US ? _ DEL 011 010
0000 0 SP
0001 1 !
0010 2 "
0011 3 #
0100 4 $
0101 5 %
0110 6 &
0111 7 '
1000 8 (
1001 9 )
1010 : *
1011 ; +
1100 < ,
1101 = -
1110 > .
1111 ? /
² https://catonmat.net/images/why-vim-uses-hjkl/lsi-adm3a-full...
My hate for the key came years before I thought about the possibility of remapping it. Similarly, I hate the F1, a key that when accidentally pressed on some windows machines inside programs like excel can steal the focus and leave the computer unusable until it loads the useless help sidebar (when all I wanted was hitting the F2 for editing a cell content).
You can:) https://vim.fandom.com/wiki/Map_caps_lock_to_escape_in_Windo...
If you don't have admin then you'll need to launch it every boot since you can't put it into the startup folder.
To get to the startup folder, open the start menu, right click on an application (might have to be a windows-included app, like Edge, instead of a 3rd party one), and do 'open in folder', then go up to the Start Menu folder if necessary and then into the startup folder. Google says the path of that is this, but I haven't verified:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
Programs / links in there get autorun at boot :)
I haven't tried it but it appears there's a user-specific startup folder which might work without admin: C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
This is a bit older than my current bindings, but this does 3 useful bindings
https://github.com/keithn/vsvimguide/blob/master/vsvim.ah
CapsLock = Esc
Alt-J = Down Arrow
Alt-K = Up Arrow
this is super useful in non vim editors that support vim bindings, and the browser with vimium. The arrow keys are for where you get a dropdown list and don't want to touch your arrow keys. In Visual Studio where I use vim keybindings ( using VsVim ) a lot of refactorings / auto complete gives dropdown options and this gives an easy way to select them without leaving your homerow.
https://catonmat.net/images/why-vim-uses-hjkl/lsi-adm3a-full...
A side benefit of this is that F5 is mapped to refresh for a lot of apps (Firefox, for one) so I can hit capslock to refresh a page.
caps+(any other key) mapped to ctrl-shift-command-option+that key(useful to bind to extra shortcuts in an app).
a single just caps lock press alone bound to escape.
and finally right shift + caps lock is bound to toggle caps lock on and off.
works pretty well for me for a long while now.
karabiner elements on macos lets you do all that with "complex modifications" though the config is a bit dumb to do manually as they expect you to download configs from the web.
Whenever I resume a Vim session (from another window/terminal), I have a habit of automatically pressing the (Escape) key to ensure I'm in Normal mode. However, every now and again, I have to use Vim on someone else's computer and muscle memory would cause me to press CapsLock instead of Escape. Then pressing 'h' moves the cursor all the way to the top of the screen instead of one space to the left, pressing 'j' joins the current line to the following one instead of moving the cursor, etc. Because I'm used to typing normal mode keys in quick succession, I've already entered 4 or 5 normal commands before I realise it's all going horribly wrong. I press 'u' a few times to undo the craziness but successive presses of 'U' only undoes the previous Undo action!
In the end, I retrained myself to use Ctrl-[ which isn't quite as convenient but does work on all platforms I've had to use.
But sometimes I hit the real Esc key out of habit :-)
I've been using vi[m] on an almost daily basis since about 1989...wow, that's 30 years.
In those decades, I have resisted putting anything in my .vi[m]rc except:
set tabstop=4
set expandtab
set shiftwidth=4
set shiftround
That's it. And I agree with you, it's a very happy place for me.
Same thing but start with the biggest vim config you can find.
Specifically, I can't tolerate the tab key actually putting a tab character in. And I like four spaces per tab.
set hlsearch
I'm not working with Latin-1 files.
* `encoding` is what vim uses internally -- the way buffers and registers are stored in memory. Default value is latin1 as you mention, but it will also pick up on the $LANG environment variable. It's more effective in general to set that variable than directly tweak `encoding`. (Mine is en_US.UTF-8 due to my locale.)
* `fileencoding` is the encoding for the current buffer on disk, how it will be read and written. It is translated in memory to `encoding`. Thus you can manipulate files in encodings other than the one used in-memory. (Although if encoding was latin1 I'm not sure how well the round-trip would go.)
* `termencoding` is how the buffer will be displayed to the screen and how the user input will be read. Once again, it can differ from encoding, and will be translated.
* `fileencodings` is an ordered list of options to try when opening a file. Default value: "ucs-bom,utf-8,default,latin1" when encoding is a unicode value.
If you were editing Japanese text, for instance, choosing UTF-16 encoding would actually make vim use less memory than UTF-8, and would not affect the fileencoding used on disk either.
so I've saved my .vimrc to a gist and I just curl it every time I remote into a new environment
https://gist.github.com/airstrike/e361d94dbe4bb90f4fe6ff4418...
When I started using vi on a Sun machine in ~1986 or so, I was an expert at 'edlin' (if there could be such a thing) because it existed on every DOS machine. I learned vi for the same reason: It not only ran on everything, it was pretty much guaranteed to be installed on everything.
I hated it, as I was used to many other 'visual editors' that were modeless, more like emacs. The first Apollo editor was my favorite.
But in those days, installing an editor was a real task, so I went with what was there. Now it's in my fingers.
Although on the (fairly frequent, because busybox) occasion I have to use REAL vi, I'm flustered when I type capital-V to get a visual line buffer...
[0] https://github.com/airblade/vim-gitgutter
[1] set colorcolumn=80 textwidth=79
[2] https://github.com/stefco/dotfiles/blob/master/linkfiles/.vi...
[edit] Just want to add that I 100% agree that erring towards vanilla vim is a great idea; I used to use emacs and switched to vim precisely because the starting point fit my use style far better than vanilla emacs.
It is less buggy and doesn't refresh until you save, which I find to be less distracting.
Likewise I keep Nerdtree closed until I need it and it opens on the right. While VSCode, old Textmate, etc has it always visible and on the left side.
Your parent (https://news.ycombinator.com/item?id=20481729) does say that:
> > Of course, that's just me. I understand why someone would want to turn Vim into their personalized powerhouse editor with IDE powers, with their .vimrc a 'git pull' away.
If you want "personalized powerhouse editor with IDE powers" you are FAR better off going with Emacs/Evil.
The Emacs plugin ecosystem is way ahead of Vim.
Plugins are clean, stable and compose well together. That was never my experience with Vim.
Also unlike Vimscript, Elisp is pretty clean useable language that many Emacs users actually learn. I'd bet the vast majority of vim users never get past step 1 on learning Vimscript?
Emacs/Evil for the workstation and clean Vim for the random server side work.
vim scp://remoteuser@server.tld//absolute/path/to/document
:help netrw-start
I have yet to see something as powerful as tramp for this.
I don't get why the top comment on all vim threads is always recommending using poor defaults your whole life so you can avoid learning to configure it or avoid a second of confusion when you're ssh'd somewhere.
Maybe everyone else besides me spends all their time ssh'd into random servers.
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.
Making 1% of 1/10 of 1% more effecient seems like a curious optimization.
But I'm not really familiar with netrw other than just:
:e scp://host/path/file
On vanilla vim if you :e scp://host// you should get the built in netrw browser working over scp.
Incidentally one can mount a remote filesystem via ssh and edit the files as if they were local with any editor.
With Emacs you can skip a step and directly point your editor to the remote file via tramp.
(Or anyway, that was the case until recently when I switched to evil-mode. I'm totally helpless in default config emacs.)
The reason vi(m) is awesome is because it's everywhere and it's (pretty much) the same.
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 happen to have to work temporarily on.
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)?
It's not like using them will make you forgot the basic commands, movements, etc, to use vim in some unknown remote machine.
And it's also not like you should optimize for the random remote machine you'll get in, and not where you spend hours programming every day.
So unless one is a sysadmin and has no real "main" machine he uses vim in, this makes no sense to me...
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.
Since working on a foreign machine usually only happens when something’s broken, it’s already a stressful situation— my tools not behaving the way I expect won’t help matters.
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+ years of your career to use a nice environment, and it doesn't take much time "setting up and tweaking" to get non-internal tools like NerdTree, linters, git gutter, etc working. More like a week or so, on and off.
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.
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.
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, and see zero evidence that this hampers my productivity in any way.
Built-in file searches are good enough for open files, and grep/git grep do well enough for other files.
Linting should be part of your build process. There's a benefit to it being a bit painful for linting to fail, because that negative reinforcement causes you learn the linting rules and start writing pre-linted code.
You might disagree with me that these benefits are minor, but that's only looking at the benefits: let's look at the costs of "optimization":
First, there's the bugs in plugins and bad interactions between plugins. Very few plugins are written to any sort of reasonable QA standard. I've pair programmed with a lot of devs who use highly custom vims, and without fail, they've got bugs in their configurations that are far more distracting and impeding than any minor inefficiencies in the default configuration. Say what you want about the default configurations, but I've not found any bugs in them in years of using them.
There's also simply the time spent configuring. At one time in my life, I spent hours trying to get things just right in my configs. The results were pretty mixed--a lot of times I ended up not liking the changes I had made and reverting them.
There's a bit of hubris involved in believing you can do better than the defaults. Instead of looking at the settings as the problem, consider the possibility that your knowledge is the problem. It's likely that there's a good enough way to solve your problem in the defaults, and you simply don't know or grok it yet.
When I first started learning vim, I thought it was kind of stupid--everything seemed way harder than it needed to be. But once I actually grokked the tool, I realized that my initial impressions were the stupid ones. A lot of problems I've run into over the years with vim are like that--the problem wasn't that the default vim didn't solve my problem, it was that I didn't grok the solution which was easily assemble-able from the vim skills I already had.
A programmer I really respect has a background process which watches file edits, internet usage, and a few other things (i.e. VLC) and automatically tracks his productivity. His process marks time spent editing Emacs configuration as wasted time, and I agree. Although that might be because it's Emacs configs rather than Vim configs. ;)
Assumption 2: Text entry is a significant bottleneck compared to other areas of your process. In backpacking, there's a saying, "Don't save ounces when you can save pounds." The idea is, don't optimize the weight of your lightest things, i.e. your stove and water bottle, when there are still big optimizations to be made on your heavier stuff, i.e. your big three (backpack, sleeping bag, tent). Configuring your editor is almost always an attempt to save milligrams.
Frankly, once you reach a certain proficiency with an editor that's automatic enough to just get out of your way, editing becomes a subconscious process, and you can be thinking about other things while you edit. I think some people believe that they think of what to write, and then edit it in, and any slowness in editing is preventing them from thinking of what to write after that. I don't think that's how the brain works--if you don't have to think about editing, then you don't have to finish editing to be thinking about the next thing. So the best thing your editor can do for you is to not make you think about it consciously. The more complicated you make your editor, the less likely this is to happen. The power of vim is that it lowers a lot of more complex edits to the subconscious level: swapping two lines is three keystrokes, so it's a simple enough process that I don't have to think about it.
Once you reach a certain level of subconscious-ness with an editor, editing simply isn't the bottleneck. I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim, but they could come up with the solution to the problem in their head faster because they're more proficient with idiomatic Ruby. If editing really is the bottleneck, the problems you're solving are quite easy for you, and you could probably get paid a lot more if you took on harder problems!
And that's just looking at the process of implementing features! There's a lot more to software development. I've yet to work at a workplace where requirements gathering and keeping shareholders informed weren't much larger opportunities for optimization than my editor configuration.
Like all rules, this has exceptions. This is sort of a good "exception that proves the rule". Yes, PEP8 compliant Python development requires you make a few-line change to your .vimrc. My .vimrc contains this:
" Set tabs to width 2.
filetype plugin indent on
set shiftwidth=2
set softtabstop=2
set tabstop=2
set expandtab
" language-specific settings: tab width is 4 for python
autocmd FileType python setlocal shiftwidth=4 softtabstop=4 tabstop=4
But it's not. In a modern editor, swapping two lines is ctrl-shift-up for swapping up, or ctrl-shift-down for swapping down.
Vim isn't that much more powerful any more compared to modern code editors, it's just weirder.
> I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim
So were you a faster typer? How was it faster?
I find there's two points that get me speed in a code editor: Language specific shortcuts (like go to definition) and multi-cursor editing for editing formulas and the like.
But I'm not sure if Notepad++ has multi-cursor.
I'm not sure if vim does, either? I know you can do stuff whose result is very similar to as if you were multi-cursor editing, but do you actually get intuitive methods to place multiple cursors in various ways and then interactively edit what's there while seeing it change?
Because that's no longer a "nice to have". There's a huge difference between formulating an incantation in your head firing, and seeing if the result is right--that gets really complex with multiple edit points--and doing it interactively. You actually see a block of code grow and unfold interactively as you edit it. And it doesnt involve regular expressions :) (which are cool, but almost never fail to take my mind completely off the problem at hand, I only benefit if it operates on a pretty large chunk of text)
Sure, if you really hate your hands. ;)
> So were you a faster typer? How was it faster?
Maybe I just was a faster typist. I don't know. It doesn't really matter to the point: if your text editor gets out of the way enough that text editing isn't your bottleneck, then all time spent optimizing your text editor usage is completely wasted. My argument isn't "vim is better than Notepad++", my argument is "vim in the default configuration is good enough to not be a bottleneck". Notepad++ may be good enough to not be a bottleneck either--I haven't used it enough to have an opinion.
> Language specific shortcuts (like go to definition)
I would argue that this is more of an IDE feature than a text editor feature.
> multi-cursor editing for editing formulas and the like.
I'm not sure what you mean here. There's two things I do in vim which might be what you're talking about: splits so I can be in two parts of the same file at once, or splits where I have a REPL open and am editing fragments in one half of the screen while running them in the other half of the screen. But if you're talking about something else, I'd like to understand it so I can learn how to do it in vim. ;)
The amount of time I spend in Vim not customized is negligible, and I can always hit Esc in those cases with a not even in the ballpark time saving over losing snips and all the custom plugins.
The added benefit to becoming proficient with default configuration is that it is really easy to upgrade to a new computer and start from scratch.
And of course with vim, the benefit is the ubiquity when using ssh or docker or VMs which typically use the defaults.
Well you can also invest the small amount of time to type in:
:imap jj <Esc>
I also decided to invest some time to move to vim + tmux instead of using gvim and now that I'm used to the extras I get with tmux (yep, terminal support in vim 8 is nice but not as flexible), I think I can't go back!
When I started my career, my mentor was an emacs user, and the reason I started with emacs. I became very proficient with the editor, learning how to handle multiple buffers, window splits, rectangle selects, etc. At that time, I didn’t know vi. Until I started working on another project, where the project manager made a statement to me that started my migration to vim. I was logged into a machine that didn’t have emacs, and I was complaining about it. “Just use vi”, he said. “I don’t know vi”, I said. Then came the statement that stuck with me, “Son, you got to know vi just enough so you don’t look stupid.”
So I learned vi, just enough to not look stupid, and eventually, as proficiency set in, turned to vi more often than emacs.
Now vim is my primary editor, and I can use emacs just enough to not look stupid. ;)
Back to defaults. I customize my vim with colorized syntax highlighting, and several plugins. But at its core my vim is still default with respect to key bindings. These are the defaults that matter. If you leave key bindings alone, then the core of vim use is identical anywhere you use vim, with or without your personal vimrc. You can a make “stick to the core defaults” argument for just about any editor. Just keep the core defaults, and customize away on systems you use daily. Then when you use the editor without your personalizations, the editor still behaves as usual.
My editor life is also easy, but with some more creature comforts for daily use.
Put that on a t-shirt.
Reconfiguring means trouble when, for instance, helping a colleague or teaching someone, as well as the overhead whenever the configs are lost.
Back in the day when I was a Unix admin, we often worked in full screen terminals and when editing a config file didn't like having to close the vim instance to go look at something, so learned about this little gem:
:sh (go back to shell and do your thing and leave vim running)
Ctrl-d to return to intact and running vim instance.
As an aside, if you decide to use nano to edit config files, make sure you use nano -w (no wrap), otherwise you may find yourself with a non-bootable OS instance.
I haven't used many esoteric environments, but wikipedia says it "exists in most modern Unix shells" and the timeline for first adding it was the late 70s early 80s.
:! ls -a
In nvi (at least), one can also open a buffer and :script to run a shell inside vi and have all the yank/paste/navigation/all-the-things features of vi. Mind you need to i[nsert] or a[ppend] after the prompt to issue your commands.
https://www.youtube.com/watch?v=eX9m3g5J-XA
Mainly the idea is to not try and learn everything about vim, but instead pay attention to how you use it, and find things that are inefficient or could be easier, and then go figure out how to make vim do that thing more efficiently.
The courseware runs entirely in the browser; gives great feedback; and helped me level up in a jiffy.
Such that I have no qualms mentioning it here.
I remember learning a fair amount from it when I read it a few years ago (and should probably read through it again at some point).
This was misguided and after a year of wasted productivity and wasted time fiddling with plugs and dealing with broken stuff (surely by my own hand) I switched to a professional IDE and I rapidly became a much better developer.
I use vim constantly now but in it's most plain vanilla form, for the purpose of editing files when logged into Linux systems. That's all I use it for.
I really wish however that every Linux system had a clone of the old DOS edit command which was beautifully simply and straightforward and met most needs highly intuitively.
As a sidenote: can I just say that PyCharm is an incredible IDE and I can recommend it heartily to anyone. If your job is programming then it is many times over worth paying the money for the professional edition.
Excellent for editing config files through the terminal.
My main vim plugins for this use case:
* go.vim * nerdtree * git-gutter * YouCompleteMe * syntastic + flake8 * black.vim # python equiv of gofmt
This is only for my workstations. I prefer vanilla configs for servers.
The nano editor experience is pretty close to the old DOS edit feeling.
It IS much better than when I tried it. It parses your vimrc with and matches simple patterns to support the subset of features it does support but it doesn't really have an interpreter although one was discussed
https://youtrack.jetbrains.com/issue/VIM-669
Which means no plugins for example or complex viml. Presumably this would simply be ignored not broken.
Another approach for a different environment that seems more interesting https://github.com/lunixbochs/ActualVim I don't use sublime so I can't report on how optimal it is the idea of using an embedded vim instance is certainly interesting.
Vim defines an ergonomic set of rules for text navigation and manipulation, often implemented by very simple key bindings. This is wonderful.
The Vim editor implements all these rules, but the Vim's plugin ecosystem is a disaster. Hacks pile upon hacks. Noone understand Vim scripts. Vim scripts are easily broken and do not interoperate well with other scripts.
These set of rules can be easily implemented by other editors, as evidenced by many IDEs supporting Vim key bindings. Although these editors may not support all the above rules, they are pretty close (see the evil plugin in Emacs) and can replace Vim in daily usage.
The editor war is over. Vim's keybinding is superior. But the longevity of a text editor lies in its extensibility. For this, Emacs wins in the long run.
vscode-vim caused odd performance issues, and I encountered significant bugs with the undo stack (namely hitting 'u' would sometimes take out the last 10-15 changes instead of just one). IDEAvim would randomly go completely unresponsive for me, sometimes requiring just re-opening the file and sometimes requiring a restart of the entire IDE. And last I checked the Xcode plugin requires re-signing the entire binary with a self-signed certificate because the new plugin system won't support modal editing.
I was quite happy with neovintageous in Sublime, as well as Sublime's excellent performance in general, but no matter how many plugins I installed it could never seem to come close to the smarts of the other tools I was using.
Ultimately I just arrived the the conclusion that I'm never going to be happy with any editor and decided to make the best of what I could with a consistent set of keybindings across the tools I use.
That said, every time I edit my hosts file or something on a remote server and reach for vim, I wonder if I made the wrong choice. I'm really hoping Language Server Protocol becomes the standard and we reach the point where it no longer matters what editor we use.
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.
- QT Editor - Eclipse - IntelliJ - Visual Studio - VS Code - XCode
At the moment I mainly use VS Code, and I'm still editing much faster, despite the issues (occasional undo hiccups and error messages).
I'm pretty broken by Vim. I don't really want to invest the time to get really good at a non-modal text editor.
Disregarding color schemes here is my list:
* FZF
* COC (it provides a lot of QoL, functionality of modern editors with it's plugins using an easy seamless yarn add)
* Sandwich
Very few customizations. Mostly vanilla.
Regarding colors, I love to try new ones all the time and my current is scery followed by Gruvbox, and Dracula because they work in Terminal.app and iTerm. They also look nice / easy-on-the-eyes. My friend at work has a thing for Nord and another loves Monokai Pro, but apparently the author wants money for it...? Which seems... different.
Host * !github.com
RemoteCommand echo -e "syntax enable\nset ts=2\nset sw=2\n" > ~/.tmp_vimrc && bash -c 'set -a; vi() { vim -u ~/.tmp_vimrc "$@"; }; set +a;bash -l'
RequestTTY yes
It's possible to just curl or scp something in place via RemoteCommand above, or `source: https://foo.io/vimrc` but my security paranoia lead me to this instead.
The URL you curl could be a GitHub blob URL (theoretically immutable) but if you check the hash you’re not trusting GH for anything other than availability.
However, recently I took a liking to Visual Studio Code (with VIM bindings of course). Yes I know, it's terribly bloated and consumes RAM like nobody's business, but the Browser DOM arguably is the successor of terminal emulation in terms of ubiquitous interfaces, and VSC does use the additional power quite smartly. There are graphical hints and tweaks which are next to impossible to achieve in a terminal emulation.
I'll still use VIM all the time, especially remotely. But VSC does provide similar extensibility. I somehow wish there was something like VSC, based on web/electron, but more like a Texteditor, less like an IDE. And preferably not controlled by a huge corporation.
1. Multiple cursors!! (and how easy is to use them)
2. Real-time preview of regex search
3. Package Manager (easy installation and discoverability of plugins)
4. Jump to file, jump to function, jump to css selector.. (ctrl+p, ctrl+r, using fuzzy search)
5. Project tree in small font (many files at sight)
Edit: Here there is a bunch of good stuff: https://medium.com/@huntie/10-essential-vim-plugins-for-2018...
Doesn't vim have this by default these days?
set hlsearch
set incsearch2. Exists built in, but need to enable options
3. Exists if you install a plugin manager that has those features
4. Exists via plugin
5. Exists via plugin
>
> 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).
There is this page:
https://sites.google.com/a/bostic.com/keithbostic/vi/
Where if you download the Nvi archive, you get 1.79 from 1996.
In the tarball's docs/ directory, there is a changelog which goes back to 0.92 -> 0.93 (Mon Dec 20, 1993). 0.94 went to 1.00 on January 10, 1994.
4BSD (same as 3BSD) had the original vi (at version 3.1). You can see the sources at TUHS.
Fun fact: AT&T adopted vi in System V UNIX, and advertised that fact without crediting UCB as required by the BSD license. So when AT&T sued, USB countersued, which is why AT&T settled for merely removing UNIX code from future releases.
Looks like Vundle has an MIT license. rip off usually implies something negative or dishonest. Copying MIT licensed code is a normal and encouraged activity.
http://www.gmarik.info/blog/2014/why-i-stopped-contributing-...
I've been using it for > 10 years now but I still find myself learning (and sadly forgetting) new features when reading articles like these.
[1] https://github.com/vifm/vifm
https://www.amazon.com/Ed-Mastery-Standard-Unix-Editor-ebook...
At 120 lines, I consider my .vimrc quite light.. Although I'm not sure what others will think.
But I'm so used to vim + tmux now, it's hard to imagine working with something different.