Coming Home to Vim
stevelosh.com
stevelosh.com
"I’m not entirely sure what the filetype lines do. I’ve read that they’re necessary and so far I haven’t had problems."
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!
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
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.
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.
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
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!
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
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.
Yeah, I definitely need to get around to reading :h filetype.
I mentioned Snipmate in the article, so I know about it :)
It would be helpful if it mentioned that somewhere...
It is a good start to a simple but yet powerful vim configuration, especially integration with screen, pastetoggle, etc.
Anyway, might as well join in too, here is my vimrc: http://gist.github.com/144742#file_gistfile1.vim
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.
: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
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/
I used to use FuzzyFinder_TextMate, but that's stopped development, and the creator recommends you use Command-T instead.
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 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.)
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
edit: Many of the most popular textmate schemes have already been converted and can be found at http://github.com/squil/vim_colors
My favourite is earendel (http://www.vim.org/scripts/script.php?script_id=2188)
> 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.
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.
I totally agree with you about the clipboard issues though.
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.
Should help with indentation issues.
That is what I use.
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.
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.
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.
I gvim you could have used the mouse too.
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>
Try :set paste :set nopaste :set invpaste :help paste
fyi,
:set paste :set nopaste
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.)
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.
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.
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.
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.
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.
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.
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.
"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>So there you go, if Steve's site makes your eyes bleed then go and kill the HP Palatino fonts on your machine.
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.
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.
I did link it in the "Important .vimrc Lines" section, but perhaps I should add it at the bottom as well.
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.
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.
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?
But other than that, I think this is a great list of addons and I already use a few of them myself.
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.
" 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 ysawhich shares the exact same title.
I'll add a link to it now.
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.
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.)
Note: I am not attempting to argue emacs vs. vim.
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.
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.
http://vikingapp.com @vikingapp
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?
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.
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?
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.
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 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.