Open up fetch API for external usage

[blueyed]

I've just remembered that I have the following in my vimrc:

au BufNewFile * nested let s:fn = expand('<afile>') |
\ if ! filereadable(s:fn) | let s:fn = substitute(s:fn, '^\S\{-}/', '', '')
    \ | if filereadable(s:fn) | echomsg 'Editing' s:fn 'instead' | exec 'e '.s:fn.' | bd#' | endif | endif

This helps when copy'n'pasting a path from a patch / diff header, e.g. from git diff.

I think it might be a good addition for vim-fetch, applying all specs with an optional path prefix, too.

It could be limited to just a single char prefix (a/, b/, i/, w/, ...).

[kopischke]

I’m wondering if that is not best handled by gF, but I may be missing something. I get what the snippet does (the same thing as vim-fetch, but with less jumping through hoops), but I’m not sure I grasp the usage case. Could you explain what you want to achieve in some more detail?

[blueyed]

Yes, it's also a case for gf/gF, but those do not work when opening Vim.

My use case is using git or some other tool in the terminal, then copying some path from a patch output and starting Vim with it. This usually means to start Vim using vi a/path/fo/file, where the file is ./path/to/file.

[kopischke]

OK, never mind the gF part, I got thrown by your mention of vimdiff; could you give me some samples of patch / diff tools which do this, as well as of their respective output format? That syntax is not standard patch format (either normal, context or unified) as far as I can see, so I’m still very hazy on the usage specifics.

EDIT: I only just noticed you mentioned git (sorry, early morning here); are we talking about git diff output? I’m not trying to be deliberately obtuse, I’d just like vim-fetch’s functionality to be as narrowly and specifically defined as possible.

[blueyed]

are we talking about git diff output?

Yes.

Another example are patches in Debian packages, which (at least used to be) commonly applied using patch -p1 to strip the first prefix.

[kopischke]

Correct me if I’m wrong, but none of these actually include position information, right? This is about guessing the correct file path only from a contextually truncated format?

[blueyed]

Yes.

[kopischke]

Thought so. I’m not sure that is a good fit for vim-fetch – I think I’d rather have it remain focused on jump specs. However, I have a few ideas about how to make vim-fetch’s heuristics available outside the plug-in’s scope. For instance, instead of passing the key to a hardwired matcher, one could make its API accept arbitrary handlers, so you could do something like

let handler = {'pattern': '\m^[^~\./]/'}
function! handler.parse(file) abort
  return [substitute(a:file, self.pattern, '', ''), [0, 0]]
endfunction
" define autocmd group...
autocmd BufNewFile,BufWinEnter [^~./]/?* call fetch#buffer(handler)

in your .vimrc (fetch#buffer() is the new API as of the upcoming release 2.0). That would leverage vim-fetch’s buffer detection heuristics and switching abilities. What do you think?

[blueyed]

I’m not sure that is a good fit for vim-fetch – I think I’d rather have it remain focused on jump specs.

Ok.

autocmd BufNewFile,BufWinEnter [^~./]/?* call fetch#buffer(handler)

That looks good!