feature request: filetype by actual filetype

[nobe4]

Did you check existing requests?

• [x] I have searched the existing issues

Describe the feature

Enable Oil to find the filetype by nvim's computed filetype. Not only the file extension.

Provide background

I use a lot of scripts in ./script/ for common functions (test, lint, serve, ...). They all are without extension, so when I change repo/OS I know that test will always run the test, regardless of the underlying system.

This works well enough, but oil.nvim seems to be only using the filename extension to determine the filetype.

(n)vim can also use other markers, like the shebang line. It would be awesome to integrate with vim.filetype.match's contents. For example:

For instance:

:lua c = vim.fn.readfile("./script/test")
:lua f = vim.filetype.match({ filename = "test", contents = c })   
:lua vim.print(f) -- => sh

I have tried to do such changes in https://github.com/nobe4/oil.nvim/commit/64bf6523f8b220ce00f96660e5f545f60797f597 But it's probably incomplete.

What is the significance of this feature?

nice to have

Additional details

If this sounds like a worthy idea, I'd love to have some pointers towards making this a reality!

[nobe4]

Edit, it seems that I misunderstood the function that I read earlier, the code that pulls the icon is actually: https://github.com/stevearc/oil.nvim/blob/302bbaceeafc690e6419e0c8296e804d60cb9446/lua/oil/util.lua#L928-L951

However, at no point does this seems to involve reading the file, and is relying on 3rd party instead.

[stevearc]

This isn't explicitly stated anywhere in the documentation, but one thing that is very important to me about oil is the performance (see https://github.com/stevearc/benchmark.nvim/tree/master/examples/file_explorers). I work in large codebases that sometimes have enormous directories and I want the load time to be as close to instant as possible. Reading the entire contents of each file in a directory before displaying it can potentially slow that down a lot.

I would potentially be okay with adding some logic around this, but only if it's carefully written to preserve responsiveness. For example, only running when there are <N entries in the directory, and only reading the first few lines of the file instead of the entire contents.