Add Option to Override Filetypes

[l-zeuch]

Expected Behaviour

When entering NVim with a *.go.tmpl file, it is expected that the plugin changes the filetype to yagpdbcc, thus granting syntax highlighting.

Actual Behaviour

Instead, the filetype remains on gohtmltmpl, which seems to be set by (Neo)vim itself.

Steps to Reproduce

(Make sure the plugin is loaded already or loads on-demand)

$ nvim demo.go.tmpl

:set verbose ft?

See ft=gohtmltmpl instead of ft=yagpdbcc.

Additional Context

$ nvim --version
NVIM v0.6.1
Build type: Release
LuaJIT 2.0.5
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

I'm not entirely sure where to begin troubleshooting -- I suspect the double extension is throwing our code off.

Code of Conduct

• I agree to follow this project's Code of Conduct.

[l-zeuch]

Update: Apparently I have a competing plugin installed, which sets the filetype:

https://github.com/fatih/vim-go/blob/430bc227654abc3eb5e27a9052a857344ca08cdc/ftdetect/gofiletype.vim#L10

I'll investigate further with that plugin disabled.

[LRitzdorf]

I get a filetype of template, with no plugin interference.

Initial thoughts: our plugin bails out if any filetype has already been set. We could qualify that behavior to take over anyway if the extension is .go.tmpl (maybe dependent upon a variable that the user would set in their init.vim?)

[l-zeuch]

I get a filetype of template, with no plugin interference.

Okay, this tells us that we did something wrong with regards to the detection of filetypes. I suspect that the following code snippet does not work as we expect it to.

au! BufWrite,BufNewFile *.go.tmpl setfiletype yagpdbcc

As far as I aware, the issue lies within the double extension. vim-go circumvents this issue by triggering on just *.tmpl.
Perhaps it is worthwhile to do so as well?

Initial thoughts: our plugin bails out if any filetype has already been set. We could qualify that behavior to take over anyway if the extension is .go.tmpl (maybe dependent upon a variable that the user would set in their init.vim?)

I agree, such a configuration variable could be useful. However, there are a plethora of other plugins out there, and as far as I am aware, none of them do something similar. Thus I am currently kind of reluctant to implement such a configuration, simply because it seems to go against the general consensus.

[LRitzdorf]

Hm, interesting point about consensus there. I'm aware of other plugins (vim-airline, for example) that change their behavior based on variables. I do agree that using this to change whether we claim a specific filetype as our own is unorthodox, though.

Relatedly, what happens if we claim an extension that other plugins also claim? If they're loaded first, our plugin will bail out (as we've established), but what determines that loading order? We want to make sure we have reliable behavior, of course.

[l-zeuch]

Relatedly, what happens if we claim an extension that other plugins also claim? If they're loaded first, our plugin will bail out (as we've established), but what determines that loading order? We want to make sure we have reliable behavior, of course.

Honestly, not quite sure about that. My first guess would be the order they're added to the runtime path, with the last one taking precedence. I'd have to investigate.