filetype.nvim
filetype.nvim copied to clipboard
filetype.nvim breaks ftdetect
Nice plugin, thanks!
Given /usr/local/Cellar/neovim/<ver>/share/nvim/runtime/filetype.vim
is not fully loaded because of vim.g.did_load_filetypes = 1
it also does not load
" Use the filetype detect plugins. They may overrule any of the previously
" detected filetypes.
runtime! ftdetect/*.vim
runtime! ftdetect/*.lua
which is part of it. This breaks user's custom filetypes specs from ftdetect/
directory.
Do you think that
- your plugin could run those two commands
- provide configuration option (setup function?) to add custom mappings to extensions
Thanks!
Edit: since that only invokes autocmds specified in those files feel free to ignore that question/request as it's easy to just move those autocmds to some other sourced file.
I think adding support for user defined filetypes is a good idea. However, I won't include sourcing other ftdetect
files in the plugin since its purpose is to avoid creating autocommands.
Also there should be a way to override default mappings. What to you think?
Oh dang, yeah. Just realized this. I have a few custom ftdetect autocommands and I would love to replace them with additional configuration for this plugin. I moved them to a file that I know will be sourced for now.
@nathom Just checking out your dev branch. Looking good, thanks lot!
One problem I am seeing is my custom literal override:
require('filetype').setup {
overrides = {
literal = {
['something.log'] = 'somethinglog',
},
complex = {
['.*zsh/fpath/'] = 'zsh',
['.*ssh/config'] = 'sshconfig',
},
},
}
When I open something.log
file it gets log
filetype set.
This issue is one of the things that was stopping me from using the otherwise great plugin. I have one question regarding the fix, how does it help a plugin developer? If I install a plugin, and it has its own file type detection, do I have to manually enter the filetypes in to the new setup function call?
I personally just have this at the top of my init.lua
:
vim.g.did_load_filetypes = 1
vim.cmd([[ runtime! ftdetect/*.vim]])
vim.cmd([[runtime! ftdetect/*.lua]])
I know the point of the plugin is to avoid loading more than 1 filetype setting autocmd, but the vast majority is still in filetype.vim
. With this plugin, and the lines above, I still get the startup performance beneficts + external ftdetect
plugins (and my own ftdetect
) still work as expected.
I can't imagine legacy filetype plugin authors ever catering to filetype.nvim
honestly.
It seems that this is an ordering issue. The regexes always run after the extension and literal tables, so they will get overridden. Maybe I'll need to keep a separate overrides table that has precedence over the rest.
One problem I am seeing is my custom literal override:
require('filetype').setup { overrides = { literal = { ['something.log'] = 'somethinglog', }, complex = { ['.*zsh/fpath/'] = 'zsh', ['.*ssh/config'] = 'sshconfig', }, }, }
When I open
something.log
file it getslog
filetype set.
It seems to be fixed in main now. And since there is a way to provide overrides (no need for ftdetect, unless some other plugins/etc need it) I will close that issue as it's all working for me now.
Can you see any issues with not having those runtime!
on ftdetect files?
Reopening as per https://github.com/nathom/filetype.nvim/issues/41#issuecomment-963032730
While the current state is fine for personal ftdetect
settings, it doesn't help filetype plugins like https://github.com/lervag/vimtex that extend and/or correct Vim's default filetype.vim
detection logic. I strongly believe that not breaking these plugins is more important than avoiding two or three autocommands. (After all, the point of filetype.nvim
is not to avoid all autocommands, just the 800+ needless ones in `filetype.vim ;))
I strongly agree with @clason , this has broken the many filetype plugins that I use, and I think the general assumption would be that these would still work. I think a mention of this issue in the README in the meantime would also be useful.
Unfortunately it also break https://github.com/kassio/neoterm, because it relies on 'ftdetect' folder for its core logic.
PSA: filetype.lua
is now the default on Neovim master (and 0.8.0, when that is released). It has full parity with filetype.vim
(including scripts.vim
and setf FALLBACK
support), passing Vim's filetype detection test suite. It will be kept in sync with future filetype detection changes in Vim and should thus be a safe and non-breaking replacement.
That means this plugin is free to take a more opinionated approach without concern for backward compatibility, if desired. (Although it would be good to keep filetype.lua
enabled as a fallback, as this doesn't have the same performance penalty as filetype.vim
.)