Background
Vim 7.3 all platforms.
Vim allows the user to open a file "hyperlink" by pressing gf.
Problem
Goal
Find a solution that makes gf work with tab-page as the default behavior.
Details
The current default behavior opens the new file in the same viewport, but sometimes a user might want to open the new file in a different tab using the Vim tab-page feature.
Alternatively, a user may wish to always have gf use tab-page and never open the linked file in the same viewport.
Vim allows the gf command to open in a new tab, but it requires the user to type control-W <C-W> before invoking gf.
The existing approach is not optimal, because the keystrokes are cumbersome and introduce the risk of repetitive strain injury for users who make heavy use of the gf command.
See also
Vim help:
:help gf
:help tab-page-intro
:help tab-page
:help tab-page-commands | /_gf
:help CTRL-W_gf
Desired solution
It would be desirable to do away with the need to type <C-W>gf all the time, in order to save keystrokes and reduce the risk of repetitive strain injury.
Failed attempt
The following attempt did not work (use a normal command):
:normal <C-W>gf
Questions
why does not :normal <C-W>gf work as expected?
what alternative approaches will work to make Vim exhibit the desired behavior and reach the goal?
The answer to your first question:
What comes after :normal is supposed to be raw key presses, as you'd type them in normal mode. What you used means nothing so it does nothing (you are lucky, it could mean something and fuck up your entire buffer!).
It would work if you inserted the raw representation of <C-w>:
:norm <C-v><C-w>gf
which should look like:
:norm ^wgf
The answer to your second question:
nnoremap gf <C-w>gf
Related
The motivating story (TL;DR)
Terminals, due to historical reasons, won't distinguish tab from Ctrl+I. This makes quite a mess when I use Vim: my muscle memory tells me that Ctrl+I shall advance me forward to the next position in the "Jumplist", but some Vim-plugins do remap the tab key to do other good stuffs.
Better defined task
Can I make a "conditional mapping" for active windows from ahk_process gvim.exe when no "special characters" are shown at the bottom left corner of the active Window?
For the window on the left, the Vim session is in "Normal-mode"
For the window on the right, the Vim session is in "Insert-mode".
Other modes do exist, like Visual-mode
At the end of the days, I would like to map the tab key only in "Normal-mode". The best that I can come up with is to OCR a fixed region of pixels at the buttom-left corner, and make it a conditional. Yet, I am inexperienced for getting OCR jobs done in AHK.
Sidenote: I am asking for help from the Vim community the flipside of the same question: https://vi.stackexchange.com/questions/18796/may-i-have-a-vim-session-report-its-mode-in-its-window-title
No need for OCR/AHK hacks.
:nmap (and :nnoremap) maps only in normal mode.
:imap (and :inoremap) maps only in insert mode.
etc.
See :help :map-commands for the variety of different mapping commands for variety of modes.
If a plugin is overwriting a normal-mode mapping for Tab, see who the offender is by using :verbose nmap <Tab> (or its equivalent, :verbose nmap <C-I>), then look at its documentation to see how to rebind it (or in the worst case, eliminate the culprit).
There's no need to grab Vim's current mode to make it available to another application; that would be really cumbersome. If your eventual goal is to send different keys for <Tab> / <C-i> to Vim (e.g. <F13> instead of <Tab>), and you only want Vim to react differently in certain modes (e.g. normal mode), you can just map the other modes to again unify both keys:
:nnoremap <F13> ... " Functionality A
:nnoremap <C-i> ... " Functionality B
:map! <F13> <C-i> " Both keys continue to do the same in insert and command-line mode.
Relatively new to VIM and having a great time using it.
One very minor annoyance I've been having is command mode character navigation when I want to revise a command. I'm used to using readline shortcuts on the regular (non-vim) command line but these shortcuts don't seem to work in : command mode.
For example, using ctrl + b to go back a character ends up sending me to the start of the line, or using alt + f to go forward a word ends up clearing the line and exiting command mode.
The only way I've found to navigate in command mode is to use the arrow keys, but I'm under the impression you should avoid the arrow keys in vim for max efficiency.
What is the standard way to navigate around in : command mode? Do vim users usually use the arrow keys here? Is there a different way to modify commands?
As a more concrete example, I've been using vimgrep a lot to search through files. I'll do a command like:
:vimgrep /font-family/j my-project/**/*.less | cope
Later, I'll want to use the same search but look for a different property, so I hit : then ctrl + p to access my previous vimgrep. Now here I have to use the arrow keys to navigate backwards to the search string and modify it. It would be much faster if I could use readline to navigate backwards by word then delete by word.
For small edits, Backspace and light use of the cursor keys should be fine. For anything larger, I would advise to use the command-line window:
In the command-line window the command line can be edited just like editing
text in any window.
So, there's no need to mentally switch to readline key mappings; just use the full editing power (including any custom mappings) of Vim!
You can switch via <C-F> from the command-line, or directly enter it (from normal mode) by pressing q: instead of :. All the details can be found at :help cmdline-window.
I like this question. Long time vim user, but new-ish here, so I can't vote it up. But indeed, perhaps unofficially, many vim fans feel that most of the time the goal is to not have your hands leave home row position (fingers move, hands relatively still).
I will admit, when it comes to command mode, I use the arrows. With P being on my pinky finger, I would miss-hit ctrl-P a lot, and it's faster to slide my right hand down (on my Natural keyboard) and find the up-arrow by quick feel, instantly, to do the same thing. Once I'm there, left-right arrows are also easy to find without looking or delay. Also Ctrl-arrows let you skip by word.
One of the great things about vim is the :help. I have easily spent tens of hours over the years reading through it, and it solves 95% of my problems if I have enough time and working-memory to push deep enough into it.
Here is what I found for :help readline:
READLINE readline.vim ft-readline-syntax
The readline library is primarily used by the BASH shell, which adds
quite a few commands and options to the ones already available. To
highlight these items as well you can add the following to your
|vimrc| or just type it in the command line before loading a file with
the readline syntax:
let readline_has_bash = 1
This will add highlighting for the commands that BASH (version 2.05a
and later, and part earlier) adds.
Give it a try! (I am using vim 7.4)
You can see a list of the default key binds with :help cmdline-history (scroll down a bit) and :help ex-edit-index.
You can remap this with cnoremap:
cnoremap <C-b> <Left>
cnoremap <C-a> <C-b>
" .. Probably more
Note that using cmap will probably get you into problems here since the right-hand side is the currently mapped action, whereas with cnoremap the right-hand side it will always use the native Vim action.
I use NERDTree with the setting:
""""
" NerdTree
"
Bundle 'scrooloose/nerdtree'
Bundle 'jistr/vim-nerdtree-tabs'
map <F2> :NERDTreeTabsToggle<CR>
I can open any number of tabs with the same file by pressing 't'. For example:
|foo.txt|bar.txt|foo.txt|foo.txt|
How to prevent the opening of duplicate files? I want to open an existing buffer by pressing 't'.
I found the solution here https://github.com/scrooloose/nerdtree/issues/439
Grab the latest version and stick this in
~/.vim/nerdtree_plugin/override_tab_mapping.vim
https://gist.github.com/scrooloose/0495cade24f1f2ebb602
Thanks #moeabdol
From what I understand NerdTree does not have such a behavior. I believe however what you are looking for is either :tab drop like #Ben mentioned or using :sb to switch buffers with the following setting: set swb=useopen,usetabe.
Personally I would suggest you use NerdTree for more of a File Explorer and less of a file/buffer manager. By leveraging Vim's buffer commands you can easily switch between buffers. Additionally by using Vim's buffer commands you can avoid the "one-to-one: file-to-tab relationship trap" that so many new vimmers get stuck on.
Aside about NerdTree
NerdTree is very helpful to explore a complex or unfamiliar file structure, but it comes at the cost of taking up screen real estate and disrupting buffer and window/split workflows. See Oil and vinegar - split windows and the project drawer for more. Using a nice fuzzyfinder plugin like CtrlP often takes the place of NerdTree for many people.
I have a nice post about NerdTree that might be of value: Files, Buffers, and Splits Oh My!
Aside about tabs
Vim's tabs are not like most text editors tab. They are more like viewports into a group of windows/splits. Additionally, Vim is buffer centric, not tab centric like most editors. Therefore using features like the quickfix list is often easier without tabs (See :h 'switchbuf if you must use tabs). Vim's tabs often get in the way of using a splits as there are better window and buffer navigation commands available. I personally have many files open (sometimes 100+) use no tabs and use on average 1-2 splits without any issue. Bottom line: read the following posts:
Why do Vim experts prefer buffers over tabs?
Use buffers effectively
Best practices with Vim mappings
Supply a mode. So :map becomes :nmap
Unless using a <Plug> or <SID> mapping you should probably be using :noremap
By following these 2 rules your mapping will become:
nnoremap <f2> :NERDTreeTabsToggle<cr>
to open a new buffer, just press o
While vim's way of doing things is generally good, I feel like there are aspects that really get in the way as somebody who is not completely committed to vim for text-editing.
This means that I am hitting Esc+/ and typing slashes into files in Sublime Text, and hitting Ctrl+F in vim, scrolling down a page.
Similar things happen with Ctrl+S and :w and custom mapping ; to : still doesn't make it as convenient and fail-safe as Ctrl+S. Not to mention in PuTTY, Ctrl+S does something rather upsetting (it suspends output from the terminal till Ctrl+Q is pressed). Basically, IMHO some things (like switching to a "find mode" and saving the file) are good to attach to a global left-hand home-row shortcut chord rather than requiring the user to mess about in a modal command line. It simply is too often used to subject the user to these mode changes. I suppose this isnt a legitimate complaint because the entirety of vim is constructed around the modal concept, and these functionalities are a result of that.
In any case I'd like to make it a bit easier on my brain because I've tried for a while now to keep it all intact and it's simply too much (I have more or less internalized the switching between Ctrl on a windows machine on a desktop keyboard and the use of the thumb for the Cmd on my Macbook, but this modal text editor business seems to be too much). It did not take too much deliberation for me to decide that global homerow key chords are simply more intuitive.
Mapping Ctrl+S to :w is trivial, so the question here is about the find mode. I want to bind Ctrl+F to put me in find mode, but repeating it should not type slashes into the find command. Can this be done? Is there perhaps a colon-command that when executed simply drops me into the current find-command-buffer-thing?
In your .vimrc add:
inoremap <C-f> <Esc>/
noremap <C-f> <Esc>/
In whatever mode you are in, this will put you in "find" mode (it actually just types a slash in the command line which you can use to search). With these bindings it will work for all modes, even if you are in insert mode.
do you want this?
nnoremap <c-f> /
if you like you can also try
nnoremap <c-f> q/
the 2nd mapping brings you to a search history window. you could choose previous search keywords/patterns. also available to type new pattern (by pressing i)
btw, there is no find mode
Mappings can be defined separately for the different modes in Vim, see :help map-modes. This automatically takes care of your proposed <C-f> mapping: Initially, you're in normal mode, then the search pattern is entered in command-line mode.
If you so far only occasionally use Vim, and find it too "different", several things may make the switch easier:
easy Vim (evim or vim -y) defaults to insert mode
on Windows, :behave mswin and the $VIMRUNTIME/mswin.vim script create some common Windows shortcuts
graphical GVIM has menu items like Edit > Find... and toolbars.
Some things like the flow-control freeze on <C-s> in terminals are unfortunate, mostly historical accidents; you can't blame Vim for those.
You don't need to map anything. / is expressive enough and is definitely not slower than <C-f>. Same for <C-s> which, despite a certain familiarity, is not much better than :w<CR>. You are learning a new tool, remember?
What you should focus your efforts on is getting confortable with Vim's modality. The simple fact that, for you, doing a search involves hitting <Esc> is a sign that you didn't get that part. Your other comments on using Vim shortcuts in ST and ST shortcut in Vim are not good signs either and the part where you complain about having to adjust to your Mac's Cmd is the icing on the cake, IMO.
It may sound brutal but, from your question, it seems like you are doing too much at the same time, without organization and for, probably, no good reasons.
Switching from Windows to Mac OS X and switching from ST2 to Vim at the same time is sure to be confusing and I suggest you slow down a little and make a choice before you loose your mind and waste more of your time.
Which leads me to this: Why do you use a Mac and why are you using Vim?
Windows is a fine OS. Sublime is a fine editor. Even if you switch to the Mac, Sublime works very well there. So Why Vim?
If you are tired by some Sublime limitations and want the awesome power of Vim, fine. But you must wrap your head around its modality and awkwardness and accept to change your habit.
If you don't approach Vim with more flexibility, you'll never get full benefits.
If you decided to use Vim because it is trendy, I'll respectfully suggest you to stop there and go back to Sublime. Vim is weird, Vim is different, Vim is huge, Vim is a rabbit hole… if you are not ready to work with it and insist on not accepting its core design, you won't get far so why bother? You can pretty much live all your professional carreer without ever touching Vim. There's no shame in that.
Remapping / to <C-f>, on the other hand…
I've used vi for decades, and am now practicing using vim, expecting
eventually to switch to it entirely.
I have a number of questions, but I'll start with the one that
troubles me most. Something I have long done in vi is to type
a bottom-line command into the file I am editing, yank it to a named buffer
(e.g., using the keystrokes "ayy) and execute that buffer (using
:#a^M). This allows me to edit complicated commands till they
work right, and to keep commands that I will use many times as I
work in a file. (I have
in my .exrc file a mapping that reduces this yank-and-execute to a
single keystroke; but that isn't relevant to my question.)
I find that in vim, I need a lot more ^Vs than in vi. This
means, on the one hand, that when I have some command-line in a file
that I expect to use this way, I now need to keep it in two
versions, one for vi and one for vim. Also, the requirement of the
extra ^Vs seems inelegant: evidently various special characters
that are interpreted once when the named buffer is executed in vi
are interpreted twice when its is executed in vim -- but why?
As an example, a command of the form
map =f :w^V|e foo^M
(mapping the keystroke-sequence =f to write the current file
and go to the file foo) works this way in vi, but has to have the form
map =f :w^V^V|e foo^V^M
in vim. (Here in both commands, ^V is gotten by typing ^V^V,
and ^M is gotten by typing ^V^M; so typing the first version
involves typing three ^Vs, and the second, seven.) To be
exact: the first version does work in vim if one actually
types it into the bottom line (with the indicated extra ^Vs);
but the latter is required in an executed named buffer.
Any explanation? Anything I can set to fix this? ("compatible"
doesn't seem to do it.) Any hope that it will be fixed in a future
release? (The system I am on uses version 7.0.)
(I should confess that I'm not a programmer; just a user who has
become proficient in vi.)
Personally, I'd stop using ^V completely. In Vim (I've no idea about Vi), there are various key notations that get round the problems you're having. For your specific example, I'd recommend:
map =f :w<bar>e foo<CR>
where <bar> means 'insert the vertical bar here' and <CR> means 'insert a carriage return here'. See:
:help key-notation
for more information. I find the <CR> much easier to understand than ^V^M.
That's an interesting way of using :#, which I hadn't thought of before. I generally just use the command line history when I need to edit complicated commands, and I tend to save common or complicated commands as mappings or commands in my .vimrc (of course, I have a mapping that will pop open my .vimrc in a new tab). But there are certainly benefits to using vim's normal mode rather than command line mode for editing a complicated command.
As I understand it, you not only want to avoid so many <C-V> characters, you would also like to be able to use the same commands in vim and vi. Unfortunately, that would preclude you from using the (preferred in vim) key-notation. I think that you should be able to use the cmdline mode's Ctrl-R Ctrl-R register to help you out (:help c_<C-R>_<C-R>). E.g.
map <Leader>e mm^"ay$`m:<C-R><C-R>a<CR>
mm - mark cursor location so we can return later
^"ay$ - yank current line into register a (ignoring whitespace at beginning and newline at end)
``m` - return cursor to start position
: - enter command line mode
<C-R><C-R>a - place the literal contents of register a onto the command line, which seems to be where your problem with vim versus vi was coming to into play. I think that <C-R>a would give you the same behaviour you are seeing now with :#a.
- execute the whole thing
Using that mapping, I then typed your example of map =f :w^V|e foo^M into a file, placed my cursor on that line, ran my <Leader>e mapping, verified that your =f mapping had loaded correctly, and then ran it. Obviously you'll want to customize it to fit your needs, but I think that playing around with <C-R><C-R> will basically get you what you want.
All of that said, if you can, I'd strongly recommend taking the plunge and forgetting about compatibility with vi. Then you can use the much simpler key-notation and a host of other vim features. :-)