One option would be the other gf
commands: <C-w>f
opens in a new split and <C-w>gf
in a new tab.
You could try to :set switchbuf=useopen
and see if that helps.
Lastly, you could use an ftplugin to map gf
to :drop
as follows:
" ~/.vim/after/ftplugin/python.vim
nnoremap <buffer> gf :execute 'drop' expand('<cfile>')<CR>
(If you go for this route, you may want to adjust b:undo_ftplugin
as well.)
This last solution does suffer from the fact that :drop
does not open in a new tab if the buffer doesn't exist (it uses the current window). You could fix this with
nnoremap <buffer> gf :execute (bufloaded(expand('<cfile>')) ? 'drop' : 'tabedit') expand('<cfile>')<CR>
There are further caveats to either mapping solution:
expand('<cfile>')
should be an exact replica of the filename-resolution system used by gf
, which is far more intelligent than just "word under cursor" (it involves using include
/includeexpr
and suffixesadd
, at the least). If expand('<cfile>')
isn't working, you can try .'.py'
or .&l:suffixesadd
as a workaround.
- I made the mappings buffer-local since I put them in an ftplugin. In general I recommend not overriding vim’s builtins unless it’s strictly a superset of the behavior, but YMMV.
- If you consider tab pages to be more like window layouts, it may be more advantageous to envision a workflow where you are ok with having the same file open in multiple windows across multiple tab pages. I may have a tab for the main entry points of a project, a tab for each of successive stages of a processing pipeline, etc. Each of those tabs may have different or the same files; sometimes, I have the same file in multiple windows just for different views! This depends on the complexity of the project though, as for many projects I don't need more than 2 or 3 windows and am often only in 1 or 2.