Hacker News new | past | comments | ask | show | jobs | submit login
History and Effective Use of Vim (begriffs.com)
593 points by begriffs 32 days ago | hide | past | web | favorite | 218 comments



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. Once you get used to biting the bullet and hitting escape instead of jj, or ctrl+c, it just works, everywhere.

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.


>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 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...


> It's not like using them will make you forgot the basic commands, movements, etc, to use vim in some unknown remote machine.

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.


>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+ 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.


> 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.


> 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.


That’s fair enough, I guess. At this point, I’m happy enough with my workflow despite (or maybe because) I don’t know what most of those things do. Some novelists use fancy purpose-made software and others use old-fashioned yellow legal pads; I guess I lean more towards the latter when it comes to software development.


> 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, 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.


> 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.

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)


> 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.

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. ;)


You won’t ever catch me saying that vanilla vim is the best editor out there but it’s sufficient, as are all of the others you named. At some point, the bottleneck becomes thinking up the correct solution and not the data entry. In my opinion, we passed that point at least a decade ago; even if you reduced the amount of data entry effort to zero, it’ll make little difference in my overall efficiency as a programmer.


Exactly, you said it better than I did.


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.


I develop mostly Python for a living, so I'm well aware of this problem. :)

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
So sure, not completely default. But note: the 8 line change I have works without any other changes on every vim install I've come across, and doesn't really change my behavior as a user that much. The people I'm arguing against are proposing installing whole giant behavior-changing plugins (i.e. a linter). I've got a few changes in my .vimrc, but probably fewer lines than even the most basic plugins.


I've taken this approach halfway and only install plugins/config that I can easily do without. Things like git-gutter [0] and a line at the 80th column [1] are great, but I don't depend on them when I log into a remote machine. If I really want some features, I have them somewhat organized in my .vimrc [2]. It's a great compromise; I find that I haven't thought about major editor configuration in a couple of years.

