Call original gf after remapping gf to custom function

Question

gf doesn't work for absolute links used in Azure DevOps yaml files, p.e.

  - template: /devops/template/my-template.yml

(It only works without the leading slash.)

This is why I have created my custom function that tries first a gf and then tries guessing the file that is meant:

function! GoToFile()
    try
        normal gf
    catch
        let path = expand("<cfile>")
        if path[0] == '/'
            ...
        endif
    endtry
endfunction

I have mapped it to gF:

nnoremap gF :call GoToFile()<CR>

This is just a workaround. Actually, I would like to map it directly to gf:

nnoremap gf :call GoToFile()<CR>

But then strange things happen (after using gf):

• No syntax highlighting for the opened file.
• Other open buffers disappear from my "buffer tabs" (no real tabs, I use ap/vim-buftabline)
• The file name in the remaining "buffer tab" looks different now (d/t/template.yml instead of just template.yml)

Is something wrong with this approach? Do I end up in a loop? Shouldn't nnoremap prevent this? Is there a way to call the "original" gf (like \ls in bash to ignore aliases)?

Answer 1

Try to use normal! gf with exclamation mark in your function.

With normal gf (without exclamation mark) you most probably are calling the same function over and over again until vim breaks it.

See :h :normal

            If the [!] is given, mappings will not be used.
            Without it, when this command is called from a
            non-remappable mapping (|:noremap|), the argument can
            be mapped anyway.

Answer 2

Is something wrong with this approach?

Yes.

When you do gf and Vim doesn't find the target file, it tries to use :help 'includeexpr', if it is set, as a last resort. It is expected to be an expression that transforms the given "path-like" string into an actual usable path.

In this case, it would look something like this:

" in after/ftplugin/yaml.vim
setlocal includeexpr=substitute(v:fname, '^\/', '', '')

which would let you use the native gf and gF and make this problem moot.

Now, includeexpr is supposed to return a valid path but it doesn't prescribe a way to do so. There are, actually, many situations where a substantial amount of work is required in order to obtain a valid path and that work can all be encapsulated in a function:

" in after/ftplugin/yaml.vim
function HandleAzurePaths(fname)
    " your code here
endfunction
setlocal includeexpr=HandleAzurePaths(v:fname)

If your logic in lines 677-694 works, you should be able to fit it there and make it return x… without having to deal with "real" gf and "fake" gf.

FWIW, I use such a function for JavaScript, where I reimplemented Node's module resolution algorithm in about 100 lines so don't feel constrained, here.