feature request: Support Plain Directory Paths in Buffer Names

[ro0gr]

Did you check existing requests?

• [x] I have searched the existing issues

Describe the feature

I’d like to propose the ability to open an oil.nvim window using the plain directory path as the buffer name, rather than prefixing it with the custom oil:// protocol. This could improve compatibility with other plugins and workflows that expect standard file paths.

Would this be a reasonable addition to the plugin?

Provide background

The current implementation of oil.nvim creates some friction when integrating with other plugins. For example:

• There is an open issue in project.nvim that highlights compatibility challenges.
• The Snacks picker fails to open files in the oil.nvim window. Instead, it defaults to selecting any other file-like window (e.g., a sibling window). While I haven’t confirmed whether this is directly caused by the custom oil:// file protocol, the same workflow works seamlessly with Snacks + Nerdtree, which suggests the protocol may be the root cause.

What is the significance of this feature?

strongly desired

Additional details

During some experimentation, I attempted to replace the oil:// prefix with an empty string in the default adapter settings. As expected, this didn’t work as intended, since the protocol is assumed in many places throughout the codebase. Refactoring this would require significant effort and careful consideration.

Before diving deeper, I’d like to clarify: Is there an unavoidable technical reason for requiring the oil:// protocol prefix?.

My current understanding is that it’s primarily used to properly restore Oil buffers when sessions are loaded without Oil being set as the default_file_explorer. If this is the only reason, could we explore alternative approaches to handle this case?

For example:

• Allow an empty file protocol only when default_file_explorer is set to true.
• Skip restoring Oil buffers if Oil isn’t the default file explorer and the protocol is set to empty.
• Investigate other ways to identify Oil buffers without relying on the protocol prefix, such as maintaining a buffer variable stored in the session (though I’m unsure if this is currently feasible).

Are there other implications or use cases I might be missing? I’d appreciate your thoughts on this!

[ro0gr]

I just came across another example where the oil:// protocol might introduce unnecessary integration complexity. In lualine.nvim, there’s a specific check to handle the oil:// prefix for Git branch detection. While this works, it raises the question: Could we simplify or eliminate the need for such custom integrations in external plugins?