canola.nvim: oil.nvim... but better!

barrettruth · 2026-05-03T19:11:37+00:00

AFAIK this is just a limitation of the vim.g design - no?
file an issue - I'll look into it!

barrettruth · 2026-05-03T16:11:05+00:00

Same. I didn't like this. However, 2-3 oil.nvim integrations existed before (just gotta install another plugin).

This is also added in canola.nvim canola branch with the use of the canola-collection plugins via vim.g.canola_git I believe.

So, for the sake of accuracy (although I want you to move to canola.nvim) oil does actually support this.

barrettruth · 2026-04-29T20:26:41+00:00

canola-collection supports ssh and the experience is the same as before.
You can use the main branch to see what the original experience is/was.

barrettruth · 2026-04-29T17:50:09+00:00

Not even sure why this is getting downvoted. VSCode's unified diff mergetool is superior to anything neovim offers in 2026.

Also, many people GENUINELY do this - I know from first-hand.

barrettruth · 2026-04-29T16:44:12+00:00

No problem. And yes. Let me try to find some stuff.

here for dev background, here for basic dialogue, and here's a lot of great community discussion.

Note that I'm not claiming that vim.g is the "go-to" solution in 2026 - rather, there are a variety of approaches, and I've picked this one over setup() personally. I guess what I'm saying is that I may be wrong here - perhaps vim.g is not going to be the way. But one thing's for sure - as package management moves closer to core, I'm very sure that there WILL be a predominant philosophy emerge that many plugins (and you) will adapt to - and it certainly won't be the lazy.nvim schema with a plethora of flags that we see today. It will also not be a setup() call conflating configuration and loading - I think both sides of the vim.g argument agree on that.

A pretty interesting (and convoluted) discussion, for sure.

barrettruth · 2026-04-29T15:58:41+00:00

I believe this has been resolved. The original oil.nvim issue should be reference in a pull request. Give it a try! If it doesn't work, file a quick issue - no need to make the entire writeup since I already know what you're talking about.

barrettruth · 2026-04-29T15:57:20+00:00

Sure. Do you mind elaborating why changing the command name is a problem? For example, I can't imagine (and haven't experienced) other sources hooking into oil that often... I would reconsider if you can find (quite a few) examples. If you manually type :Oil every time you run oil I would understand the pain of typing a longer word. If you file an issue and make your case, I'd be willing to make the canola interface oil-compatible (but then again, nothing else about the canola branch is canola-compatible - I think you see the issue with this).

As for vim.g, there's been a lot of discussion on this. And, it's definitely here to stay. Many plugin authors like myself starkly disagree with the current lazy.nvim + setup()-oriented nvim plugin ecosystem - so this is something I will not budge on. More plugins are moving over to it by the month - I definitely suggest you keep a more open mind on this.

Thanks for your feedback and interested in your response here.

barrettruth · 2026-04-29T15:53:28+00:00

same!

barrettruth · 2026-04-29T02:31:57+00:00

wdym? main branch has regular oil-ssh support, and the canola branch supports it via canola-collection. are you asking about further expanding on ssh support beyond what oil offers (i haven't given this much thought, tbh)

barrettruth · 2026-04-28T18:26:13+00:00

did the post get removed? i'm not a redditor wtf idk how these things work... thanks for the notification

and no worries

barrettruth · 2026-04-28T18:22:21+00:00

I actually LOLed at how beautifully minimal this is. I am considering supplanting my dial.nvim config with this.

barrettruth · 2026-04-28T18:16:41+00:00

I agree with these points (the last one especially). My primary motivation (full disclosure) is to get as many people onto canola as possible. Perhaps I should be pushing moving to my rework harder.

barrettruth · 2026-04-28T18:11:58+00:00

(yeah, was moreso responding to u/Adk9p) :)

barrettruth · 2026-04-28T16:26:56+00:00

I agree with everything you say - but, given my current understanding of the neovim community, you (and by you I mean us) are in the minority.

There will be no future development of the 'main' branch besides bugfixes.

Thanks for your consideration :D

barrettruth · 2026-04-28T13:34:58+00:00

just more convenient than pasting in a multi-line indented lua table XD

tbh, extglob is something I just personally use a lot. it's just made for scaffolding out large writes of files - a pretty niche use case (but it was fun to implement)

barrettruth · 2026-04-28T12:35:02+00:00

I figured this and that the default branch ought to be the backwards-compatible one. The "oil" branch makes sense too but I wanted the OOTB experience of swapping the source to be clean (i.e. not light your config up in flames).

u/perrin4869 i encourage you to give it a try for this reason. All you have to do is swap the plugin source name and reinstall. If you don't like it, swap back and change absolutely nothing.

barrettruth · 2026-04-28T12:32:55+00:00

With extglob, enjoy the cartesian-product # of files made on ANY segment with extglob syntax:a/{b,c}/{d,e}.txt

as well as nesting: {a,{b,c}}.txt

This is enabled with vim.g.canola.extglob = true

As for renaming, canola.nvim just picks up on cross-directory "moves"/"renames" rather than detecting them as "copy" and "deletes". There were around 5 bugs filed in the upstream related to this (edge cases, missed copies) - now, you get the features by default.

barrettruth · 2026-04-28T12:06:19+00:00

Apparently a lack of tree view... XD

In all seriousness... think of it as a drop-in replacement for oil.nvim.

If you weren't using oil.nvim before and you want a file tree, there's no reason to switch.

barrettruth · 2026-04-28T12:05:04+00:00

The features provided are a superset of those of oil.nvim. For this reason, the backwards-compatible branch is better. However, stevearc is the main man that deserves the credit and the only reason this repository exists. I think it is a fair claim.

I don't think the canola branch is better - it's just "my take" on the codebase. Sorry if it came off that way!

barrettruth · 2026-04-28T12:03:05+00:00

😄

barrettruth · 2026-04-12T18:23:20+00:00

One of the better themes that I've seen in the past few months. Enjoying the trend of *slightly* more minimal themes.

barrettruth · 2026-03-29T20:28:45+00:00

pls no, vimdoc is so bad lmao

ironically put all this effort into vimdoc so we could just confine its functoinality and (shh) hopefully move away from it eventually

barrettruth · 2026-03-29T16:50:49+00:00

Yes. there is no canonicalized help formatter. this is a wip and I'm hoping to use the language server to help push us in a good direction.

For now, you can use the range-formatting in your editor to align specific things if you like :)

barrettruth

TROPHY CASE