Coming Home to Vim(stevelosh.com)
stevelosh.com
Coming Home to Vim
http://stevelosh.com/blog/2010/09/coming-home-to-vim/
27 comments
I wish this post were closer to the top. Now that knowledge can finally become instantly available, it's biggest enemy is large amounts of misinformation. This is a much more effective strategy than censorship.
I'm not a vim guru by any stretch of the imagination, but I still don't take what he says at face value. I don't trust ANYTHING I see on the internet just because it's there!
Your criticism seems to be due to the belief that, in a world where the only information on the internet could be treated as gospel, that would allow the experts opinion to come through easily. Unfortunately, that sets up the circumstance where the experts get granted much more exposure and trust than they necessarily deserve, and it inevitably gets subverted and abused.
I personally prefer the current system - treat all information as suspect until you can verify it. It leaves MUCH less room for exploitation than all of our other "trust by default" mediums.
-- Ayjay on Fedang
Your criticism seems to be due to the belief that, in a world where the only information on the internet could be treated as gospel, that would allow the experts opinion to come through easily. Unfortunately, that sets up the circumstance where the experts get granted much more exposure and trust than they necessarily deserve, and it inevitably gets subverted and abused.
I personally prefer the current system - treat all information as suspect until you can verify it. It leaves MUCH less room for exploitation than all of our other "trust by default" mediums.
-- Ayjay on Fedang
Oh, I agree that not trusting information on the internet is the sensible default. However, there are plenty of people who will be copying his examples directly without any investigation.
Some will probably post the exact same stuff on their own blogs or link to this post. Before you know it this example will drown out any serious search results for "vim filetype", effectively stopping new people from learning how to do things properly.
Now obviously this post is a bit hyperbole in this instance. But these things do happen because people can't be arsed to treat the things they write/publish with the care it deserves.
Some will probably post the exact same stuff on their own blogs or link to this post. Before you know it this example will drown out any serious search results for "vim filetype", effectively stopping new people from learning how to do things properly.
Now obviously this post is a bit hyperbole in this instance. But these things do happen because people can't be arsed to treat the things they write/publish with the care it deserves.
I see a lot of people in #vim (freenode) who have followed some random blog post instructions for configuring vim that we have to correct.
Actually I remember why I do this now. It's to make Pathogen work.
From Pathogen's docs:
From Pathogen's docs:
Note that you need to invoke the pathogen functions before
invoking "filetype plugin indent on" if you want it to load
ftdetect files. On Debian (and probably other distros), the
system vimrc does this early on, so you actually need to
"filetype off" before "filetype plugin indent on" to force
reloading.
One of the things I love about Vim is that every time I read though a post like this or look at someone's .vimrc I learn something new about what it can do or get another insight about how its features can make my life easier.
My (semi-commented) .vimrc is on GitHub if anyone wants another example: http://github.com/samdk/vimconf/blob/master/dotvimrc
I've also found StackOverflow's list of most-voted questions tagged vim to be a very useful source of little tidbits: http://stackoverflow.com/questions/tagged/vim?sort=votes&...
And there've been several HN .vimrc posts that I also found very useful. This is one of the best: http://news.ycombinator.com/item?id=856051
This is another excellently commented and extensive .vimrc that (I think) is mentioned in one of the above links, but deserves its own specific mention here: http://www.vi-improved.org/vimrc.php
And this is another I found completely by accident a while ago that includes some excellent examples of vimscript macros: http://fingelrest.silent-blade.org/uploads/Main/vimrc.html
My (semi-commented) .vimrc is on GitHub if anyone wants another example: http://github.com/samdk/vimconf/blob/master/dotvimrc
I've also found StackOverflow's list of most-voted questions tagged vim to be a very useful source of little tidbits: http://stackoverflow.com/questions/tagged/vim?sort=votes&...
And there've been several HN .vimrc posts that I also found very useful. This is one of the best: http://news.ycombinator.com/item?id=856051
This is another excellently commented and extensive .vimrc that (I think) is mentioned in one of the above links, but deserves its own specific mention here: http://www.vi-improved.org/vimrc.php
And this is another I found completely by accident a while ago that includes some excellent examples of vimscript macros: http://fingelrest.silent-blade.org/uploads/Main/vimrc.html
That's exactly what I hate about both Emacs and Vim: yes, they are customizable, however many useful customization are scattered around user scripts.
EDIT: A flag here and there does not make a structured environment. That's why many people are running to other editors: they find that what they are more likely to need is already there in a designed way, not in a thrown-together one.
EDIT: A flag here and there does not make a structured environment. That's why many people are running to other editors: they find that what they are more likely to need is already there in a designed way, not in a thrown-together one.
Exactly.
Case in point: I just found out about ending the backupdir with two slashes to include the full path in the filename by reading your .vimrc. Thanks!
Case in point: I just found out about ending the backupdir with two slashes to include the full path in the filename by reading your .vimrc. Thanks!
syntax on
filetype on
filetype plugin on
filetype indent on
You do not want "filetype off"
Also, check out snipMate as it gives you easy to use TextMate type snippets.
In Vim:
:h filetype
filetype on
filetype plugin on
filetype indent on
You do not want "filetype off"
Also, check out snipMate as it gives you easy to use TextMate type snippets.
In Vim:
:h filetype
You do not want "filetype off"
A minor quibble: you might want "filetype off" temporarily, if you use Pathogen (which the poster does). Pathogen needs to run before the filetype plugin is turned on, and due to the way some distros work (Debian and its children, primarily, I think), this requires you to start your .vimrc this way[1]:
As a general rule, though, you are right that you want it turned on normally.
[1] http://www.vim.org/scripts/script.php?script_id=2332
A minor quibble: you might want "filetype off" temporarily, if you use Pathogen (which the poster does). Pathogen needs to run before the filetype plugin is turned on, and due to the way some distros work (Debian and its children, primarily, I think), this requires you to start your .vimrc this way[1]:
filetype off
call pathogen#runtime_append_all_bundles()
call pathogen#helptags()
" Later...
filetype plugin indent on
As a general rule, though, you are right that you want it turned on normally.
[1] http://www.vim.org/scripts/script.php?script_id=2332
This has been changed in Debian (the system vimrc no longer turns syntax or filetype on), but persists in Ubuntu.
I wasn't aware of the change. Thanks for letting me know.
Replying to myself because I can't seem to reply to sigzero:
Yeah, I definitely need to get around to reading :h filetype.
I mentioned Snipmate in the article, so I know about it :)
Yeah, I definitely need to get around to reading :h filetype.
I mentioned Snipmate in the article, so I know about it :)
This is not vim-related, but the reason you couldn't reply is that HN doesn't let you reply to a comment until after a certain amount of time has passed. This amount of time depends on how deep the comment is in the tree. (I believe the restriction is there to help prevent excessively deep comment trees that are just people arguing back and forth.)
It's circumventable, as well; if there's no "reply" link on the main threaded view, you can click the "link" button to get the comment on its own page, and reply from there.
Cool, thanks!
It would be helpful if it mentioned that somewhere...
It would be helpful if it mentioned that somewhere...
Addendum: ugh, it's not even in the damn FAQ.
It was announced here: http://ycombinator.com/newsnews.html
That's because it's inside information.
I just started using it. Like it a lot.
Another good vimrc is the vimrc from grml http://git.grml.org/?p=grml-etc-core.git;a=blob_plain;f=etc/...
It is a good start to a simple but yet powerful vim configuration, especially integration with screen, pastetoggle, etc.
It is a good start to a simple but yet powerful vim configuration, especially integration with screen, pastetoggle, etc.
Nice, I got a feeling what your main line of programming is from the source. That's somehow fun.
Anyway, might as well join in too, here is my vimrc: http://gist.github.com/144742#file_gistfile1.vim
Anyway, might as well join in too, here is my vimrc: http://gist.github.com/144742#file_gistfile1.vim
>Some people use a mapping that turns search highlighting off and on, but I don’t like that solution. It means I have to remember to turn it back on later once I’ve probably already forgotten about the original search.
:nohlsearch removes highlighting, doesn't modify search history, and also doesn't disable highlighted search. It will still highlight matches for the next search.
> When I press return, create a new line at the same indentation level as the current one. Don’t try to be clever and adjust the indent of new line in any fashion.
:nohlsearch removes highlighting, doesn't modify search history, and also doesn't disable highlighted search. It will still highlight matches for the next search.
> nnoremap <leader>S ?{<CR>jV/^\s*\}?$<CR>k:sort<CR>:let @/=''<CR>
> When I press return, create a new line at the same indentation level as the current one. Don’t try to be clever and adjust the indent of new line in any fashion.
set autoindent nosmartindent nocindent
> I'm curious why not just use `ViB:sort`?
Because we use LessCSS[1] which lets you nest selectors:
I'll give the indent settings a try, thanks!
[1]: http://lesscss.org/
Because we use LessCSS[1] which lets you nest selectors:
body {
color: #151515;
background-color: white;
a {
color: red;
}
}
I'll give the indent settings a try, thanks!
[1]: http://lesscss.org/
For a free, cross-platform (and excellent) alternative to PeepOpen, try Command-T
I used to use FuzzyFinder_TextMate, but that's stopped development, and the creator recommends you use Command-T instead.
https://wincent.com/products/command-t
I used to use FuzzyFinder_TextMate, but that's stopped development, and the creator recommends you use Command-T instead.
https://wincent.com/products/command-t
LustyExplorer is good. One feature that I really like is that I can start exploring from the current directory or the directory of the current file. This way I can keep vim's current directory at the root of my source tree, and not have to deal with turning on 'acd' and all of the incompatibilities that can arise.
+1 for LustyExplorer. Use that every day at work and at home.
I've added a link to this to the post, thanks!
I dont see the appeal of nerdtree and the like. For me they are clumsy and too much information.
I'm very adept at unix cmd line, find, ack, locate, CDPATH, cmd history, and friends. I spend 10-20% of my editing time at the bash prompt. So much so i aliased :e to vim
Having never got the "gui" file managemnet tools i cant say for certain but i wonder if power and productivity gains one sees from truly learning vim can be reproduced by truly learning cmd line.
I'm very adept at unix cmd line, find, ack, locate, CDPATH, cmd history, and friends. I spend 10-20% of my editing time at the bash prompt. So much so i aliased :e to vim
Having never got the "gui" file managemnet tools i cant say for certain but i wonder if power and productivity gains one sees from truly learning vim can be reproduced by truly learning cmd line.
Could you please share how exactly you do the "jump to file foo.bar" functionality? That is the only part of vim I still find a bit laborious, probably because I haven't found a good workflow for it.
:e f<tab>.b<tab><return> or similar from command line often using history. After using a code base for a few hours/days I pretty much know where everything is and exactly how many chars I need to type before tab autocompletes.
After I open a file once it is in my vim and or bash history which means opening it again is only a couple keystrokes.
I use <ctrl>6 and multiple (3-4) non-overlapping terminals (with text mode vim) in various directories. So "jump to file foo.bar" is often look at the vim/terminal to the upper right or <ctrl>6 or :e<space>f<up><enter>
Don't remember what this does excactly but it's in my vimrc and might have something to do with it.
"freakin awesome file completion set wildmode=list:longest
I also use this form of "history"
bind '"\e[A"':history-search-backward bind '"\e[B"':history-search-forward
After I open a file once it is in my vim and or bash history which means opening it again is only a couple keystrokes.
I use <ctrl>6 and multiple (3-4) non-overlapping terminals (with text mode vim) in various directories. So "jump to file foo.bar" is often look at the vim/terminal to the upper right or <ctrl>6 or :e<space>f<up><enter>
Don't remember what this does excactly but it's in my vimrc and might have something to do with it.
"freakin awesome file completion set wildmode=list:longest
I also use this form of "history"
bind '"\e[A"':history-search-backward bind '"\e[B"':history-search-forward
:b has smart tab completion. You can type any part of the filename and you can tab through the results. This is generally what I find myself doing when I have a lot of buffers open. Otherwise I just use minibufexpl with buffer next/prev keybinds.
But what about files that you haven't already opened?
:e also has tab completion.
I also use ctags. Usually I want to look things up by symbol name, not filename, though it's trivially easy to make a script that generates a tags file of just filenames too. (And :tag also supports tab completion.)
I also use ctags. Usually I want to look things up by symbol name, not filename, though it's trivially easy to make a script that generates a tags file of just filenames too. (And :tag also supports tab completion.)
PeepOpen or Command-T.
A little off-topic: I love how in the side panel of the page the sub-title fades in and out as you scroll.
that's proportional to how much of the actual headline is still visible. scroll slowly and you'll notice.
Here's a bit more about them: http://stevelosh.com/blog/2010/09/making-my-site-sing/#showi...
Entirely agree on the aesthetics, one of the things holding me back from switching is that I love vibrant ink in textmate. I just can't seem to find a theme that is quite as bright (vividchalk was pretty close). Any suggestions?
Convert your textmate theme to vim: http://coloration.sickill.net/
Thanks! macvim here I come :)
edit: Many of the most popular textmate schemes have already been converted and can be found at http://github.com/squil/vim_colors
edit: Many of the most popular textmate schemes have already been converted and can be found at http://github.com/squil/vim_colors
Some are even "improved". I love molokai http://winterdom.com/2008/08/molokaiforvim .
The issue I had with Molokai (and it may be my screen) is that the comments were barely readable. The colours were just too close to the background.
My favourite is earendel (http://www.vim.org/scripts/script.php?script_id=2188)
My favourite is earendel (http://www.vim.org/scripts/script.php?script_id=2188)
Since the blog isn't taking comments, posting it here.
> doesn't work very well with is Python, because it preserves whitespace when it moves the code over the REPL.
If that's the only issue, it's easy to fix it. All you need to do is to replace multiple new lines with single new line.
I have been using it on Ubuntu with vim and IPython and it seems to work fine. When I started using slime.vim for Python, I ran into whitespace issue and Jonathan(slime.vim developer) resolved it when I asked him on his blog. http://technotales.wordpress.com/2007/10/03/like-slime-for-v...
You can search for Rahul in the comments.
> doesn't work very well with is Python, because it preserves whitespace when it moves the code over the REPL.
If that's the only issue, it's easy to fix it. All you need to do is to replace multiple new lines with single new line.
let s:foo_text = substitute(a:text, '\n\s*\n\+', '\n', 'g') . "\n"
I have been using it on Ubuntu with vim and IPython and it seems to work fine. When I started using slime.vim for Python, I ran into whitespace issue and Jonathan(slime.vim developer) resolved it when I asked him on his blog. http://technotales.wordpress.com/2007/10/03/like-slime-for-v...
You can search for Rahul in the comments.
After a few months of vim use, I did part of the vim tutorial using both vim and a click-and-type editor (gedit) and timed myself. Gedit was significantly faster. Can't say I understand you vim fanatics.
If you say why Gedit was faster perhaps us vim fanatics can help you understand us.
Let's say I need to change a word. With Gedit, I double-click the word and retype it the right way. With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode.
Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous group of lines. In Vim, I'd need to move to the line I want to begin my selection on ([number]G or jjj), then press V, then press jjj until everything is selected. And I don't have to deal with the fact that the default way of deleting things overwrites the default clipboard either.
I do use Vim when I need to process lines in a text document (with macros), when I'm editing files on a server, or when I'm writing a git commit message. I suppose I could use Vim in much the same way as Gedit through its mouse capability, but I dislike the lack of interface between my system clipboard and Vim's, and the fact that when I paste code in to a Vim document, the indentation gets all screwed up.
Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous group of lines. In Vim, I'd need to move to the line I want to begin my selection on ([number]G or jjj), then press V, then press jjj until everything is selected. And I don't have to deal with the fact that the default way of deleting things overwrites the default clipboard either.
I do use Vim when I need to process lines in a text document (with macros), when I'm editing files on a server, or when I'm writing a git commit message. I suppose I could use Vim in much the same way as Gedit through its mouse capability, but I dislike the lack of interface between my system clipboard and Vim's, and the fact that when I paste code in to a Vim document, the indentation gets all screwed up.
"With Vim, I press j until I'm on the line where the word is, then I press w until I'm at the beginning of the word, then I press cw to change the word, retype it the right way, and press escape to go back to command mode."
OK, this is something Vim people need to work on. Using j/k to move more than one or two lines is the wrong way to do things.
I know, I know, we extoll the virtues of hjkl constantly, but really they're barely more effective than the arrow keys.
There are better ways to move around in Vim, such as [f]orward, '[t]il and searching. In your case (changing word XYZ to something else) I would search for the word with /XY… and press return to get there, then edit as you described.
"Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous group of lines. In Vim, I'd need to move to the line I want to begin my selection on ([number]G or jjj), then press V, then press jjj until everything is selected."
See my previous comment about movement. You'd move to the line you want by using a search (or '{', which moves to empty lines), start your selection with V, and move to the end with another search (or some kind of movement command that gets you where you want to go quickly).
We Vim users need to stop touting our Nethack-honed hjkl skills and start talking about Vim's better movement commands.
"And I don't have to deal with the fact that the default way of deleting things overwrites the default clipboard either."
Yeah, this is dumb. YankRing helps a lot by letting you 'Ctrl+P' to the right text, but I really think Vim should have a "clipboard register" that only gets overwritten when you mean it (and have other registers for the last yanked elements).
"when I paste code in to a Vim document, the indentation gets all screwed up."
If you're using a graphical Vim like gvim or MacVim this simply shouldn't happen. It's a bug and you could report it.
If you're using the command line Vim you might need to do a bit more work to launch Vim and tell it to talk to X. It's a few extra minutes up front, but such is the price of using a terminal-based editor in a graphical environment.
OK, this is something Vim people need to work on. Using j/k to move more than one or two lines is the wrong way to do things.
I know, I know, we extoll the virtues of hjkl constantly, but really they're barely more effective than the arrow keys.
There are better ways to move around in Vim, such as [f]orward, '[t]il and searching. In your case (changing word XYZ to something else) I would search for the word with /XY… and press return to get there, then edit as you described.
"Triple-clicking in Gedit highlights a line. Triple-clicking and dragging highlights a contiguous group of lines. In Vim, I'd need to move to the line I want to begin my selection on ([number]G or jjj), then press V, then press jjj until everything is selected."
See my previous comment about movement. You'd move to the line you want by using a search (or '{', which moves to empty lines), start your selection with V, and move to the end with another search (or some kind of movement command that gets you where you want to go quickly).
We Vim users need to stop touting our Nethack-honed hjkl skills and start talking about Vim's better movement commands.
"And I don't have to deal with the fact that the default way of deleting things overwrites the default clipboard either."
Yeah, this is dumb. YankRing helps a lot by letting you 'Ctrl+P' to the right text, but I really think Vim should have a "clipboard register" that only gets overwritten when you mean it (and have other registers for the last yanked elements).
"when I paste code in to a Vim document, the indentation gets all screwed up."
If you're using a graphical Vim like gvim or MacVim this simply shouldn't happen. It's a bug and you could report it.
If you're using the command line Vim you might need to do a bit more work to launch Vim and tell it to talk to X. It's a few extra minutes up front, but such is the price of using a terminal-based editor in a graphical environment.
"There are better ways to move around in Vim, such as [f]orward, '[t]il and searching. In your case (changing word XYZ to something else) I would search for the word with /XY… and press return to get there, then edit as you described."
That is both slower and has the disadvantage that any intermediary occurrences of the word between my cursor and the one I want to edit will be accessed first.
"See my previous comment about movement. You'd move to the line you want by using a search (or '{', which moves to empty lines), start your selection with V, and move to the end with another search (or some kind of movement command that gets you where you want to go quickly)."
I invented the following task for myself: With the cursor on a blank line above 4 lines of text followed by a blank line, copy the 4 lines and paste them so that there is a buffer of 2 blank lines between the 4 lines of text and their duplicates. I did the task 4 times in both gedit and vim, restarting whenever I screwed up (which was quite often). Here are my results.
vim: 18.28s gedit: 14.45s
I discarded an earlier task that I think Vim might have been doing better on because the task ended with the buffer back where it started, and I wasn't sure I was able to count accurately while performing the task. However, I had practiced with Vim on that task to the point where my movements were purely mechanical, and I was typing characters nearly as fast as I'm typing these words now.
It's probably a better idea to relax while doing these tasks instead of racing through them, as I'm generally relaxed when I code, but I still don't see much promise in Vim at this point.
As a side note, why is it that I'm the only one doing tests on myself? It's almost as though you guys don't actually want to know which editor is faster.
That is both slower and has the disadvantage that any intermediary occurrences of the word between my cursor and the one I want to edit will be accessed first.
"See my previous comment about movement. You'd move to the line you want by using a search (or '{', which moves to empty lines), start your selection with V, and move to the end with another search (or some kind of movement command that gets you where you want to go quickly)."
I invented the following task for myself: With the cursor on a blank line above 4 lines of text followed by a blank line, copy the 4 lines and paste them so that there is a buffer of 2 blank lines between the 4 lines of text and their duplicates. I did the task 4 times in both gedit and vim, restarting whenever I screwed up (which was quite often). Here are my results.
vim: 18.28s gedit: 14.45s
I discarded an earlier task that I think Vim might have been doing better on because the task ended with the buffer back where it started, and I wasn't sure I was able to count accurately while performing the task. However, I had practiced with Vim on that task to the point where my movements were purely mechanical, and I was typing characters nearly as fast as I'm typing these words now.
It's probably a better idea to relax while doing these tasks instead of racing through them, as I'm generally relaxed when I code, but I still don't see much promise in Vim at this point.
As a side note, why is it that I'm the only one doing tests on myself? It's almost as though you guys don't actually want to know which editor is faster.
I tried your test, and was slightly faster at doing it vim than gedit (assuming my fingers were on the keyboard to begin with). How exactly did you do it in vim? I used the following:
y4j5jp -- yank down to 4 lines, move down to the blank line, paste after it.
I appreciate that there's an awful lot to learn before you can edit quickly in vim, and that the difference (if any) between that and gedit(or any other editor) may not be worth it.
I prefer vim for reasons other than speed, though -- the composable commands "feel" right to me, and the macro system makes short work of repetitive tasks. I'm essentially making lots of small programs to write the larger program for me.
y4j5jp -- yank down to 4 lines, move down to the blank line, paste after it.
I appreciate that there's an awful lot to learn before you can edit quickly in vim, and that the difference (if any) between that and gedit(or any other editor) may not be worth it.
I prefer vim for reasons other than speed, though -- the composable commands "feel" right to me, and the macro system makes short work of repetitive tasks. I'm essentially making lots of small programs to write the larger program for me.
I did V}y}p.
I don't know about other vim-users, but I haven't run any tests because my primary motivation for using vim isn't speed (it's that vim connects with my brain and my motor activity -- it just feels "right" and I get a great flow).
yap}p
You can also use the mouse with vim.
set mouse=a and the behaviour is the same, tripple click hilights a line and you can drag your mouse around to highlight a contiguous group of lines.
regarding the system clipboard, yeah thats messy, but you can easily map a key to toggle the paste mode (set pastetoggle=<f11>) or get the content from the the clipboard via some keybinding (shift-F7) map <S-F7> :r!xclip -o<CR>
set mouse=a and the behaviour is the same, tripple click hilights a line and you can drag your mouse around to highlight a contiguous group of lines.
regarding the system clipboard, yeah thats messy, but you can easily map a key to toggle the paste mode (set pastetoggle=<f11>) or get the content from the the clipboard via some keybinding (shift-F7) map <S-F7> :r!xclip -o<CR>
Reading your comment it is apparent you dont now "enough" vim. It has a long learning slope with many comfortable plateaus. You must be diciplined and interested in mastering your tools to push beyound these.
fyi,
:set paste :set nopaste
fyi,
:set paste :set nopaste
In my Vim vs Gedit test, I was doing tasks from the beginning of the Vim tutorial using the exact commands the tutorial told me to use.
It does seem possible to me that someone could become faster with Vim than a click-and-type editor, but I'd guess they'd never amortize the costs of their learning. (Of course, if you're already quite advanced then you've paid a good chunk of the cost and it may make sense to continue.)
It does seem possible to me that someone could become faster with Vim than a click-and-type editor, but I'd guess they'd never amortize the costs of their learning. (Of course, if you're already quite advanced then you've paid a good chunk of the cost and it may make sense to continue.)
The beginning of the tutorial doesn't necessarily have the most efficient way to accomplish a task. It just has the most basic way.
For example: move up 10 lines with 10k. Move up 2 paragraphs with 2{. Move up to "what" with ?what, and if it stops somewhere else first, just hit n. Find the first letter T in a line with fT, and hit ; if you stopped at another one first. Etc. You can't put everything at the beginning of the tutorial but having a lot of these tricks in your bag speeds you up quite a bit. Then you start combining these movements with commands, repeating these combinations with just a period, recording them in macros with a couple keystrokes, applying them to every selected line with :norm, etc. It's the combination of all these things that makes it go fast.
That said, if I've got a long distance to travel and there's no obvious movement command to get me there quickly, I'll still use the mouse occasionally. It does seem to break the flow though.
The biggest improvement vim has made to my productivity isn't just the raw speed of editing, it's the fun of editing with it. That keeps me a lot more focused when the work itself gets a little mundane.
For example: move up 10 lines with 10k. Move up 2 paragraphs with 2{. Move up to "what" with ?what, and if it stops somewhere else first, just hit n. Find the first letter T in a line with fT, and hit ; if you stopped at another one first. Etc. You can't put everything at the beginning of the tutorial but having a lot of these tricks in your bag speeds you up quite a bit. Then you start combining these movements with commands, repeating these combinations with just a period, recording them in macros with a couple keystrokes, applying them to every selected line with :norm, etc. It's the combination of all these things that makes it go fast.
That said, if I've got a long distance to travel and there's no obvious movement command to get me there quickly, I'll still use the mouse occasionally. It does seem to break the flow though.
The biggest improvement vim has made to my productivity isn't just the raw speed of editing, it's the fun of editing with it. That keeps me a lot more focused when the work itself gets a little mundane.
To add to what Steve said, I would say: don't be afraid to use the mouse if you're in a graphical Vim. In MacVim, if I want to change a word, I'll double-click it, hit c and type whatever I want.
You might say, "But you had to hit 'c' instead of just typing!"
Maybe, but I could run any number of commands over that word instead of just changing it. Also, if I were in insert mode, double-clicking and typing would overwrite the word as if I were in a normal editor.
You might say, "But you had to hit 'c' instead of just typing!"
Maybe, but I could run any number of commands over that word instead of just changing it. Also, if I were in insert mode, double-clicking and typing would overwrite the word as if I were in a normal editor.
You could use the Cream bundle for vim (http://cream.sourceforge.net/) to get a more modeless, Textmate-like editor.
Generally, if you know where you're going its a lot faster to just start typing a search until you get to the word you want than to mess around with j and w (why incremental search isn't default eludes me). I won't claim that will always be faster than a mouse, but it should narrow the difference a lot.
I totally agree with you about the clipboard issues though.
I totally agree with you about the clipboard issues though.
when I paste code in to a Vim document, the indentation gets all screwed up.
Try :set paste :set nopaste :set invpaste :help paste
Try :set paste :set nopaste :set invpaste :help paste
No, you would type xxg, where xx is the line number, then move with w if the word was a short distance away, or use the mouse if it was somewhere like the middle of the line, then cw. This works out favorably even a Thinkpad where I don't need to take my hands away from the home row for, and it works better when working with very large screens.
Since you seem to compare terminal vim vs gedit: How do you run gedit in a terminal?
I gvim you could have used the mouse too.
I gvim you could have used the mouse too.
Really what I'm wondering is whether the Vim way of doing things or the click-and-type way of doing things is faster. I don't see any really compelling advantages of Vim as a click-and-type editor. Gedit also has a plugin mechanism y'know.
Apple discovered fairly early on that while using a keyboard shortcut seems faster, using the mouse is almost always quicker, even for very advanced users. The illusion stems from how we perceive time when performing the different tasks - we remember time spent searching for the correct target to click, but we forget time spent remembering the right incantation.
This paradox is one of the big reasons why I don't use Vi or EMACS - I think that the productivity gains are nowhere near as great as users make out, but the sense of mastery over such arcane tools is inherently satisfying to the kind of person that spends a lot of time in a text editor.
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
This paradox is one of the big reasons why I don't use Vi or EMACS - I think that the productivity gains are nowhere near as great as users make out, but the sense of mastery over such arcane tools is inherently satisfying to the kind of person that spends a lot of time in a text editor.
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
That's certainly interesting research, but it's far from conclusive. There are all manner of variables such as the accuracy of the mouse actions required, the number of keystrokes required, the familiarity of the user with the commands, and even the quality of the mouse.
The tests that Apple conducted were based on simple tasks available on the Macintosh computers of the time. However, text editing is a complex task with a lot of room for optimization. There is no doubt that more keypresses can be achieved per second than mouse actions, and that if asked to repetitively perform a task that could be accomplished by means of 10 vim key strokes or some combination of 5 text selections and menu choices, the max speed of the vim'er would top out higher than the mouser.
However true it is that the keyboarder forgets the time spent recalling arcane commands, it's also true that experienced vim'ers can issues multiple commands per second, some of which will do things that would not reasonably contained in a convenient location in a menu and/or icon-based interface. The powerful grammar and compositional nature of vi commands alluded to in this article, combined with the patterns that emerge in working with specific programming languages lead to opportunities to develop extremely efficient editing skills that blow a mouse-based workflow out of the water. It's not just my own experience, it's watching other people do things in vi or emacs that I guarantee are impossible with a mouse.
You may well be right that the improved productivity of vi/emacs is exaggerated by its practitioners, but I don't think there's really a case to be made that advanced keyboard editing is a waste of time.
The tests that Apple conducted were based on simple tasks available on the Macintosh computers of the time. However, text editing is a complex task with a lot of room for optimization. There is no doubt that more keypresses can be achieved per second than mouse actions, and that if asked to repetitively perform a task that could be accomplished by means of 10 vim key strokes or some combination of 5 text selections and menu choices, the max speed of the vim'er would top out higher than the mouser.
However true it is that the keyboarder forgets the time spent recalling arcane commands, it's also true that experienced vim'ers can issues multiple commands per second, some of which will do things that would not reasonably contained in a convenient location in a menu and/or icon-based interface. The powerful grammar and compositional nature of vi commands alluded to in this article, combined with the patterns that emerge in working with specific programming languages lead to opportunities to develop extremely efficient editing skills that blow a mouse-based workflow out of the water. It's not just my own experience, it's watching other people do things in vi or emacs that I guarantee are impossible with a mouse.
You may well be right that the improved productivity of vi/emacs is exaggerated by its practitioners, but I don't think there's really a case to be made that advanced keyboard editing is a waste of time.
Another thing that comes to mind is that using current devices (such as two 22" displays, i.e., a much higher resolution like 3360x1050), the time to do anything meaningful with a pointing-device increases, too. I, for instance, switched to a big trackball device because all this mouse lifting and re-centering became annoying.
As for the simple tasks: Something like Emacs macros enable effective processing of raw text input data--something that would take a lot longer if it had to be done manually, if possible at all.
As for the simple tasks: Something like Emacs macros enable effective processing of raw text input data--something that would take a lot longer if it had to be done manually, if possible at all.
After reading that long ago, I timed myself doing keyword searches on a webpage using both cntrl-f and accessing search from the menu. cntrl-f was significantly faster.
I agree that this is true in some cases but I can give you a counter example that really showed me how convenient vim is: ciw. 'ciw' erases the word under the cursor and allows you to retype it. This process is very, very slow using the mouse: even if double or triple click tends to correctly highlight the word you want to replace, positioning your mouse there is pretty slow.
Few months of vim use is not really enough to see major benefits in raw speed. You have to get not just the basics but the advanced movement/replacement commands in your bones. A click-and-type editor will start you off fast and top out quickly.
You can also use vim as if it were TextEdit, mostly, and the gradually add the advanced features, as per wycats. Best of both worlds.
You can also use vim as if it were TextEdit, mostly, and the gradually add the advanced features, as per wycats. Best of both worlds.
[deleted]
I don't know how you are working and what your typing characteristics are, but you are probably not doing a lot of fast typing.
Once you type reasonably fast (>30wpm), the time you have to invest to reach for the mouse, do some funky things and home back in to the keyboard is quite significant.
Another thing is, that once you got some of the very useful commands into your bone, like repeat action, some of the more elaborate selections, replacing and so on, you really get much more efficient with vim.
There are other advantages too. Pulling gedit through and ssh session is at best problematic, most cases there won't be an X client on the other side. You (almost) always find some kind of vi/vim there though.
There are all those nice things you can do that are really use case specific, like live editing files through ftp, scripting various things that you regularly do, adapting the config file, etc..
But it's not a question of "months". Really, vim has a very steep learning curve and you have to use it on a regular basis so it gets entrenched in you. Think more about "years". But that's cool, there is always more to learn, tweak and optimize.
Once you type reasonably fast (>30wpm), the time you have to invest to reach for the mouse, do some funky things and home back in to the keyboard is quite significant.
Another thing is, that once you got some of the very useful commands into your bone, like repeat action, some of the more elaborate selections, replacing and so on, you really get much more efficient with vim.
There are other advantages too. Pulling gedit through and ssh session is at best problematic, most cases there won't be an X client on the other side. You (almost) always find some kind of vi/vim there though.
There are all those nice things you can do that are really use case specific, like live editing files through ftp, scripting various things that you regularly do, adapting the config file, etc..
But it's not a question of "months". Really, vim has a very steep learning curve and you have to use it on a regular basis so it gets entrenched in you. Think more about "years". But that's cool, there is always more to learn, tweak and optimize.
typeracer.com says I type around 80 wpm, and I get quite nervous when I'm taking any sort of typing test, so I suspect my real typing speed is much higher. I'm on a laptop. Reaching for my mouse is very natural.
I do generally use vim for editing over ssh, although since I am root on the machines I work with, I would configure Gedit to work over ssh if I did any serious remote editing.
I do generally use vim for editing over ssh, although since I am root on the machines I work with, I would configure Gedit to work over ssh if I did any serious remote editing.
This is an excellent vim tutorial. Unlike others I've read, it makes me want to be vim power user by clearly spelling out the benefits of various tricks and commands.
"Many people like to remove any extra whitespace from the
" ends of lines. Here is one way to do it automatically
" when saving file.
fun! <SID>StripTrailingWhitespaces()
let l = line(".")
let c = col(".")
%s/\s\+$//e
call cursor(l, c)
endfun
autocmd BufWritePre * :call <SID>StripTrailingWhitespaces()
" When editing a file, always jump to the last known cursor position.
au BufReadPost * if line("'\"") > 0 && line("'\"") <= line("$") | exe "normal g'\"" | endif
" This function determines, wether we are on the start of the line text (then tab indents)
" or if we want to try autocompletion
function InsertTabWrapper()
let col = col('.') - 1
if !col || getline('.')[col - 1] !~ '\k'
return "\<tab>"
else
return "\<c-p>"
endif
endfunction
" Remap the tab key to select action with InsertTabWrapper
inoremap <tab> <c-r>=InsertTabWrapper()<cr>Great read. Among other things it made me dig deep into the heart of my Vista machine and find whatever font was making your site (and others) utterly unreadable. The answer is shitty Palatino fonts installed by HP, presumably as part of a printer driver.
So there you go, if Steve's site makes your eyes bleed then go and kill the HP Palatino fonts on your machine.
So there you go, if Steve's site makes your eyes bleed then go and kill the HP Palatino fonts on your machine.
Hmm, perhaps I should change the font stack.
Is your shitty HP font named "Palatino" or "Palatino Linotype"?
If it's "Palatino" I'll need to insert a Windows-only font at the front of the list.
If it's "Palatino Linotype" I'll need to insert a Windows-only font as the second element in the list.
Is your shitty HP font named "Palatino" or "Palatino Linotype"?
If it's "Palatino" I'll need to insert a Windows-only font at the front of the list.
If it's "Palatino Linotype" I'll need to insert a Windows-only font as the second element in the list.
Hi Steve - it's "Palatino". I also have "Palatino Linotype" and it looks fine now that I've knocked off Palatino.
It's a problem I've come across previously on Windows, I think Sun's Java was also installing some horrible version of Palatino a while back. Pity, as it's a wonderful typeface and looks nice on your site.
It's a problem I've come across previously on Windows, I think Sun's Java was also installing some horrible version of Palatino a while back. Pity, as it's a wonderful typeface and looks nice on your site.
On a side note, the Gundo feature (http://stevelosh.com/blog/2010/09/coming-home-to-vim/#gundo) is available for Emacs (http://briancarper.net/blog/568/emacs-undo-trees).
I am quite proud of my vimrc. It took me a while to build it. By default, it's just a text editor without settings required for development. Use dev to enable devmode and nodev to go back to normal text editing mode.
http://github.com/SpookyET/dotfiles/blob/master/vimrc
http://github.com/SpookyET/dotfiles/blob/master/vimrc
If anybody is curious, or just wanted to steal his .vimrc (like myself), here it is [I'm surprised he didn't provide it at the end of the article...]
http://paste.pocoo.org/show/265338/
http://paste.pocoo.org/show/265338/
Here's the BitBucket link, which will stay current as I push more updates in the future: http://bitbucket.org/sjl/dotfiles/src/tip/vim/.vimrc
I did link it in the "Important .vimrc Lines" section, but perhaps I should add it at the bottom as well.
I did link it in the "Important .vimrc Lines" section, but perhaps I should add it at the bottom as well.
A litte off topic. Much that I like vim I haven't found any plugin than can indent Javascript properly. To be honest whenever I write Javascript I just open up emacs. Is there something close to js-mode in vim?
(ITYM js2-mode) No.
I use this to indent my JS: http://www.vim.org/scripts/script.php?script_id=1936
You could use JSLint plugin to get more of the features, but I've never gotten it to feel like js2-mode.
I use this to indent my JS: http://www.vim.org/scripts/script.php?script_id=1936
You could use JSLint plugin to get more of the features, but I've never gotten it to feel like js2-mode.
A bit off the topic but a couple of doubts regarding pathogen. I installed pathogen and am a bit confused regarding the organisation of the plugins within pathogen. Say I have plugin called foo.vim, inside the bundles folder do I directly drop it or do I create a folder called foo and then drop foo.vim within it? Also say a plugin has syntax files and an ftplugin folder then do I just drop the plugin in pathogen and it is supposed to work? Is there any good doc out there explaining how to configure with pathogen?
"Say I have plugin called foo.vim, inside the bundles folder do I directly drop it or do I create a folder called foo and then drop foo.vim within it?
You need to create the folder foo with a folder called plugin and then foo.vim inside it -> foo/plugin/foo.vim
" Also say a plugin has syntax files and an ftplugin folder then do I just drop the plugin in pathogen and it is supposed to work?
Yep. Normally vim plugins are shipped in zip files that contain the structure and are meant to be installed on top of your .vim directory. All you do is instead install them into .bundles/pluginName instead. Also, since a lot of vim plugins are kept in source control anyways, a lot on github, you can simply use git submodules to version your plugins as well making updating them a cinch.
You need to create the folder foo with a folder called plugin and then foo.vim inside it -> foo/plugin/foo.vim
" Also say a plugin has syntax files and an ftplugin folder then do I just drop the plugin in pathogen and it is supposed to work?
Yep. Normally vim plugins are shipped in zip files that contain the structure and are meant to be installed on top of your .vim directory. All you do is instead install them into .bundles/pluginName instead. Also, since a lot of vim plugins are kept in source control anyways, a lot on github, you can simply use git submodules to version your plugins as well making updating them a cinch.
Thank you.
I can't get snipMate to work. Downloaded a brand-new gVim (windows 64, btw) dropped a pathogen.vim file straight from github into my vimfiles/autoload folder and copied the snipMate's files to vimfiles/bundle/snipMate.vim
I'm using the article's _vimrc.
:scriptnames lists the "plugin/snipMate.vim" files from both the "snipmate.vim/" and "snipmate.vim/after"
But when I type some snippet (like a "for" in a *.c file) and press tab, a single space (not a tab) is inserted. Pressing tabs on non-snippets inserts a tab like expected.
Am I missing something here?
I'm using the article's _vimrc.
:scriptnames lists the "plugin/snipMate.vim" files from both the "snipmate.vim/" and "snipmate.vim/after"
But when I type some snippet (like a "for" in a *.c file) and press tab, a single space (not a tab) is inserted. Pressing tabs on non-snippets inserts a tab like expected.
Am I missing something here?
I disagree with everything that he starts with 'I almost never do X so I...'
But other than that, I think this is a great list of addons and I already use a few of them myself.
But other than that, I think this is a great list of addons and I already use a few of them myself.
yeah i rely on replacing first pattern all the time!
TextMate doesn't have split windows?!
Nope. It's one of the biggest complaints about Textmate, and one of the things that led me to (mostly) switch to vim.
A lot of people are pretty upset with the author because rather than choosing to release an incremental update that adds smaller features like this, he decided on a total rewrite and got bogged down with no release in sight.
That said, Textmate still feels remarkably current despite the fact that its last major update was more than 4 years ago.
A lot of people are pretty upset with the author because rather than choosing to release an incremental update that adds smaller features like this, he decided on a total rewrite and got bogged down with no release in sight.
That said, Textmate still feels remarkably current despite the fact that its last major update was more than 4 years ago.
Couple tricks:
" this splits a netrw window in the directory of the current file, :Vexplore for vsplit.
nnoremap - :Sexplore<CR>
" I use surround.vim all the time. The default mapping for s is terrible.
nmap s ysi
nmap S ysaInteresting article. I found it a bit strange that he didn't link to or reference this:
http://weblog.jamisbuck.org/2008/10/10/coming-home-to-vim
which shares the exact same title.
which shares the exact same title.
Yeah, I didn't realize that post had the same title, even though I read it and it's a fantastic post.
I'll add a link to it now.
I'll add a link to it now.
I have nothing constructive to add beyond-- thank you Steve, what a fantastically informative post. It clearly took a lot of time and effort to put together and it is very much appreciated.
Don't lose another four years before blogging about how you finally switched to emacs from vim and bite the bullet now. Emacs is to vim as vim is to textmate IF you are a hard core software developer. Vim is best for sysadmins, simple, quick non-complex editing.
I know, I know... But when you were newly in "love" with textmate I'm sure if I said you need to switch to vim you'd say no way. Skip vim and go right to the best there is, Emacs.
I know, I know... But when you were newly in "love" with textmate I'm sure if I said you need to switch to vim you'd say no way. Skip vim and go right to the best there is, Emacs.
Agreed, but is it painful. (And yes, I swapped Control with Caps on day one)
...and once your fingers are raw, bloody stumps from typing with three modifier keys held down, then you can write about coming home to vim again! Bonus!
Seriously, can we not start yet another Emacs vs. vi argument? Neither is perfect, they both have ardent fans, pick either, get really proficient with it, and don't look back.
(Emacs user who loves Emacs's extensibility and multi-buffer design but prefers vi's modal keyboard ui. And yes, I know about viper, etc.)
Seriously, can we not start yet another Emacs vs. vi argument? Neither is perfect, they both have ardent fans, pick either, get really proficient with it, and don't look back.
(Emacs user who loves Emacs's extensibility and multi-buffer design but prefers vi's modal keyboard ui. And yes, I know about viper, etc.)
Have you noticed that all of the recent press seems to be for vim? It seems like every month there's a new "I switched to vim!" post, but never a similar emacs version, or even a mention of emacs in the switch article.
Note: I am not attempting to argue emacs vs. vim.
Note: I am not attempting to argue emacs vs. vim.
If I'm not mistaken, they're usually switching to vim specifically from textmate. The Mac + Ruby community seems to be disproportionately well-represented in blogs, probably due to a high concentration of web developers.
Some high-profile Ruby people (e.g. Yehuda Katz) wrote about switching to vim about two months ago (http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...), and it probably set off a chain reaction.
Some high-profile Ruby people (e.g. Yehuda Katz) wrote about switching to vim about two months ago (http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...), and it probably set off a chain reaction.
[deleted](1)
From the HN Guidelines: "Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them."
You have nothing new here, nor do you have any evidence to back up your claim that emacs is superior to vim for development purposes. I'm not agreeing nor disagreeing with you here - I don't have the authority to as I don't have enough experience with Emacs to make that call. Emacs is a great piece of software, and I think that we can all agree upon that here even if we aren't a user of it (such as myself), but that doesn't mean we can make un-cited statements about it.
You have nothing new here, nor do you have any evidence to back up your claim that emacs is superior to vim for development purposes. I'm not agreeing nor disagreeing with you here - I don't have the authority to as I don't have enough experience with Emacs to make that call. Emacs is a great piece of software, and I think that we can all agree upon that here even if we aren't a user of it (such as myself), but that doesn't mean we can make un-cited statements about it.
I was getting a bit tired of seeing/reading a blog post by a random convert to vim/emacs every week but this one is very good.
I feel the same way about Emacs. I use IDEs for specific development tasks (I don't generally code Java in Emacs, for example, since Netbeans, Eclipse, Idea are all much better in that context) but where content is all over the place as it often is with net development, I use Emacs.
If you're a vim user on a mac, try ViKing. It lets you use vi-like navigation throughout OSX. It's still in beta and I would love some feedback.
http://vikingapp.com @vikingapp
http://vikingapp.com @vikingapp
I've given you feedback before, but will repost it here for other HN readers.
The main reason I don't use ViKing is that the hotkeys all end up shadowing something useful or being very awkward.
If I choose Ctrl I shadow Ctrl+H.
If I choose Cmd I shadow lots of stuff, like Cmd+L in a browser.
If I choose Alt (ViKing doesn't do that right now, but I'll assume it could be added) it's quite awkward (unless I remap capslock to Alt, but I've already got capslock-as-Ctrl in my fingers).
I don't have a solution to this, but would desperately love to find one.
The main reason I don't use ViKing is that the hotkeys all end up shadowing something useful or being very awkward.
If I choose Ctrl I shadow Ctrl+H.
If I choose Cmd I shadow lots of stuff, like Cmd+L in a browser.
If I choose Alt (ViKing doesn't do that right now, but I'll assume it could be added) it's quite awkward (unless I remap capslock to Alt, but I've already got capslock-as-Ctrl in my fingers).
I don't have a solution to this, but would desperately love to find one.
Sorry I haven't fixed this yet. I've been swamped with other projects.
I was thinking about it tonight... what do you think of some kind of double-tap combo that would enable/disable ViKing functionality, like ctrl-ctrl?
I was thinking about it tonight... what do you think of some kind of double-tap combo that would enable/disable ViKing functionality, like ctrl-ctrl?
The kevincolyar account does nothing but spam HN with links to his application. I am sick of seeing him post spam each time a VIM article hits the homepage.
I'm the author and submitter of the post and for what it's worth I don't mind his comment at all.
It's relevant because OS X Vim users would probably like to use Vim movement everywhere. I know I would.
It's certainly more relevant than the "use emacs lol" comments that inevitably show up.
It's relevant because OS X Vim users would probably like to use Vim movement everywhere. I know I would.
It's certainly more relevant than the "use emacs lol" comments that inevitably show up.
Yeah, the whole vim/emacs war is so 1995.
I'm just trying to get what I think is a useful application into the hands of the people who would find it useful. If you find that irritating, just keep scrolling by.
Try contributing to discussions instead of copy-pasting the same promotional tagline.
You could also make some effort to actually understand vi — your app doesn't take you out of insert mode! Using hjkl and ypu does not somehow make anything vi-like when there's no command mode, no compositionality, and a hotkey that breaks everything else. Seriously, chording‽ If you're going to chord for movement just use the built-in emacs bindings! Instead of ^hjkl it's ^bnpf, if you really want to do something as inane as use modified letters as arrow keys.
Why did you write your cargo-cult app at all? There's at least a half-dozen InputManagers that implement true vi command modes already, and while nobody actually uses them, at least their authors appear to have actually used a vi editor before!
You could also make some effort to actually understand vi — your app doesn't take you out of insert mode! Using hjkl and ypu does not somehow make anything vi-like when there's no command mode, no compositionality, and a hotkey that breaks everything else. Seriously, chording‽ If you're going to chord for movement just use the built-in emacs bindings! Instead of ^hjkl it's ^bnpf, if you really want to do something as inane as use modified letters as arrow keys.
Why did you write your cargo-cult app at all? There's at least a half-dozen InputManagers that implement true vi command modes already, and while nobody actually uses them, at least their authors appear to have actually used a vi editor before!
I'm sorry you don't find ViKing useful. It's not meant to replace vi, it's simply meant to be a tool that vi users might find useful. I know many who do.
I assure you I do understand vi. I use it everyday. I've explored the idea of making ViKing modal but based on user feedback have decided not to go that route. I am aware of the InputManagers you mentioned but I believe I'm solving a different problem.
Thank you for your feedback, though. I do appreciate it.
God bless.
I assure you I do understand vi. I use it everyday. I've explored the idea of making ViKing modal but based on user feedback have decided not to go that route. I am aware of the InputManagers you mentioned but I believe I'm solving a different problem.
Thank you for your feedback, though. I do appreciate it.
God bless.
This is what I love most about Vim, it's becoming a universal, mouseless interface to just about everything you use a computer for, except maybe games.
So far there's a Vim plugin or mod for: Emacs, Firefox, Chrome/Chromium, Opera, Eclipse, and now even OS X. What others are there?
So far there's a Vim plugin or mod for: Emacs, Firefox, Chrome/Chromium, Opera, Eclipse, and now even OS X. What others are there?
His example .vimrc has filetype listed twice, which is redundant. This in itself isn't a big deal, but the problem these lines illustrate is.
Sentences like these are the reason for billions of blog posts about setting up an OpenSSL certificate authority all repeating the same example which the documentation explicitly mentions is the wrong way of doing things.
In fact I find that these voodoo instructions often crowd out any actual proper tech guides in the search results, all for the sake of drawing traffic to some blog...
Don't write tech guides if you can't be bothered to do the research and explain to your readers why they should do what you do and what exactly they're doing!