On top of that the whole "language of editing" and combining noun,verb,adjective commands, etc... doesn't really appeal to me because I'm too visual when I'm editing code. I can't stop to think about the right semantics about what I want to do, I just do it visually.
After the initial learning process, you don't think about the right semantics of what you want to do. Learning vim's normal mode really is very analogous to learning to touch type. In most text editors, when you want to delete a word, you don't really think about hitting backspace a whole bunch of times. Of course, you did think about hitting backspace when you first started. With vim, you don't really think about hitting dw (or cw), you just do it. You did your thinking a while ago, and now it's just how your fingers move.
Of course, there are plenty of valid reasons why vim might not be for you, so please don't take my comment as a "No, you really should learn vim" piece of evangelism.
This is exactly the reason I decided to make what is probably a lifetime choice to use vim going forward. The vim defaults are ideal for general purpose editing. It's true an IDE or the right modern editor might have things set up with nice defaults for x or y language, but pick five editing tasks at random and you'd be hard-pressed to find a better editor out of the box than vim.
Being able to competently edit any file out of the box on any system affords me a great mental flexibility. It lowers the barrier for learning new languages, or even switching platforms (I like OS X now, but I don't want to be locked in forever when Apple dials up the consumerification to 12). The main disadvantage is that vim really can't compete with IDEs for boilerplate-heavy verbose languages like Java, but I'm not particularly interested in learning languages like that.
Now it's true that I will tweak my config and go and seek out some plugins to enhance my core workflows slowly over time, but that's just the icing on the cake. Mainly I focus on mastering core vim and I do with reasonable confidence that the investment I'm making now will pay dividends 10, 20 and 30 years from now.
> On top of that the whole "language of editing" and combining noun,verb,adjective commands, etc... doesn't really appeal to me because I'm too visual when I'm editing code. I can't stop to think about the right semantics about what I want to do, I just do it visually.
It's one thing if you like a polished GUI and you just can't feel good about vim's lack of polished OS integration and GUI features, but with regards to thinking about semantics, these commands all become muscle memory and you end up doing most of them on a subconscious level that is hard to describe unless you've experienced it. I wouldn't write it off based on the assumption that it wouldn't work for a "visual" person.
However, just like any other tool you use on a regular basis, those commands become muscle memory very quickly and you don't even think about it.
Now I use vim for work, mostly editing c code. I have a very barebones vimrc and have never installed a little bundle or package. I use it mainly because of its simplicity and terminal integration.
I can't say I'm a very visual person though. I get distracted with too many bells and whistles and often times even just switching windows causes me to get distracted by the interwebz (...i'm a bit add), so I like the simplicity of a blank screen.
Point being, vim isn't for everyone, but using vim doesn't have to be this big giant complicated endeavor that everyone seems to make it out to be.
(Small confession: I also really feel kind of bada$$ when I'm sitting behind a black terminal with green text...)
While this is obviously a matter of taste, I do like vim's minimalism in that you start off with a simple core with sensible defaults and just add any features you want (I use tcomment, command-t, and fuzzyfinder for switching buffers - that's pretty much it, my .vimrc is less than one page). I found vim much easier to get into than emacs (which I'm currently using for most heavyweight coding sessions) where the defaults are (imho) not as sensible and you have to dig through tons of stuff that comes bundled with it, instead of understanding everything from the beginning and building from there. Of course, it's great to be able to extend emacs with elisp to do any stuff you feel is missing, and I've generally felt it easier to integrate the whole dev experience (minus the browser) into it than with vim - but such usage was of course never in harmony with vim's philosophy in the first place.
On top of that the whole "language of editing" and combining noun,verb,adjective commands, etc... doesn't really appeal to me because I'm too visual when I'm editing code. I can't stop to think about the right semantics about what I want to do, I just do it visually.
Like the rest of vim, these things just become muscle memory - you will completely stop thinking about what command to use after a bit. The reward is getting all those micro-level text editing tasks done with fewer keystrokes, minimizing the time you spend typing and therefore the disconnect with the thought that preceded the typing. I think this dynamic is really great when you get into the zone and want to let stuff flow out with as little neuromuscular obstruction as possible :P
I think the vi/vim editing model is a genuinely important contribution to text editing technique, much more so than vim the program, but of course you can use vim keybindings in lots of other editors and IDEs and still get the core benefits, assuming the most important vim-powers have been implemented.
You can get awfully far with just the built-in application and maybe something like CommandT to help navigate projects, especially if using a GUI editor like MacVim to make tab navigation easiest.
By the sound of it Vim might just not be your thing. I switched to Emacs 15 years ago after many years of advanced vi & Vim usage and never looked back since I never really liked modal editing.
I've used vim a great deal in the past and it really is exceptional for editing a given file. The thing that really tipped me to ST2, though, was its management of multiple files in a project. The sidebar and Goto Anything are indispensable. I know vim has command-t, but I just haven't been able to browse a family of related folders as easily. How do others do it?
Also, I just can't get used to the line-by-line scrolling of vim and emacs vs. the pixel scrolling of Sublime, or TextMate, or even TextEdit.
Also what's the point of displaying a third of the height of a line?
The moment I start Ctrl-P in Vim, it takes about 20 seconds just to index and then when I began to type, the letters I type appear really slow and it takes ages for it to actually type out the whole word. Same when I delete a word by hitting backspace.
Command-T is, I would say, 40% faster for me but there is the same lag when typing/backspacing.
However, both methods I know for doing this only work inside an X server - does anybody know a good way to remap keys without X?
Use the showkey command to find out what keycode the caps lock key generates (mine is 58), then add a line in your layout file to the effect of
keycode 58 = Escape Escape Escape Escape Escape
Finally, load your new layout using loadkeys /usr/share/kbd/keymaps/i386/{yourlayoutname}/{yourlayoutname}.map.gz
sudo loadkeys keys.kmap
This works, but I haven't set this up to load on startup yet.
I am tempted by Sublime Text and Vim, but can't live without a few Emacs features these day. But sometimes I miss the fluidity of Vim.
That said, I found the most important influence on my productivity is fun. I am most productive when I enjoy what I am doing. And this is very directly influenced by the way I do the clickety-clack thing with my keyboard.
In fact, I sincerely think that Vim is the most efficient text editor out there. Nothing else comes close. The thing is, me personally, I am having more fun elsewhere, for reasons that have little to do with text editing performance.
Mind you, this is not critique against Vim. But I would like to discuss text editing productivity in terms of fun instead of keypress efficiency. Whenever anyone argues about the relative merits of EditorX against EditorY in terms of key presses I feel like he is missing the point.
What do you think about this idea/argument?
At the moment I'm using Emacs with EVIL (Vim layer) and loving it. You should check it out :)
It really does not matter why your text editor of choice is making you feel good, but as long as it does, you will be more productive in it than in any other one.
I'm actually a die-hard Emacs user. I like the idea of Vim's modes and more efficient keyboard commands, but I can't leave all my Emacs features and plugins and customizability (I've even written some simple major modes). However, I'm really considering learning how to use something like Evil one of these days and (hopefully) have the best of both worlds.
That said, my mind is incapable of handling both Emacs and Vim at the same time. When I used Evil, I would forego all the greatness Emacs provides in favor of Vim.
Still, maybe Evil makes more sense coming from Emacs than coming from Vim (aka maybe I should try it again).
> What do you think about this idea/argument?
Unless you can tell what is the fun part, and what are the reasons you are having more fun elsewhere, I don't know what do you want to discuss.
What do you think is fun in Emacs and not in other editors? What was unfunny in Vim?
I'll be totally honest, it takes time and a real commitment to using Vim as your only editor. But, over time, you'll start to think in this text objects and, combined with the "commands as a language" concept--that's when Vim will really start to show it's power.
You didn't mention the fact that all of this becomes addicting rather quickly: going to a more "normal" editor or textarea can be extremelly frustrating some times.
E.g. 't' is a motion command which takes you 'till' a particular character. The same command even works with 'Visual Block Selection'. Most of the other editors have a different work flow for 'Block selection' and they are not friendly at all.
And if you are starting out, I would HIGHLY recommend the book 'Practical Vim' http://pragprog.com/book/dnvim/practical-vim . The book teaches the 'The Vim Way' and to be a good Vim user, you have to understand the 'The Vim Way', there is no way around it. Good luck!
http://blog.carbonfive.com/2011/10/17/vim-text-objects-the-d...
http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...
This is why I never stoop to pedantry. I know the difference, I swear!
FYI my transition was Notepad++ > TextMate > Sublime Text 2 > Sublime Text 2 + vintage mode [1] > Vim.
I changed my default editor at work to be Vim, and started doing all my dev work at home through Vim. I started off just using the arrow keys to move and just using insert mode to edit text the normal way. Each day I tried to add one new command to my repertoire; I learned about how to structure vim commands (c-change i-in w-word, etc.) and move using hjkl and the higher order movement commands like w and b. Now I can maneuver my way around vim quite confidently, and although when I started off I was much slower in Vim than other editors, I now find that Vim is just as fast or faster for most tasks, particularly where I can make use of Macros.
At the moment I still have to get my head around markers and a few other concepts, but I've definitely become proficient enough for it to be worth the effort and time invested so far.
My tips for anyone learning to use vim for everyday development would be some common tab commands: :tabnew <path> to open a file in a new tab, :tab sball to show all currently open buffers in separate tabs, gt and gT to jump to the next/previous tabs.
I don't use tabs because I don't find them useful at all. If I need to see 2 files at once, split panes it is; if I am switching between files, I have them open as buffers(NERDTree and BufExplorer makes it pleasant).
> I use tmux as my window manager for my terminal, so I have not use for panes in vim.
I use tmux as well. The only times I use tmux panes is when I need to run shell in the same window.
> I just have a bunch of vim processes running and use tmux for the window management.
And I have one vim process running for one project root. Coding rails? Open vim in top folder and open all files from there using rails.vim navigation commands(:Rcontroller, :Rmodel...) or NERDTree and switch between them using BufExplorer.
This is because all the state is shared within a single Vim: buffers, copy-paste information, and so on.
http://superuser.com/questions/39384/best-grep-like-tool/342...
Ack isn't the only thing better than grep. If you're searching in Git repos, you might want to check out git-grep. Another useful tool is Exuberant Ctags: http://ctags.sourceforge.net/
The reason I took "betterthangrep.com" as a domain name, besides it being catchy, is that I want people to think beyond stock grep as a tool, to know that they have options. The page http://betterthangrep.com/more-tools/ is just a listing of other tools that may be better than grep, depending on the use case.
Ack
If you’re a programmer and you don’t know about Ack, you need to start using it now. It’s far, far better than grep.Instead of taking us on a long biographical journey of how you found the One True Editor (this week), why not familiarize yourself with Amdahl's Law?
au! BufRead,BufNewFile * lcd %:p:h
This makes it so that when you open a buffer, you cd to the current directory (only for that window), so you can quickly open files in that directory.
[% is the current file relative to pwd, :p converts to a full path, :h takes off a path component, lcd does a cd but only for the current window]
Another tip is that when your internet connection sucks enough for SSH lag (tethered, free wifi, whatever), you can edit a file locally and have vim do the SCP back when you write:
:e scp://you@somewhere/path
Boom!
" Allow easy navigation to relative files
cmap %/ %:p:h/
set autochdir
Thanks for the laggy SSH tip.
However, I really don't like the configuration system for vim. Reading the article above, I lost interest when he started talking about his .vimrc file and the plugins he used. It seems arcane to have to have these cryptic settings, whose functions aren't immediately obvious, and write them to a file. I understand that part of the VIM philosophy is that it's almost like a language, or that it's like programming your text, but configuration is just something that you (ideally) set once, and then forget about. Even if I do learn what "nnoremap <leader>ft Vatzf", if I need to set up my environment again, I'll likely forget what it is and why I needed it in the first place. And even if I configure VIM to have the things I want (for example, NERDtree for project navigation), it'll never look or feel as intuitive as having a graphical interface.
So it seems when people talk about VIM, it seems that they're really talking about two things: the control scheme (keybindings) and the editor itself (the environment).
Being an android developer, I use eclipse. I use the "Vrapper" plugin, which gives me vim keybindings in the eclipse editor. I love it. It gives me the vim navigation that I know and love, but the environment and tools provided by Eclipse. I think this is how it should be - the environment of the editor is best handled separately, and although you can add a ton of plugins and configure the crap out of VIM to turn it into an IDE, it'll never really be a proper IDE.
This is why I'm still looking for an ideal lightweight text editor/IDE. My ideal for linux would be Geany, but with Vim keybindings. I discovered Vico yesterday, which looks interesting, but is OSX only at the moment. Might be what I'm looking for, but we'll see.
With some experience and the right mindset, Vim's language becomes second nature and a mapping like yours is very easy to understand.
The thing is that too many people, me included at the beginning, follow the "learn -> customize" path in the wrong order: "customize -> learn"; often because of articles like this. This lead to a non-productive mix of plugin-addiction and mappings-dependance that's rather obviously counter-productive.
The ideal path would be to first learn how to use plain Vim then use this knowledge to customize it. This path leads to a short .vimrc and a lightweight .vim directory while the other leads to a miles-long arcane .vimrc and a bloated .vim directory.
http://ontwik.com/tools/vim-from-novice-to-professional-by-d...
To copy a line in Vim you just have to press 'yy' but there is no copy line command in Emacs out of the box. What you can do is C-k, C-y, i.e cut a line into clipboard and paste it back to have copy line effect.
But trying and learning different tools is obviously useful. Emacs introduced me to ido-mode and org-mode. Now that I know of the possibilities, I can search for and use similar plugins in Vim.
That sounds like another good trick. But then how do you jump to your next f,F,t? I find myself frequently typeing "f=" to find "=" and then hitting ";" to jump through all the "=" in that line and reach the one I want.
But, for example, I use ',' as my <Leader>. So that I can still use ',', I also map ',,' back to ',' functionality:
let mapleader = ","
let maplocalleader = ","
nnoremap <leader>, :normal ,<CR>:<CR>[0]: http://vim.sourceforge.net/scripts/script.php?script_id=2174
Don't become too plugin dependent too early, but a quick browse through some other's dotfile repositories (yadr is worth looking at, especially if you are on a mac - not necessarily to use, but definitely to see what's possible). Things like EasyMotion really make you think. As do things like persistent undo files. (gundo and other stuff)
At some point you should be buildilng up your own set of dotfiles from scratch.... not just relying on someone elses (some day some bug hits you and you have no idea where to start otherwise)
> "I don’t buy the “you’re thinking 90% of the time and only typing 10% of the time, so your editor doesn’t really matter” argument. Even if the premise is true, the conclusion is wrong."
Interestingly to me, people never (or rarely) attempt to improve their thought process, which would probably result in a much higher increase in productivity than editor proficiency.
nnoremap / /\v
vnoremap / /\v