Live data from Hacker News

VIM Pays Excellent Dividends: Learn it early, if you can

medium.com

61–65 of 65 posts

Re: VIM Pays Excellent Dividends: Learn it early, if you can

#61

Earlier quoted context omitted.

I've been thinking about this lately, and whether my preference for modal editors is a historical accident, an adaptation to the limited resources available when I was an undergrad, or whether there's more to it. I think there's more to it. What separates vim and emacs from editors with a more forgiving learning curve is that they embrace a separate language for editing that's distinct from text entry. That's not to…

I wonder if that's the feeling too if you come back to a "normal" programming language after getting reasonably proficient in Lisp. I see a couple of interesting parallels there - the biggest difference of Vim's modal commands to other control schemes (except maybe Emacs') is that they compose rather well. Add macros to that, and you can define (more or less) abstract editing functionality on the fly. It's basically…

That is a very interesting point. I've been starting to study Racket, and although far from proficient, I can see the analogy. I really appreciate the lack of mental overhead for syntax, and I'm beginning to get a feel for how you might be able to plug things together.

Re: VIM Pays Excellent Dividends: Learn it early, if you can

#62
post #59

Earlier quoted context omitted.

Watch this three minute video or view the concise notes below it for some very nice tips on handling buffers. http://vimcasts.org/episodes/working-with-buffers/ > You can quickly jump between the active buffer and the alternate buffer using the command . Pressing it again takes you back to where you were before. If you don't like the command for this, you could map it to something else, such as the tab key, with a li…

Thanks, that video was pretty good and helped me understand buffers. If you'll indulge me a bit more though, why does Vim warn you while switching out of an unsaved buffer (and make you use !) if it's still going to keep your changes when you come back? > However, the latest release of Vim now includes a built in plugin system, does that satisfy your need to have one blessed version? It absolutely does. I'm going to…

Not sure if you'll find this delayed comment, but I can give it a shot.

There is a note on the linked video page about `set hidden`, but it doesn't spend much time explaining it. If we open Vim and type `:help hidden`, we get the following:

  'hidden' 'hid'          boolean (default off)
                        global
                        {not in Vi}
        When off a buffer is unloaded when it is abandoned.  When on a
        buffer becomes hidden when it is abandoned.  If the buffer is still
        displayed in another window, it does not become hidden, of course.
        The commands that move through the buffer list sometimes make a buffer
        hidden although the 'hidden' option is off: When the buffer is
        modified, 'autowrite' is off or writing is not possible, and the '!'
        flag was used.  See also windows.txt.
        To only make one buffer hidden use the 'bufhidden' option.
        This option is set for one command with ":hide {command}" :hide.
        WARNING: It's easy to forget that you have changes in hidden buffers.
        Think twice when using ":q!" or ":qa!".
The default state of `hidden` is off, so with that in mind, the explanation basically answers why Vim warns you about switching buffers. If you switch away, the buffer is "hidden" -- Vim keeps track of what is in it and doesn't unload it. That's probably what you expect, but can lead to loss of unsaved data if you switch away from a buffer, work on some other buffers for a while, then close Vim without coming back to the unsaved one. So by default, Vim wants you to be explicit when switching away from a buffer that will become hidden. In most cases you probably want to save it first.

Turning `hidden` on would remove the warning, you could switch away from an unsaved buffer with `:bn`.

So if you want to always work with unsaved hidden buffers floating around (view them with `:ls`!), you could add `set hidden` to your .vimrc. Alternatively, you could set up a command to automatically execute a save action every time you tried to switch away from an unsaved buffer. Notice that `autowrite` is mentioned in the help text above. Running `:help autowrite` shows:

  'autowrite' 'aw'        boolean (default off)
                        global
        Write the contents of the file, if it has been modified, on each
        :next, :rewind, :last, :first, :previous, :stop, :suspend, :tag, :!,
        :make, CTRL-] and CTRL-^ command; and when a :buffer, CTRL-O, CTRL-I,
        '{A-Z0-9}, or `{A-Z0-9} command takes one to another file.
        Note that for some commands the 'autowrite' option is not used, see
        'autowriteall' for that.
So if you added `set autowrite` to your .vimrc, instead of `set hidden`, you could avoid the warnings by automatically saving the file, rather than leaving it unsaved.

Hope this helps! One of the pain points of vim is that many of the defaults end up being somewhat unexpected choices. Many people get over that by just looking up someone's post online and copying in a bunch of settings. When you do that, you don't end up learning much about navigating vim and understanding the configuration process. You just end up with a new set of defaults that might also not quite be what you want. I try to keep my .vimrc pretty plain until I realize something could be better, then spend a moment to figure out how to do that and add it in.

Re: VIM Pays Excellent Dividends: Learn it early, if you can

#63
post #59

Earlier quoted context omitted.

Thanks, that video was pretty good and helped me understand buffers. If you'll indulge me a bit more though, why does Vim warn you while switching out of an unsaved buffer (and make you use !) if it's still going to keep your changes when you come back? > However, the latest release of Vim now includes a built in plugin system, does that satisfy your need to have one blessed version? It absolutely does. I'm going to…

Not sure if you'll find this delayed comment, but I can give it a shot. There is a note on the linked video page about `set hidden`, but it doesn't spend much time explaining it. If we open Vim and type `:help hidden`, we get the following: 'hidden' 'hid' boolean (default off) global {not in Vi} When off a buffer is unloaded when it is abandoned. When on a buffer becomes hidden when it is abandoned. If the buffer is…

Thanks again!

Re: VIM Pays Excellent Dividends: Learn it early, if you can

#64
post #26
post #23

I find using Vim more natural when I'm spending time in the command line. I'm an entrenched Windows user but I love the power of the linux command tools. Now thanks to the GNU Tools packaged with Git, you get Vim and OpenSSH as lovely extras. It's really nice to be able to switch back and forth between editing on Linux via SSH in Vim and then back in Windows. If you're searching around and moving files via the DOS pr…

You know Cygwin has been around for ages and has done this forever. You didn't need to wait for some big bundle of git to arrive on Windows for this.

Yes, I was using Cygwin a decade ago - it was the most painful experience.

It's got nothing to do with Git - just that Git bundles the most up to date versions of GNU tools compiled for Windows. There were pre-cursors to Git, but Git packages them all nicely.

Just for sentimental reasons I love using DOS, same as any Linux user loves their shell. So having the tools natively in DOS is a much nicer experience.

Re: VIM Pays Excellent Dividends: Learn it early, if you can

#65
post #28
post #26

Earlier quoted context omitted.

You know Cygwin has been around for ages and has done this forever. You didn't need to wait for some big bundle of git to arrive on Windows for this.

I don't think you need to wait for anything; I think he's describing MinGW that comes with a Windows install of Git. It's been around for a long time. Cygwin vs MinGW is a whole other argument, of course.

Yeah the MinGW - it's just that Git packaged them all up nicely, previously I always found there was a few missing tools. I find it much nicer to be able to use those inside DOS.
Post reply on HN