[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.


I would recommend ditching gitgutter for vim-signify: https://github.com/mhinz/vim-signify

It is less buggy and doesn't refresh until you save, which I find to be less distracting.


I've never really understood why you'd want a constant visual indication of changed lines all the time, especially with something bright/colourful on the side. The only time I find that useful is during reviews before committing. Otherwise it seems like a distraction. Vim is great for minimalism.

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.


This is partly a matter of taste, and since I don't find it distracting at all, there's no downside for me. But as far as value added, I find it super convenient. I like that gitgutter gives a quick indication of what chunks I've been working on and lets me quickly navigate between them (without having to remember to mark them/hit ^O) by hitting ]c or [c (I think these are defaults, but I might have overridden them). I also like that it lets you effortlessly interactively stage changes (in case you have a good hunk you want to commit before trying something more experimental out) as well as previews that show you diffs of specific hunks as well as the ability to selectively undo hunks. It also is a great way to immediately verify that a file is unchanged without hitting ^Z and running `git diff FILE` for the file I was editing. It's also an easy confirmation that I didn't accidentally change or break something accidentally. Obviously I run a `git diff` and tests before a commit, but for me, nothing beats seeing my diffs in the full context of the file to confirm that, yes, those were all things I did on purpose.


I wasn't aware of the ability to jump between changes via shortcuts. That seems useful.


Ones that take up space are kind of annoying, I agree. I like IntelliJ's solution: mark with green, or yellow for additions and changes. It's a 1px line next to the line number, and also it's in the "minimap" type of view so you can jump right to where your changes are in a large file.


I haven't had any problems with gitgutter so far, but I'll give it a look! I think gitgutter can also be configured to only update on save, though I actually like the live updating and have never had issues with it (IIRC I set it to wait a second before updating to keep it from constantly running git commands).


I use a bunch of plugins and I've never had trouble remembering the defaults in the odd case I'm unable to use my own config.

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.


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.


How much editing do people need to do on the production server in the context of developing software?

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.


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


This is one of the reasons my preferred implementation of Vi is Evil -- the TRAMP network layer in Emacs does exactly what you want: let you treat any remote file system as local. It even does multi-hop access through e.g. bastion machines. It is great.


I've never used any of those plugins, but the built in netrw has a directory browser that works.

On vanilla vim if you :e scp://host// you should get the built in netrw browser working over scp.


It's unfortunate that in this day and age we still have people who directly access and touch a production server at all, ever. There is zero need.


This sounds nice until you have to debug a crazy error that only happens in production.


Wouldn't this represent 0.1% of your usage? Meanwhile the thinking portion is 99% of the job and the act of using the UI to enact the changes on any editor is the other 1%.

Making 1% of 1/10 of 1% more effecient seems like a curious optimization.


Honestly, if you have to hop on production to debug a crazy error, you have two bugs. The infrastructure being so different on production compared to development or local is a fixable issue. As are any other differences between production and local that make difficult to debug in these special cases. It takes a long time. It's a substantial effort. But it is worth while.


You're quite green, aren't you?


It may seem that way, but no I've crossed that chasm long ago. I've debugged on production more than I would ever care to remember. But in all honesty it is easier than ever to stay completely off of production. It's also extremely cost effective. It's not simple and it is work, but it has never been easier to actually be successful at staying off if production.


Easier then ever maybe but still probably impossible to avoid. It's not that anyone wants to mess up with live, it's more like you don't have a choice.


Really? I haven't allowed people to log directly only a production environment in almost 10 years. There is definitely a choice.


It's not a serious issue for me. I can't download my configs to random devices either. Working on embedded stuff I've usually only got vi, and honestly, the most annoying thing is no `F` binding (which is a default in vim).


Poor undo is my main bugaboo in vi, but I'm usually OK with just :e! and starting over.


If you want portable then yeah empty out your .vimrc and get fluent with vims superpowers as they are.

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.


Use tramp with Emacs and you can interact with remote machines as if they were local. Who cares if the server only has vim, you have Emacs.


+1 for Tramp. You can connect to SMB, ssh, and even docker containers from within Emacs. It's strictly better than using a remote ssh session with vim because you don't need to configure anything server-side. It would be a huge hassle to setup plugins like autocompletion on a remote machine for vim, but Emacs lets you use all your regular plugins while ssh'ing, which is a huge bonus.


Vim can also edit remote files, with its built-in netrw module. It can do ssh, ftp, dav, fetch, http, rcp, rsync.

vim scp://remoteuser@server.tld//absolute/path/to/document

:help netrw-start


But will every other Vim plugin (like fuzzy-finding file browsers or whatnot) work with netrw-accessed files as if they were local? Does it trivially do multi-hop SSH through e.g. bastion machines?

I have yet to see something as powerful as tramp for this.


I agree, and I use both Vim and Emacs regularly. Both great tools with different payoffs.


They're especially awesome together: http://spacemacs.org/


I’m a long time VI(m) user, who started with emacs. I’m proficient in both editors, but use vim as my daily driver.

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.


“Son, you got to know vi just enough so you don’t look stupid.”

Put that on a t-shirt.


Oh, but you should know enough Emacs to avoid such embarrassing situations: TRAMP!


Just a quick note, you can use Ctrl +[ rather than Escape. Saves your fingers from constantly having to reach for that corner.


I bind my CAPSLOCK to ECAPE that way instead of the escape key killing my hand my left pinky finger can just naturally get me out of insert mode by hitting CAPSLOCK.


I used to do this and really enjoyed the convenience.

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.


Do yourself a favor and figure out how to bind caps lock to press for escape, hold for control. I use a programmable keyboard (web search for QMK if you're interested) but there are software options too. You'll never look back and you'll be baffled how you ever lived without it.


i have ctrl-shift-command-option+hjkl mapped to the arrow keys in any app.(works in tandem with the next config so it's just the press of the caps lock key)

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.


On Linux you can use the awesome xcape for this


I actually started binding my CAPSLOCK key to F5, and I have F5 set as a tmux attention key, but I've never had too much problem with left pinky finger hitting escape..

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.


F5 is the Midnight Commander copy key, would never work for me.


That's good for some people, but I have Caps Lock bound to Commmand/Ctrl. The above default key combo works well for me since that way only my right pinky leaves the home row.


Am I the only person who actually finds Esc easier than C-[ or Caps Lock? Maybe it's just heavy muscle memory at this point, but I've been using Esc for years and every time I try to use anything else it just feels clunky.


Esc is often a half height key and is placed in the Function key row. This is quite a stretch if you are touch typing and want to hit Esc while still keeping your index finger on the F key. But you have the same problem with Ctrl. It's sometimes placed under the left shift key, which is a really awkward pinky reach (I think Mac keyboards have the Command key in a slightly better place, but I haven't used a Mac keyboard extensively, so I'm not sure). For me, since I have a Japanese keyboard with a short space bar and an extra key on either side of it, I make the extra key on the left a Tab key, which I hit with my thumb. Then I make the Caps Lock a control key (to match the old place it used to be) and the Tab key becomes the Esc key. The nice thing about that is that it's usually oversized so easy to hit. It's also an easy reach.

But sometimes I hit the real Esc key out of habit :-)


Using the ring or middle finger allows you to hit the escape with very little motion and you can find the home row again afterwards without looking. Try it - usually takes the slightest wrist angling and extension of the fingers.


On my keyboard I need ALT GR for [. On a side note, I'm rather disappointed that the ESC key didn't get updated with modern keyboards. The keyboard vi was designed on had ESC where Capslock now resides.


I despise and hate with passion the Capslock key. On linux I always run setxkbmpap -option caps:escape. I wish the same could be done on Windows. I got used to it so much that I find myself from time to time writing catpital letters when I'm on Windows or foreign setup.

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).


> I wish the same could be done on Windows

You can:) https://vim.fandom.com/wiki/Map_caps_lock_to_escape_in_Windo...


That page mentions the 'uncap' tool which I have been using for a while. It is excellent. Download the few kb executable from GitHub, launch it once, place it in your startup folder, and it just works forever.

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


Hi! Author of Uncap here. I am glad to know that you find it useful. Putting the executable in the startup folder is how I use this tool too.


I use autohotkey...

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.


Yes, technically it's possible, but it is too complex and too permanent to run on every machine and server I log into. Perhaps I should set those registry keys on my own Windows VM though. Thanks for the reference.


buy a keyboard that lets you customize keybindings. my anne pro cost me probably less than $50 and there are many other (better!) choices out there


You can do that on windows, in some way. I've got it setup like that (former caps lock key acts like control), but I don't remember exactly what the setting was.


It's a registry edit, but SharpKeys is a small GUI for editing that part of the registry: https://github.com/randyrants/sharpkeys


Are your sure it wasn't control? I know the ADM terminals were set up that way and they even had the arrows on HJKL.



That's what I do, and lately I've been recommending it more often to others when I hear them complain about the lack of a hardware Esc key on MacBook Pros.


ESC is a much much larger target requiring much much less peripheral attention. Maybe I'm not as good a touch-typist as I like to think I am.


And ctrl+m for newline. Tose two are great to keep hands in the home rows


Yup.

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.


swapping ; and : is a must for me at this stage from sheer muscle memory... trips me up every time i run into a new setup

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...


Pretty much likewise. Actually, I do away with the tabstop=4 these days too -- I've grown to like 8-width tabs.

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...


I also find it important to set encoding=utf-8.

I'm not working with Latin-1 files.


Yes, this is a good idea, although I'd like to note there is more nuance.

* `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.


vim does not disappoint with completeness. (:


The nice thing about these settings (I use the same ones) is that if you're on a machine that's not configured to use them, they take only moments to type.


Other than shiftround, the other three seem rather language dependent (which is why I've cluttered so many files with various vimlines/modelines over the years). Wonder if the editorconfig-vim plugin might be a better compromise "only plugin" approach? Particularly given the growing consensus towards editorconfig across editors.


What made you pick those 4 if I may ask?


Every thousand years this metal sphere ten times the size of Jupiter floats just a few yards past the Earth. You climb on your roof and take a swipe at it with a single feather. Hit it once every thousand years til you've worn it down to the size of a pea.

Same thing but start with the biggest vim config you can find.


I have no idea where it started...I've been pasting those into my .vimrc for perhaps 20 years now, or more. I'm pretty sure I copied it from someone else.

Specifically, I can't tolerate the tab key actually putting a tab character in. And I like four spaces per tab.


set nu


Oh man...I know a lot of people love that, but I just can't handle it. (:


most of those, plus

set hlsearch


Depending on your job there's no reason that you would ever need to use defaults. You should optimize your editor for your day-to-day use case


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


Swap caps lock and escape, then set the bottom row from the left as windows key, alt, ctrl, space.

Then you can easily use ctrl with your left thumb.


If you are on a regular keyboard, you can keep all your fingers on the home row and use your palm to hit ctrl.


Around the time I learned vim I also got myself into the habit of using the opposite hand for Ctrl, the same way you would for Shift. It has pretty much eliminated any need to stretch for a key chord.


That's mechanography 101. I am so happy I got into those courses in secondary school in the 90s. Even if everybody said it was for girls.

Now I type at 100wpm and using Vim gives amazing productivity.



I don't find myself needing to use Vim in random environments enough to gnash my teeth about how it doesn't work as expected. Even for those who do, it's not hard to pimp out Vim while leaving the baseline behavior alone. Any new functionality I add I make sure not to override existing frequently used key bindings.


I go for a heap of plugins but don't remap the things that start off built-in, so I get the muscle-memory for the defaults when I need a remote shell somewhere, but still the useful plugins on my own computer.


This is my philosophy with most software. I expect to get 80-90% of the way with zero configuration and then maybe for some advanced features I’ll touch the config and personalize some things.

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.


I find that the muscle memory for my personal config is keyed off the visual appearance of my preferred color scheme. So I have no problem context switching between personal config and default config, provided the color schemes are right for each.

(Or anyway, that was the case until recently when I switched to evil-mode. I'm totally helpless in default config emacs.)


this +

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.


Maybe this is betraying my ignorance of emacs, but Ctrl-V?


What about dip, di(, and di{? Those have always worked for me, as long as the code is well formed.


Some defaults aren't very usable, although "Debian defaults" are very close. I had the same approach, but lately I've decided to add plugins or configuration to "enhance" and never "replace", and I have never been happier as I'm now with vim.

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!


There's also tpope's vim-sensible but I think nvim took nearly all of them.

https://github.com/tpope/vim-sensible


I do exactly the same thing. It really relieves the stress of working with an unfamiliar environment, and you become that much more effective with stock vim!


My biggest reason to not use the defaults has been keyboard layout. I've bounced back and forth between a version that deeply changed the Vim keys and one that tried to minimally change keys as best as possible. I'm back on the "minimal change" layout preference, but the problem is still "minimal change" is not "no change" and definitely not quite "nirvana".


I want syntax highlighting and correct tab behavior, though, and I use a language that not even Neovim has built-in syntax support for.


This makes sense if you don't use vim as an IDE, but if you do, configurations and plugins are essential. Of course, you wouldn't expect to have a fully configured jetbrains IDE when you SSH into a remote server, but that doesn't mean you can't use one on your local development machine.


> This makes sense if you don't use vim as an IDE, but if you do, configurations and plugins are essential.

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.


I am pretty sure that was edited in after my comment, but it could just be a reading fail.


I would agree, but then I found this: https://vim-bootstrap.com/ and it is sooooo nice. I no longer have to think about configuring vim or managing plugins because it is done. Esp for golang.



I'd take a tremendous hit in productivity if I followed that advice.

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.


I usually stick to this rule almost everywhere, with just a few exceptions for some shortcuts.

Reconfiguring means trouble when, for instance, helping a colleague or teaching someone, as well as the overhead whenever the configs are lost.


I'm the same way, and I hit the same spot with my desktop OS. I don't need any more individualization than I can put on a machine in 5-10 minutes.

The reason vi(m) is awesome is because it's everywhere and it's (pretty much) the same.


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  <   \   |
  11101   GS  =   ]   }
  11110   RS  >   ^   ~
  11111   US  ?   _   DEL


Now split the second column, and you understand the keyboard layout of pre-microprocessor ASCII terminals like the Teletype 33¹ and vi's own ADM-3A²

       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://commons.wikimedia.org/wiki/File:TTY33ASR.jpg

² https://catonmat.net/images/why-vim-uses-hjkl/lsi-adm3a-full...


Right, I was trying to figure out what bitwise operation the control key performed specifically, but my google-fu was failing. Is it key ^ 0b10?


I try to keep it minimal as well, but some plugins are too good not to install for my daily work. TabNine, Auto Pairs, Vim Surround, Endwise, and CtrlP are a few that come to mind.


I tend to only mess slightly with my .vimrc, but I get fancy in my .gvimrc for this reason.


> Once you get used to biting the bullet and hitting escape instead of jj ... it just works, everywhere.

Well you can also invest the small amount of time to type in:

:imap jj <Esc>


Still have to configure fonts. Can't stand the defaults.


Been using vim since 1998 and rarely stray unless I'm typing notes for something unimportant and them I use Nano.

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.


Or just CTRL+z and then 'fg' to go back.


This is one of the many things I learned from the destroyallsoftware screencasts [0] so many years ago. Before that I used vim in a gui (MacVim). Along with moving to tmux this completely changed how I work.

[0]: https://www.destroyallsoftware.com/screencasts


That's what I do in Emacs. I always run it from a terminal (currently using Terminator).


This is exactly what I do all the time and works nicely.


Does that work in all shells?


https://en.wikipedia.org/wiki/Job_control_(Unix)

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.


Job control was first implemented in csh, another Bill Joy invention, although I believe that particular feature was added by someone else.


> :sh (go back to shell and do your thing and leave vim running)

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.


Been using vim for almost a decade and embarrassed to not have known about how to go back to vim after doing `:sh` , so thanks for sharing that. I use tmux all the time so I tend to switch to a pane running bash and `ctrl-b z` to toggle the pane fullscreen


I wouldn't even use nano for typing notes; I'm so used to vim that I don't see why I wouldn't want its powers, even for something as simple as writing notes. I might very well want to reorder the notes, for instance: that's very easy in vim with dd/p. nano might have some Ctrl-key combo that does the same thing, but why bother learning that when I already know vim?


The worst thing is when you start typing Vim commands in programs that are not Vim.


You can also do

    :! ls -a
to execute a shell command and see the results from within Vim.


This video of a talk that Bram Moolenaar (the author of vim) gave at Google in 2007 has some pretty good advice.

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.


To anyone who hasn't tried it - http://www.vimgolf.com/ is probably the quickest and most fun way to take your skills to the next level.


I recommend the book "Practical Vim" too: https://pragprog.com/book/dnvim2/practical-vim-second-editio...

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).


Agreed, it's a great book. Drew Neil, the author also runs vimcasts.org for nice short single lesson videos.


https://vimvalley.com/ isn't cheap, but you get what you pay for.


wow good for them if they're getting people to pay $99. It does look well-designed, but the course outline seems a bit elementary. If anyone is thinking about buying this, you could probably just google the items in the course outline and try watching a youtube video on it.


Absolutely.

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.


yeah, increasing your skill is easily worth $100. Back when I was employed as a developer, I bought all kinds of educational stuff. Now that I'm working on startups, everything's gotta be free.


Is that why Vim costs so much? I kid but honestly I've found software quality to be poorly correlated with cost. Same for instructional materials.


I've never come across this before. Thanks for sharing!


Everyone is missing the most important contribution of vi[m].

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.


I started my programming career determined to be a vim guru and do all my programming with vim.

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.


To each their own! I'm a very effective python AND go programmer / sysadmin who uses vim for most all of my IDE stuff. I've also managed Linux professionally since 2005 and played with it since 1998 so it isn't for everyone.

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.


You can install IdeaVim in PyCharm. I've been using IdeaVim with IntelliJ for 6 years and could never go back to non-vim style editing. This plugin provides the best of both worlds.


Not to be unkind but have you tried actual Vim or adding any functionality to an ide?


Yes I have used plain Vim as a text editor for many years. It's a great text editor. I know it was also used for writing code back in the old days. For working on large modern JVM codebases, however, Vim is a toy in comparison to IDEA. Vim is for manipulating syntax. IDEA has advanced semantic features that will remain far outside of Vim's domain.


Not OP but I’ve been using ideaVim for many years now and I can say that it’s quite good. It even uses my main .vimrc file and handles most of the things very well.


https://github.com/JetBrains/ideavim for any readers interested.

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.


> 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.

The nano editor experience is pretty close to the old DOS edit feeling.


nano, pico, joe, depending on which carrier package you hvae installed. they all have the ^s ^x status bar type interface.


I use mcedit, it is part of midnight commander, usually available as mc.

Excellent for editing config files through the terminal.


I rarely ever use actual vim, mostly when I'm in the terminal. But I have vim plugins for most IDEs I use (VS code, intellij, XCode). It makes editing so much faster. When I have to get by without it I feel as if someone put weights around my wrists. The reason I don't use Vim is because it's frankly not a smooth experience for most languages (unless you fiddle around a lot, and even then I found Ide+vim plug-in superior). I do hope Neovim will solve this, though I didn't test it because the last time I checked windows support was experimental.


After a several month effort to learn vim bindings and use them full-time, I eventually ended up weaning myself back off because the plugins for the editors I actually use all seemed to come with considerable downsides.

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.


You should take a look at language server clients for vim e.g. coc-nvim. I don't personally used one so I can't say what works or not.

[0] https://github.com/neoclide/coc.nvim


I did actually give coc-nvim a try, and while it was effective for JS and Vue (the primary things I use VSCode for), I’m yet to find anything that can convince me to drop PhpStorm or Xcode for their respective specialties. So unfortunately it only solved about 1/3 of my problem.


I use coc-nvim and can attest that it is really good. I used to use YouCompleteMe, and while that plugin is really powerful it's also overly complicated and breaks a lot.


I too have been down this road. I tried Atom for a couple of months, and that turned into a couple of years. I had it tuned into a VERY NICE Vim. I tried out VSCodeVim and got it to be a mostly passable Vim. It sure is pretty though. I'm back on nvim for the time being. Coc.nvim and LSPs make it pretty good. There are definitely rough edges and memory usage is pretty bad with all those plugins, but. I know it, I feel right at home with it. The only other two editors I invested any real time learning were Sublime and Emacs (I did not try to turn them into Vim - but I did end up installing Evil for Emacs later on)

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.


I experienced issues with the VS Code plugin as well, though not as severe as you described. If I had the same issues, I wouldn't use it as well. I haven't experienced any issues ever with IDEA vim. I haven't used XCode in a while, so I can't chime in on the current state of the plugin. My ranking for most stable to least stable plugins I've used would be the following (in case of multiple plugins, I don't recall the exact one, sorry):

- 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 just wanna give my 2c in that after some years using vim I've started using vscodevim and I just love it. Perhaps it helps that it happens to match my vim config pretty closely (surround, easymotion, + language plugins and stuff such as ctrl p that is native to vscode).


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.


If it’s any consolation, Ctrl-R will redo those same fifteen changes, so you won’t lose any work. And the vim extension’s undo history is separate from the editor’s so you can’t really lose any work accidentally.


Yup. I had the same issue with vscodevim which causes me to ditch vscode entirely.


I don't limit my plugin usage on purpose. I will add a plugin if it adds a value I can make use of.

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.


I very recently set out to start bringing my vimrc with me when logging into remote hosts and came up with this.

  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 gets ugly when you get a lot of options in there.

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.


Curl it, check the sha256 of the download vs a hardcoded one and then source it if they match?

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.


Excellent article by the creator of the equally-excellent postgREST. Especially the neato historical material - I didn't know that Vi was directly derived from the ex [and by extension, ed] editor.


I've been using Vim for a couple of years now and I almost can't stand any text editor without VIM-like extension.

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.


There are just so many bugs with Vim implementation in VSC. For example the two undo systems can lose sync and randomly delete half the document.


That hasn't happened to me, so far. But yes, it can be a bit buggy.


I used vim for years, but then Sublime appeared.. although I miss the snappiness of vim, and wouldn't mind to come back. Specifically, I'd miss these nice features of Sublime:

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...


I've grown quite dependent on multiple cursors myself. Supposedly, Kakoune is a vim-like editor with good multiple cursors support.

http://kakoune.org/


Mmm.. I see there are also vim plugins for multiple cursors, like https://github.com/terryma/vim-multiple-cursors ..


I've been using that for years after I switched to Vim from sublime. It has worked just fine for me.


Sublime is really nice, I bought a license for V2. But after a lot of radio silence from the dev, I realized I never want to invest years building muscle memory and becoming dependent on specific plugins only to potentially have it disappear one day. Proprietary software is just not a good option for fundamental tools like a text editor.


I'd say the tradeoffs are different rather than it never being a 'good option'. For me, paying for & using IntelliJ idea for most of my serious work has in practice been an excellent option for many years. It suits me & my working style in a way no open-source editors do. For that I'm trading the possibility that Jetbrains might die, or change its platform in a way I can't live with. In truth this has already paid off for me, regardless of what happens in the future. If I had to stop using it tomorrow it would have been well worth it.


1. Exists via plugin

2. 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


> 2. Real-time preview of regex search

Doesn't vim have this by default these days?


Yeah, I think what they want are the options

  set hlsearch
  set incsearch


Oh, rings a bell.. :P thanks!


I remember the first time I ran `vimtutor` in my terminal. A lot changed since then! Although I just stick with defaults since I have my IDE for my day-to-day job.


Also of note, the first part of https://vim-adventures.com is fun. I expect the rest is too, but I got sticker shock when I went to buy. Probably worth it for someone who doesn't already know vim well, though.


> 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.


OK, I dug something up.

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.


> nvi - 1980 for 4BSD

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.


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!)


I realized why Vim has always felt a little off to me. The primary navigational commands are mostly on the right hand, which as a left handed person feels very weird to me. While Emacs commands favor neither hand (if anything they favor the left with C-f, C-b, C-a, C-e, C-x C-s, M-x, etc). Just a small observation.


You may enjoy a dvorak keyboard. Up and down (j and k) are the c and v keys. Left and right (h and l) are j and p.


Yeah...but I like other people being able to use my keyboard. Besides I already get confused between Windows shortcuts and Mac ones. Can't imagine QWERTY vs DVORAK


It's possible to switch keyboard layouts on the fly when another user takes over.


I don't think I'll ever be able to internalise all the features of Vim.

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.


Shameless plug: A few days ago a write a quick reference for Vim too, checkout https://github.com/p1v0t/Doctor


> Oct 2010 - Feb 2014 : Vundle (Discontinued after NeoBundle ripped off code)

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.


Sorry, the way I phrased that was sloppy. I should have said, "main author abandoned, saying NeoBundle ripped off code."

http://www.gmarik.info/blog/2014/why-i-stopped-contributing-...


Also has a few commits since then. The impression I get from the repo is that it's "done", not "discontinued".


In addition to the [Neo]Vim, I can also recommend vifm[1] - vi-like file manager. It supports vi-like key bindings, similar configuration, and color schemes[2]. Moreover, it can be integrated[3] with Vim itself.

[1] https://github.com/vifm/vifm

[2] https://vifm.info/colorschemes.shtml

[3] https://github.com/vifm/vifm.vim


Just finished reading this book, “Ed Mastery”. I can’t tell if it’s “worth the money” - not sure if learning ed(1) is worth anything- but it’s fun to see the design decisions made way back in the 70s still being present in vim

https://www.amazon.com/Ed-Mastery-Standard-Unix-Editor-ebook...


I'm a React Developer that uses Vim, and whilst I have reduced my .vimrc down a lot since I started playing with vim, I still use about 15 plugins such as Deoplete, tern, ale, fzf, a language pack (I'm always messing around learning new languages), and then a selection of Tim Pope addons.

At 120 lines, I consider my .vimrc quite light.. Although I'm not sure what others will think.


I used to shell into servers a lot and open vim to edit files, so I'm quite comfortable with a sparse configuration. But when I'm developing software, I want features, and these days I spend most of my time doing development. My current setup is I use Spacemacs for development work, but I use a very minimalist vim configuration for quick edits. This gives me the best of both worlds - very quick, responsive editor that I can use reliably and efficiently. And a good development experience that is easy on my fingers.


Don't lead off with the history. #protip


I'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.


The more I use VS Code, the more I want a way not to have to use the mouse anymore.


Do try vscodevim, I made the switch and I haven't looked back. Best of both worlds for me.


Can you elaborate? I'm also a vim + tmux user


There's only one thing I need to improve my VIM experience: a way to set style options (and search paths) for each git workspace. I've yet to find a non-hairy way to do this. Help!


.editorconfig files works well for me for the essential styles. And it can be useful to the other team members as well.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: