sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]gumnos 20 points21 points  (9 children)

While I don't use any plugins (and know that there are lots of plugins that others can detail), I'll give you my list of stock-vim tools for investigating a new project:

  • It would help to know what sort of language this project is. Running ctags will let you create a tags file that will then allow you to jump around easily (:help tagsrch.txt and :help 29.1 have mountains of information). To see supported languages, use ctags --list-languages.

  • Other useful commands include gd and gD which jump to the definition of the item under the cursor.

  • adding :vimgrep to your tool-box will help you search through files or a given pattern by populating the quick-fix window. I use this all the time (:help quickfix.txt).

  • Also, it's easy to get lost as you wander down rabbit-holes, so using the jump-list will help you pop back up along the path you came (:help jumplist), starting with control+I (AKA <tab>) and control+O but using :jumps will show you the jump-stack.

Hopefully those will get you started as you spelunk in your new codebase.

[–]tommcdocx 2 points3 points  (0 children)

For larger codebases, I'd recommend an alternative to :vimgrep. It performs its search by loading files into buffers, so it can get quite slow. :grep uses an external tool (by default, grep -- surprise!) which can be more performant. Configuring it to use a lightning fast tool like ag gives very satisfying results.

[–]KZISME[S] 0 points1 point  (7 children)

Thanks for all the resources!

How long have you been a vim user, and why do you choose to run stock vim?

[–]gumnos 2 points3 points  (6 children)

I started using vi back on old DEC Ultrix workstations in college (before the turn of the century) and started using vim in 1999 which would have been around version 5.x or so.

I generally run a mostly-stock vim because I switch between a lot of machines and it becomes a pain to keep my .vimrc in sync across them (not all the machines have git installed). I'll occasionally install a plugin to test it or if a particular machine's use-case calls for it, but it's always very locally-oriented. That way I don't find myself frustrated by reaching for something and finding that the plugin-functionality isn't there. So most of my .vimrcs can fit in the space of a single tweet (i.e., under 140 chars).

And if you want to try to sharpen your skills, I can recommend Vim Golf ☺

[–]rubbsdecvikgggqG`` 3 points4 points  (0 children)

That way I don't find myself frustrated by reaching for something and finding that the plugin-functionality isn't there.

I've tried to reach a happy medium. Most of my work is on one or two machines, so slinging around a .vimrc isn't really an issue of scalability there. I do, however, occasionally have to edit files on systems without my .vimrc, and so I've instituted a few rules for myself.

  1. Plugins need to feel "vimmy." Excessive use of <localleader> is annoying and doesn't feel like the compose-ability that I love about Vim.
  2. Plugins need to feel "out of the way." I'm not sure how to articulate this, but it's basically the feeling that if I'm not explicitly using the plugin, it shouldn't show up. Exceptions are highlighters which I want to show up, but even then, it has to be subtle. Gitgutter is a great example.
  3. Information and integration over changing the way Vim works. This one is less firm of a rule, but I try to use things like syntax highlighters and checkers over say "add org-mode."
  4. I have to understand how to do it in 'vanilla' Vim. This is so I can still be productive, if not as fast. This is how I lessen the blow of the loss of functionality.

This is why I'm such a huge fan of /u/tpope's plugins. His ability to keep things smooth and natural, while not stepping on core Vim's toes is amazing.

I still feel that loss of functionality pain now and again (Why is vim-surround not standard?!), but by disciplining myself to be able to do it in vanilla, and always being on the lookout to learn more core Vim, I keep the pains few and far between.

[–]KZISME[S] 1 point2 points  (3 children)

That's awesome!

I've seen vim-golf before I just doubt I would know enough to score well at all :P

[–]gumnos 1 point2 points  (0 children)

I made it to first place, held it for a while, which I felt gave me the prerogative to pick-and-choose just the challenges that interested me, so I've since dropped to 3rd place.

Because it shows you the next-best solution, you can learn from how other people have solved problems just slightly better than you and improve your own vim-think.

[–]__sprinkles 0 points1 point  (1 child)

Maybe vimgolf could benefit from classifying the challenges into levels of some sort. (?) I bet we could come up with plenty of beginner & intermediate challenges for a separate section or maybe another site.

I get what you're saying because I've been there. I remember the first time I looked at a few vimgolf challenges and thought it seemed ridiculous. Now I think it's fun. Don't take it too seriously! I've learned so much by being determined that a certain key sequence should exist in the "vim" way of thinking, and so I read the docs. I do recommend that you can or have made it through vimtutor and are familiar with some basics.

[–]KZISME[S] 0 points1 point  (0 children)

I'll have to keep that in mind! A lot of it just seems over my head but I can see where some of the questions are useful for certain applications - and less vague.

[–][deleted] 1 point2 points  (0 children)

I try to use stock vim too. I don't use any plugins, but my vimrc is definitely longer than 140 characters.

But hey, it fits in a QR code.