Exploit smartness of `gf` about vimfiles HOT 4 CLOSED

Also, gf benefits from &suffixesadd, &includeexpr and &path when searching for the file name under the cursor.

from vimfiles.

That's an interesting idea. Ideally, there would be an easy way to make a list of all matching filenames taken from the tags file and implied by the gf algorithm. Unfortunately, after looking around through the Vim sources I don't see an easy way to get at Vim's internal functionality for enumerating the filenames implied by gf. In my workflow, if the tags file contains a match, that's what I prefer to take precedence. Also, as-written the current mapping for gf uses :tag instead of :tjump, so you're correct that only the first matching file in tags can be used. I suspect this mapping was made before I knew about the benefits of :tjump, so changing the mapping to use :tjump would certainly be an improvement. I also don't prefer the count-based interface that stock gf provides; if there are multiple matches, I'd rather see them show up in a list like :tjump provides (which is why <c-]> is mapped to g<c-]>). Do you have any ideas for gathering up the list of matching filenames for the stock gf behavior such that they could be merged with the results from the tags file (perhaps via a plugin or else some additional custom Vimscript)? Something like that would be my preference for improving the behavior of the mapping. I'm unfortunately not in a position to spend much additional time working on a more capable solution myself, but perhaps you have enough interest to pursue it.

from vimfiles.

Do you have any ideas for gathering up the list of matching filenames for the stock gf behavior such that they could be merged with the results from the tags file

I gave up on this idea, but for example something like

    for l:suffix in  reverse(split(&l:suffixesadd, ',')) + ['']
      globpath(&path, expand('<cfile:t:r>' . l:suffix)
   endfor 

would search in &pathfor the filename and the filename extended by all possible suffixes.

However, as :h gf shows

			Uses the 'path' option as a list of directory names to
			look for the file.  See the 'path' option for details
			about relative directories and wildcards.
			Uses the 'suffixesadd' option to check for file names
			with a suffix added.
			If the file can't be found, 'includeexpr' is used to
			modify the name and another attempt is done.

the story goes on, and &includeexpr would have be implemented manually.

In my workflow, if the tags file contains a match, that's what I prefer to take precedence.

Say that the filename is name.ext and it is referred to by name as .ext is implied. As a user, you expect gf to jump to the file, but if taglist('name') is nonempty, it would jump to any tag name which will be something different than name.ext.

Well, I liked the idea of using tags as a fallback to gf, but to me it seems that the fallback will only work as expected by calling gf first. Also, calling taglist() and then tjump is doubling the effort, but that's only a futile perfectionist's observation.

from vimfiles.

I've never really used the fancier features of the built-in gf command. You make a good point about having name under the cursor and expecting gf to find name.ext with an implied suffix. If gf doesn't find desired file, perhaps it's worth trying to tune the various gf-related settings to make it work better, rather than always relying on up-to-date tags files. Also, I realized that the filename can be visually highlighted and followed as a tag by pressing Ctrl-], which provides a way to prioritize tags over the built-in gf functionality. I think it's worth trying out this approach to see if there are any issues, but it seems like it might be strictly better than what I had before. Thanks for your contribution :-)

from vimfiles.