Lots of people seem to declare ; or , to be useless keys and remap them. They're two of my most used movement keys in certain circumstances.
I used to have , remapped to <leader> but switched back when I realised what I was missing out on. I'd advise anybody else to reconsider if they've made the same mistake I did.
Usually I use a method that I found on some Emacs-related website. It said to use text search for navigating around the file. That's why I use / pretty often. I use f, t, and related movements as arguments to actions.
I love using search interactive to navigate text. But however, getting the point to the right spot after that still feels cumbersome, in particular, moving to the beginning of the matched word doesn't seem easy.
Is there a use for `;` I'm missing out on? `;` just seems to be for stuff like "`fp` -- Oh wait, I didn't see all the p's between my cursor and the p I wanted. ; ; ; ;."
Now I use easymotion.vim which obviates that scenario.
I created vim-seek exactly for this reason, it's like f but takes always two characters, way faster than easymotion within the line (though I still use easymotion for longer distances) http://github.com/goldfeld/vim-seek
g; will move the cursor to the line of your last edit (and further through your edit history). I find it useful as a move command but also use it to remind myself of what and where my last edit was.
You can make it work in Chrome; there’s a way around the warning. Instructions are in “Steps on adding extensions from other websites” on the Chrome help page linked from that warning: http://support.google.com/chrome_webstore/bin/answer.py?hl=e.... In short, to add the user script, open Tools > Extensions, then drag and drop your downloaded 121512.user.js file into the Extensions tab.
Some small vim tweaks I've recently been using myself that I find very nice:
nmap <CR> :write<CR>
cabbrev w nope
Re-map enter to save the file. If you try to do a :w it will yell at you until you take out the cabbrev so you can retrain your muscle memory. Took me about a day to retrain.
let g:EasyMotion_leader_key = ';'
nmap s ;w
nmap S ;b
Remap s and S to be easymotion forward and backward. I never use s, since it's largely a redundant command, and didn't like having to do a two key command for easymotion. (You can set the leader key to whatever here, the nmap's are the important part.)
noremap <C-H> <C-W>h
noremap <C-L> <C-W>l
noremap <C-J> <C-W>j
noremap <C-K> <C-W>k
Move between panes with motion keys with control held down.
Also the YouCompleteMe plugin got some HN airtime but it really needs to get more. It's amazing.
And as others have mentioned using vim inside of tmux is very nice. It's especially helpful to remap the entire tmux keymap to be vim-like.
Also, does anyone have any suggestions for what to re-map Space to? I am amazed Enter and Space in command mode both do relatively useless things. Remapping space to page down is OK but I use ctrl-f/b which is just as fast imho.
I use space as my easymotion leader key. So <space>-w goes forward by word, <space>down does easymotion down, etc.
I used to use space as my "clear all searches and clear the echo-line" command, but decided space is too big and easymotion is too good to not pair them. I now use <leader><leader> to do the all-clear command.
" space toggles the fold state under the cursor.
nnoremap <silent><space> :exe 'normal! za'.(foldlevel('.')?'':'l')<cr>
" <leader>space expands with zO
map <leader><space> zO
YouCompleteMe claims to work with omnifunc-based completion engine, but I couldn't get that to work. Can't tell if it's YCM or foreplay that's dropping the ball, but they don't seem to work together (i.e. I get foreplay completions when I trigger omni completion, but not dynamically via YCM).
EDIT: disregard me, it was a stupid configuration error (both plugins mapped the same key for completion, and foreplay won)
This lets me set a macro by first wacking qq, then q to finish, and then replay it by wacking space. I find myself using quick throw-away macros that only have a use for maybe 10 seconds far more often with this setup. (Plus wailing on the spacebar to get work done can be really satisfying ;)
Split panes is pretty much the main reason I need iTerm2. That, combined with system-wide hotkey toggling (which I used to get on Terminal with Visor), and Send Commands to All Sessions mode (cmd-ctrl-i, I think) makes me a happy command liner.
- easier to change the default darkblue to be readable on black
- can configure double-click on filename behaviour (cmd+alt click in Terminal)
- can have auto-copy-to-clipboard on selection
In short, it's more like terminal applications on other OSes I'm familiar with.
iTerm2 can intelligently communicate with tmux in order to present splits and windows are handled by iTerm2, rather than within the single terminal window.
Am I the only one who doesn't like iTerm 2 because it feels slow to use? Example: Open up a file in vim, then scroll up and down quickly. The refresh on iTerm 2 is noticeably sluggish compared to Terminal.app.
The "step back in time" feature is sort of gimmicky, but does mean you can rewind even Curses terminal applications. Rarely actually useful, but it has saved me a huge amount of hassle a few times.
Vim sure, more for tmux for me to be honest. Its quicker to resize panes/select things with the mouse at times.
People that take keyboard only to the extreme strike me as adhering to the letter of the law rather than the intent. Whichever works faster for a person is better.
I think the key is having the option to use the mouse, in addition to normal Vim keyboard shortcuts. If I'm switching back and forth between Vim and a browser, for instance, I have my right hand on the mouse already, and I can scroll with the wheel, select a tmux pane, copy and paste things, etc. very easily. If I didn't have that option, I'd have to switch back to the keyboard. If I have both hands on the keyboard already, I'm probably not going to use the mouse.
> All of that can be done much more efficiently without the mouse:
Surely we don't need to get into this sort of thing here.
If you don't know how to do it without the mouse, then it's more efficient to do it with the mouse. If you don't remember how to do it without the mouse, then it's more efficient to do it with the mouse. If you just like using the mouse better, then ….
Anyway, and perhaps more importantly, it doesn't hurt any of us if anyone else values ease of use (even if it's illusory or temporary!) over efficiency.
Yes, there is. "Best" is a harder subject to tackle, but there's always "better".
di{ is obviously both quicker and more precise than reaching to the mouse, pointing at the beginning of the code block, extending the selection until the end of the code block and hitting backspace.
One may think these keybindings are awkward or hard to remember (I did, at first, they are not) but they are both faster, more efficient and more deterministic by nature. But I may be a control freak. :-)
It's a subjective experience. I, too, prefer to use the keyboard as much as possible but I've also encountered doofuses that mock that position because the mouse is "so convenient" and "there's no way it's faster to use the keyboard entirely". So I guess their better is different from my better.
>All of that can be done much more efficiently without the mouse
No. All this can be made with an extra cognitive overload provided by the use of keyboard shortcuts that makes you think you're doing something useful and/or faster than with the mouse.
Especially if you don't need to have your hand at the keyboard at all times (i.e you're just browsing code and not writing), scrolling with the mouse is way faster.
For you. But you don't get to make that decision for everyone else. Stop trying to impose your value system on others. It's clear you don't like using a mouse. Then don't. Keep using a 1970s keyboard if it suits you. Bon a petite.
Yes, openly criticizing someone's opinion (or in this case, simply stating another opinion) on a public forum is exactly the same as trying to impose my value system on that person.
By the way, you totally missed the "me" in
> Keyboard shortcuts give me precision and efficiency, not speed, and that cognitive overload you talk about is a small price to pay.
which quite clearly means that this is a subjective matter.
Thanks for helping policing the internet: we clearly don't need to debate about anything.
I agree on most points, but there is no way that wacking Ctrl-W +/-/>/< is more pleasant than just moving either your index finger or your thumb a half an inch to use a trackpoint or trackpad and instantly get the window proportions you want.
You can of course make nicer mappings, but even then it isn't as nice.
I also resize often, particularly when using vimdiff, because I often use smaller screens (either because I am watching other things in tmux panes at the same time, or because I am working on my eeepc).
No. I know what the difference is between the two.
And I know that I never use mouse in one or the other. I don't use it for scrolling, I don't use it for pointing and clicking, I don't use for selecting stuff…
REPL? no use for the mouse. htop? no use for the mouse. git/svn/hg? no use for the mouse.
How do you select text then? I'm sure there are ways, but they are certainly not intuitive and I've never bothered to look them up since I don't do this task as often.
Do you mean "select text from whatever is displayed in the terminal" or "select text in Vim"?
I never select or copy anything from the terminal: pbcopy on the Mac OS X and xclip on Linux are what I use to get stuff from the shell into the system clipboard.
I don't think that's what you ask, but in Vim, visual selection is done by hitting v (character-wise), V (line-wise) and Ctrl-v (block-wise) followed by a motion or a text-object: va{, vit and so on.
This can be fixed by editing the keybindings for your shell. Bash by default on OS X? If so Google for ".inputrc", mine looks like this:
# See http://www.reddit.com/r/commandline/comments/kbeoe/you_can_make_readline_and_bash_much_more_user/
"\eOd": backward-word
"\e[5D": backward-word # for OS X
"\eOc": forward-word
"\e[5C": forward-word # for OS X
"\C-f": reverse-search-history
"\C-F": reverse-search-history # for OS X
#Control-F: reverse-search-history
#Control-j: menu-complete
#Control-k: menu-complete-backward
set bell-style none
set completion-ignore-case on
set completion-prefix-display-length 2
set show-all-if-ambiguous on
set show-all-if-unmodified on
I might as well answer seeing as I found this out yesterday. Go to the profile options then the keys tab. Then there is an option for left/right option key acting as normal meta or +esc. While meta sounds correct for this, esc+ was recommended and works.
I recently switched to Vundle from Pathogen and it is a joy to use. Best part: you can bootstrap[1] Vundle from your .vimrc, turning the two-part "vimrc & plugins" configuration into a one-part "vimrc" configuration.
I'm not sure why the author advocates job control (ie ctrl-z/fg/bg) instead of using tmux/screen. A multiplexer offers far more flexibility, and most importantly does not lose state even if your session ends (eg ssh connection drops).
I didn't mean for them to come across as mutually exclusive. The ^Z/fg approach is great for keeping context: Go to a directory, run something, edit something, suspend editing to run something else, resume editing, finish back at the command prompt.
With tmux I'd need to create a new pane, navigate to the same directory, and reinitialize any environment stuff like virtualenv.
For Python, there is a choice of the jedi library or the rope library to do refactoring and smart completion. This in addition to ctags and the like. I imagine other languages have similar things.
Smart completion is fine to me, but the refactoring is a potential problems. It seems there isn't an open source refactoring tools as good as PyCharm for python.
My single greatest tip to make vim even more amazing is to run it in a tmux session: It makes it super easy to split panes and create new windows for related things you need to do (git stuff, compilation, running tests, running a REPL, etc.)
For anyone using tmux and vim, I recommend having a look at vimux (https://github.com/benmills/vimux). It lets you control your tmux pane from within vim.
I use two tmux windows, one of each of my screens. One is code and the other runs `make && ./test blah blah` whenever I hit F5 in vim. To get vimux to use windows (as opposed to just panes) there's a fork under pull requests (disclaimer: I wrote it).
You can easily split panes (called windows in vim) within vim. You can also create new tabs within vim for related things you need to do.
I still use tmux or screen to do other things which aren't convenient or elegant to do within vim, but splitting windows and creating tabs can be done just fine within vim itself (or, in my case, within gvim, which I prefer due to the increased color gamut and keybinding abilities over terminal vim).
This is my setup as well. I open two terminal windows: the one on the left is used for "control" stuff, and the one on the right is for code. Then in each terminal I run tmux. For a Rails project, I have separate tmux windows for models, controllers, views, stylesheets, a psql prompt, etc. I've done it long enough that I know which window has which stuff, and each vim session only has a few files open, so it's easy to `:ls` and `:e #3` around. My scripts to launch tmux look like this:
Personally I have a mapping <leader>x that starts a terminal emulator when running under X or drops to the shell otherwise. When I work on a project I cd into its directory. Executing commands is just a matter of hitting <leader>x, doing what's necessary, and closing the terminal.
tmux is fantastic, especially for remote development. However, you can't change a single pane's font size, nor is it easy to select an entire line of text using the mouse (with vertical panes). Thus I suggest iTerm2 for local development if on a Mac.
If you haven't tried multiple panes with multiple font sizes — e.g., smaller font for logs/compiling/long-running, bigger for editing — then that's a world I don't want to live in. (j/k ;)
The author mentioned CtrlP for fuzzy filename matching. Its great because it's in pure Vimscript, but in my experience it becomes unusably slow for moderately sized projects. A month or two ago, I switched back to CommandT (requires Vim to be compiled with Ruby support, engine written in C) and haven't thought twice about it since then.
It's fine with many files, the only issue is when it indexes, which can't easily be automated. I just checked and it gets through about 2000 files a second on my MBP.
I've been meaning to try out matcher[0] for usage with CtrlP, I'm not sure how well it works but it's written in C and is purported to speed up search. Not sure if it's still being maintained, however...
It works quite well. The only negative I've found is that using matcher seems to disable CtrlP's usual highlighting of which letters in a search result are matched.
There's not much to maintain. I ported the matcher from Command-T out of its ruby-C wrapper, and it more or less just works. I use it dozens or hundreds of times a day.
I've found that my impression of CtrlP's speed varies dramatically depending on the project that I'm working on. For projects such as Bochs [0] (~750 files in CtrlP), I get annoyed at the initial .5-sec wait [1], but after that it's extremely fast. I don't have a particularly fast processor, either.
I find CtrlP breaks down with large projects such as the Linux kernel. While it's fast to find the initial list of files (2 seconds or so) it's extremely slow to actually search through said list, about .5-sec per keystroke.
[0] I'm not a maintainer, I just happen to be using its wonderful instrumentation hooks in a research project.
[1] It's about half a second on my laptop, which has an SSD. This time is dramatically larger if you have a rotary drive, more like 10-20 seconds IIRC.
I use CommandT primarily on my main machine but I also have CtrlP installed and they are both mapped to the same key (<leader>f) in a conditional. If I'm on a machine that has Vim compiled with Ruby, I get CommandT, otherwise CtrlP. Best of both worlds.
One of Vim’s strengths is that it starts lightning fast, so starting Vim from the terminal is trivial. With a modern, 256-color terminal like iTerm2 or Gnome Terminal, it will even look like gVim. But the best part is that you can drop into the command line at any time with Ctrl-Z, which suspends Vim, and your working directory is where you left off.
Is there any reason to do this instead of !sh within Vim to drop into a shell?
You end up creating a new session each time when you do !sh. backgrounding Vim lets you use the same shell instance.
The other issue I have in general with the ! form is that some applications mess up osx vim. For example, try dropping into a node session (!node) and then quitting.
bind-tty-special-chars (On)
If set to On, readline attempts to bind the control characters treated
specially by the kernel's terminal driver to their readline equivalents.
Disabling it doesn't actually stop readline from binding those control characters. It just enables you to override those default readline binds. If the variable is set to On (the default), that's not possible.
Also, another thing I have noticed, is that I cannot catch the SIGTSTP (Control-Z) signal with the `trap` command. I can catch other standard signals, e.g. SIGINT (Control-C), but not SIGTSTP (along with SIGSTOP and SIGKILL, obviously).
I'm sure they mean `map fg <c-z>` in Vim so that `fg` from Vim lines up with `fg` from shell and you can repeat the same stroke to easily "toggle" Vim.
:!sh will work, but it puts you in an entirely new context (environment and CWD). :sh is just plain awful and doesn't emulate anything correctly.
I recommended ^Z/fg/bg because it's the fastest, easiest way to get to a good, functional shell if you're not using a multiplexer (tmux/iTerm2). If you map ^Z in your shell to "fg\n" then switching is lightning fast.
I think this is the explanation, I usually only find myself wanting to temporarily "stop" Vim and do something on the shell for quick one-off commands that are fine in a subshell - not to keep a backgrounded Vim instance around for longer than that. The blog author seems to have a different use in mind.
I can live without Vim but cannot without Vim mode.
All apps I have used since learning Vim has some kind of Vim bindings - Visual Studio, Eclipse, PyCharm and ST2. I also rely on browser vim plugins (vimium, vimperator).
It seems Vim mode is becoming ubiquitous in my apps.
There is some C++ file I currently don't have open, say "palette.cpp" which is in a subdirectory "project/graphics/algorithms/color/".
Now I want to open palette.cpp without ever having to type, not even with tab autocompletion, that path.
IntelliJ (which I do use for C++ ;)) can do this easily: just press CTRL+R, then palette.cpp, ENTER, and there you are in that file.
Another thing: Some IDE's and editors have this feature where if you change lines, it marks it with some color on the left, as well as colors in the scrollbar, to immediately see which parts of the file were changed compared to git and/or the last time you opened it. Can Vim do this?
with your cursor on a filename that is a legitimate relative path, you can just press 'gf' to open the file from command mode. there is also a mirrored command of '^xf' in insert mode. slightly different work flow...
^o and ^i get used a lot in conjunction with 'gf', and are also pretty handy in general.
CtrlP takes care of that. Ctrl+P and then Ctrl+F (cycle to buffers list—you can also map this to anything you want) and it will list buffers with a + next to the buffers with local edits. Ctrl+D and it will change from full path to file name search. You can cycle between buffers, files, mru files and even more (tags, etc.) with extensions.
> Some IDE's and editors have this feature where if you change lines, it marks it with some color on the left, as well as colors in the scrollbar, to immediately see which parts of the file were changed compared to git and/or the last time you opened it.
Most of the things of such kind are available as vim plugins (for the 'open file without path' thing, see e.g. http://www.vim.org/scripts/script.php?script_id=858) - you can then remap those new commands to keys/shortcuts.
> if you change lines, it marks it with some color on the left
This is the feature that I miss the most in Vim, after working 5+ years in IDEs like Visual Studio. There are some Vim plugins addressing this (at least a year or so ago, when I searched), but nothing as elegant and seamless as in IDEs.
re: git changes, after seeing such a plugin for sublime (https://github.com/jisaacks/GitGutter) I went ahead and implemented the same thing for Vim (https://bitbucket.org/sirpengi/iwilldiffer). The plugin is still in beta status yet with compatibility, and I should make it easier to install with the various plugin managers as well as make the feature async (right now, the UI blocks waiting on the diff command). But otherwise, I'm using it daily and it supports mercurial as well as git.
The C++ plugin is totally unusable and I uninstalled it immediately after trying.
But I just made a manual set of syntax highlighting rules for C++, and that's good enough for me.
The git integration and other IntelliJ features make up for the missing C++ navigation and refactoring features for me.
I do everything related to compiling, debugging, and stuff (as well as all git committing and stuff, the IntelliJ git integration is about showing changed lines) from a terminal.
Every time I read an article like this, it's how a power user installs an array of plugins and customizations to really soup up Vim, which to me kind of misses the point. If you want that level whiz-bang, use Coda or Sublime Text 2 or Eclipse or whatever.
I don't recall where I saw this, but someone advised disabling syntax coloring in your editor to remove a crutch (and, secondarily, to visually simplify your environment). I've tried this with Vim and it's surprisingly nice [0]. You have to read the code more closely, and think more carefully about what's on screen, and this has the effect of focussing me more. Simplifying my environment, making it more sparse, but always having the power of Vim available, makes for a really potent, semi-distraction-free environment.
[0] Well, mostly. I leave it on in order to have three colors used: a good contrast color for code, a second contrast color for strings, and a third, very low-contrast color for comments and line numbers so that, if I want to see those things, I can look for/at them, but if I don't, they're easy to ignore. Likewise, visually distinguishing between strings and code continues to be really useful.
Customizing your editor to do what you want doesn't miss the point. It is the point. If my editor does exactly what I want, I have no need of Coda or Sublime Text 2 or Eclipse or whatever.
You can turn off colors. That's your customization because you like it. Good. Other people want other customizations.
"If you want that level whiz-bang, use Coda or Sublime Text 2 or Eclipse or whatever. I don't recall where I saw this, but someone advised disabling syntax coloring in your editor to remove a crutch (and, secondarily, to visually simplify your environment)."
Perhaps you might enjoy using ed...
From: patl@athena.mit.edu (Patrick J. LoPresti)
Sender: news@athena.mit.edu (News system)
Subject: The True Path (long)
Date: 11 Jul 91 03:17:31 GMT
Newsgroups: alt.religion.emacs,alt.slack
When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow. They print useless messages like,
'C-h for help' and '"foo" File is read only'. So I use the editor
that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
---
Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard. Everyone else loves ed
because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
-rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code! I just want an EDitor!!
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely
you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you
are an idiot, you should use Emacs. If you are an Emacs, you should
not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
?
He said he tried using Eclipse, and his Vim setup was more productive. Apparently that means that Vim can not only beat Eclipse at being a sparse minimalistic editor, but also at being a whiz-bang IDE.
In short, according to the OP, if you want that level whiz-bang, you should switch from Eclipse (and presumably Coda or Sublime Text 2) to Vim.
A lot of us do development on remote servers. Using vim in a terminal on the server is a heck of a lot snappier than a local editor over a remote connection. Also makes reconnecting your dev environment as easy as tmux a -d and allows me to do so from multiple machines.
someone advised disabling syntax coloring in your editor to remove a crutch (and, secondarily, to visually simplify your environment) ... You have to read the code more closely, and think more carefully about what's on screen
I don't want to have to think more carefully about things that don't matter like syntax. Highlighting gives you visual clues so you can get meaning from code more quickly and get on with it, instead of having to read everything carefully.
It is funny, I use vim pretty much everyday for a decade. I install vim, I use "write", "close", "quit". I semi pretty vimrc file with line numbers and syntax highlighting.
I am still not very good at opening multiple buffers, I just close vim and open the other file.
But that is about it. I felt I have doing it wrong. But I can get work done and it is easier everytime I install a new server.
In Star Trek the next generation; as different users interacted with different physical platforms (tablets, desk consoles, wall panels, tablets, voice activated devices, "desktops", etc), the work space would adapt to it's physical medium....so....I'm sold!
I've been looking for something like this for months. I've also never heard of easymotion or YouCompleteMe. How is it that I've been out of the loop for all these things ??
When I try to access a remote ftp directory, I can only open the directory that I typed in a path to. As soon as I navigate through the listed directories and hit enter on any, the screen splits into two horizontal panes and the top pane reads "File not found".
I tried this from Windows 7 Gvim/Vim (don't have the version handy but it was 7.3+) and it worked as expected.
From what I gather it just doesn't seem to look for the right directory after I hit enter in the list I think. Maybe it skips an extra forward slash somewhere or something?
I understand we're not really on the netrw/vim mailing list but any response would be appreciated!
I've recently uninstalled NERDTree in favor of netrw and I've been presently surprised at how little I miss NERDTree and how much more productive I am on default vim installations.
One thing NERDTree does that netrw doesn't (IIRC, haven't looked very deeply into this) is open files you select in a different window than the one that contains the file listing. I happen to find that convenient, YMMV, of course.
Almost, but not quite. o opens a new window with the selected file, while nerdtree opens the file in the most recently used non-nerdtree window.
Also, there doesn't seem to be a way to tell netrw to create a vertical split rather than a horizontal split, which is inconvenient on modern wide screen monitors.
Good suggestion. In the article, I failed to point out that the advantage of NERDTree is its hierarchal folder view. When a project's directory structure become gigantic it's useful to see the directory structure as you edit.
Instead of NERDTree you might want to try Vimpanel, it's based on NERDTree but much more evolved, and instead of using :bprev/:bnext you might want to try Bufstop, it uses history instead of the buffer list to get you to the previous buffer. I made these to get around some limitations for some plugins that everyone seems to suggest.
Am I the only who tries not to override default commands? It's not like I use them all, but I might learn it at some point, and I want to have them available.
Trust me, when you have really crappy hardware (Intel Atom 1.3GHz w/ 512MB mem), you will notice the difference. Execution of commands that takes 2-3 seconds on Gnome Terminal will be nearly instant on xterm.
set undofile " This creates a undo file that persists your undo history when the file gets closed
imap >> <ESC> " Double right arrow to escape from insertion mode. This is faster and more comfortable (at least for me) than to reach for tab key for some people
set clipboard=unnamed " This is bridges between your Vim yanks and your system clipboard
Some people use jj to go to the normal mode. Personally I remapped Caps Lock to Escape in my whole system, so I can go to normal mode easily.
You can yank to the system clipboard by providing appropriate register to yank into. You do that by pressing "* before the yank command (e.g. "*yy to yank the current line).
Recently, I made the switch to vim from Sublime Text and I have installed some of the same tools. So far, I've committed to vim, but I have found that the plugins for file searching, linting, etc. are easier to use, more intuitive, and less painful to setup in Sublime Text.
Does any vim plugin support context sensitive auto-complete like Visual Studio (auto-complete only with variables that are alive in the current block of code)? I code in perl and am currently using ctags for autocomplete, but it doesnt autocomplete based on the context.
The important bits are vim's built-in omnicomplete and neocachecompl
Omnicomplete by itself isn't bad. I haven't seen any excellent documentation explaining how it all works, but even without my .vimrc I use C-X-f a lot to complete filenames.
iTerm2, at least, can show underlines where you'd expect squiggly lines in GUI vim. It's not as nice as the squigglies but it's pretty functional in practice.
I can recommend CtrlP (or Command-T). I can't imagine navigating in a project without them. They also have great buffer navigation. Personally I mapped <leader>t to CtrlP file search, and <leader>b to CtrlP buffer search (:CtrlPBuffer).
Sometimes you want to indent more than once. This remap is fine, but the idiomatic way to do this is just to use a period to repeat the last command. It doesn't hurt to get used to that.
I'm disappointed no one's mentioned digraphs yet. I've used emacs for years, but I'm starting to use vim now because ctrl-k G* etc is just so easy (I type a lot of math).
If that's your only reason, stick with emacs but use evil-mode. I flip-flop between liking evil-mode (when I'm mostly just editing stuff) and preferring standard emacs keybindings (when I'm switching a lot between shells, dired, interactive sessions, etc.)
I use nvi, and have tried to switch to vim a dozen or so times over the years. But there are so many irritating little quirks and misfeatures and annoyances that I can never manage to fix. Does anyone know of a guide to getting a sane, non-broken vim working with some basic plugins like syntastic? Last time I tried I couldn't bind F-keys for some reason, I couldn't get syntastic's error marking column to stay on instead of shifting my text back and forth all the time, I couldn't get auto-complete mapped to tab properly, and a few other things I can't remember now. I eventually gave up again as the extra functionality of vim ends up being counter-productive when none of it works right.
>>Last time I tried I couldn't bind F-keys for some reason
F keys bind fine for me, using OS X Terminal, and gnome-shell in linux. Are you using an esoteric term?
>> I couldn't get syntastic's error marking column to stay on instead of shifting my text back and forth all the time
That is using the SignColumn part of vim. As far as I know, vim doesn't allow you to force the existance of SignColumn. You can open up a bug report at their Google Code repo if you think its worthwhile
It sounds like you want vim features. But vi compatibility mode is probably not consistent with these. Mapping f-keys should work fine in a GUI vim, but in a terminal F-keys may depend on configuring the terminal. You don't have to use syntastic if it doesn't work right for you, you can just use individual checker plugins or set makeprg and use :make. Mapping auto-complete to tab depends on not having multiple plugins fighting over the key. Most of this is a matter of particular plugins, not vim itself.
Right, I want some of the vim features, mainly plugins. I don't enable vi compatibility, it isn't even remotely vi compatible and it just breaks stuff. I want syntastic, that's the primary motivation for trying to get vim working. I just want it to be helpful instead of irritating. No plugins are messing with tab, I am just trying to get it to work using a normal mapping.
I used to have , remapped to <leader> but switched back when I realised what I was missing out on. I'd advise anybody else to reconsider if they've made the same mistake I did.