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!

[kopischke]

I’m on the fence about this; with the extension of their capabilities to gF in release 2.0, vim-fetch’s specs have gotten more intricate, if anything. As things stand, opening up the API for arbitrary specs looks like an excellent way to shoot yourself in the foot. Maybe I’m being paranoid, but I’d rather not have users figuratively bleeding from holes in their appendages yelling and cursing at me in the Issues…

@blueyed your input would be appreciated :).

[kopischke]

Another possible way would be to modularise the internals of fetch#buffer() and API-fy the modules, allowing for something like (function names tentative):

function! s:checkdiffpath() abort
  if !filereadable(bufname('%')) && !fetch#buffer#ignored(bufnr('%'))
    call fetch#buffer#instead(substitute(s:fn, '\m^\S\{-}/', '', ''))
  endif
endfunction
autocmd BufNewFile,BufWinEnter [^~./]/?* call s:checkdiffpath()

• Pro: no need to expose the rather tricky spec handling to users
• Con: this is only needed for external usage – no function but fetch#buffer() needs this internally

And then there is the option of creating another plug-in entirely, one only tasked with resolving false file paths, with user configurable resolution patterns (a superset of DidYouMean, if you want).

• Pro: no vim-fetch specific overhead (like the extended gF functionality), none of the Cons above
• Con: someone needs to write it :)

@blueyed thoughts?

[kopischke]

I’ve removed this from the 2.0 release milestone, but will leave the issue open for discussion for the time being.

[kopischke]

Closing, but kept in mind for future consideration.