feature request: prefer creation of files over directories with :e in oil buffer

[mjlbach]

Did you check existing requests?

• I have searched the existing issues

Describe the feature

I regularly use netrw with vinegar style bindings (- to go up). My default workflow for creating a new file in a given project is to open netrw, navigate to the directory I want, and :e %:p:h -> tab -> new filename.

Unfortunately, by default oil will open with a url of the form:
:e oil:///Users/michael/Repositories/fluffychat/macos

This means that if I append test.file I get
:e oil:///Users/michael/Repositories/fluffychat/macos/test.file

Which opens me in a new oil buffer, rather than a text buffer (accidentally wrote 20 new files instead of a 20 line file this way).

I'm not sure how to handle this (or I would have filed a PR), since there is not a good way to disambiguate between new file/folder by path alone, but I guess my expectation as a user with :e would be that the final path element would correspond to a new file.

Provide background

No response

Additional details

Love the plugin! If I was still a neovim dev I would tell you to upstream it and tear out netrw :)

[stevearc]

Hey, good to see you back in the vimscape!

I have two ideas for this. The first is pretty minimal: you could use a cabbr to replace % with the filepath.

vim.cmd.cabbr({ args = { "<expr>", "%", "&filetype == 'oil' ? bufname('%')[6:] : '%'" } })

It's not a drop-in replacement for your workflow, but you would at least be able to keep some of the same muscle memory.

The second idea is drafted in this PR: #78
The basic idea is to detect when a path like oil://path/to/file.txt is a normal file, and if so, open it as a normal buffer instead of an oil buffer. It's using vim.filetype.match() on the filename to detect if it's a normal file or not. It's a bit more involved, but should hopefully Just Work.

[mjlbach]

Hey, good to see you back in the vimscape!

Just visiting :)

I can definitely work around it. I just wanted to bring it to your attention :) I think #78 is an elegant solution, but totally your call if you don't want to add the complexity!

[stevearc]

Happy to merge #78! I'll just have to wrangle the CI tests into passing :/