Skip to content
This repository has been archived by the owner on May 6, 2024. It is now read-only.

filetype.nvim breaks ftdetect #9

Open
gegoune opened this issue Sep 27, 2021 · 13 comments
Open

filetype.nvim breaks ftdetect #9

gegoune opened this issue Sep 27, 2021 · 13 comments

Comments

@gegoune
Copy link
Contributor

gegoune commented Sep 27, 2021

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

  1. your plugin could run those two commands
  2. 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.

@nathom
Copy link
Owner

nathom commented Sep 27, 2021

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.

@gegoune
Copy link
Contributor Author

gegoune commented Sep 30, 2021

Also there should be a way to override default mappings. What to you think?

@qbedard
Copy link

qbedard commented Oct 3, 2021

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.

@gegoune
Copy link
Contributor Author

gegoune commented Oct 3, 2021

@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.

@Furkanzmc
Copy link

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?

@ruifm
Copy link
Contributor

ruifm commented Oct 4, 2021

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.

@nathom
Copy link
Owner

nathom commented Oct 4, 2021

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.

@gegoune
Copy link
Contributor Author

gegoune commented Oct 6, 2021

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.

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?

@gegoune
Copy link
Contributor Author

gegoune commented Nov 8, 2021

Reopening as per #41 (comment)

@gegoune gegoune reopened this Nov 8, 2021
@clason
Copy link

clason commented Nov 8, 2021

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 ;))

@jemag
Copy link

jemag commented Jan 31, 2022

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.

@ajukraine
Copy link
Contributor

Unfortunately it also break https://github.com/kassio/neoterm, because it relies on 'ftdetect' folder for its core logic.

@clason
Copy link

clason commented Jul 8, 2022

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.)

usommerl added a commit to usommerl/configuration-nvim that referenced this issue Oct 5, 2022
The plugin is no longer necessary in neovim 0.8
See: nathom/filetype.nvim#9 (comment)
gkanwar added a commit to gkanwar/.dotfiles that referenced this issue Jul 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants