Search and replace on filenames with space #333

Open
opened 2026-04-29 13:43:29 +00:00 by rafamadriz · 4 comments
rafamadriz commented 2026-04-29 13:43:29 +00:00

This was something that didn't work in the original oil.nvim because files get all mangled, take a look at this issue to see what I mean: https://github.com/stevearc/oil.nvim/issues/388

I use oil.nvim as a general file manager, where I do mass renaming of files and son on. So it's annoying that I can't replace spaces in filenames with any other character like: - or _.

While taking a look at this fork, I noticed this in the README:

  • Inline virtual text columns with eza-like highlighting (permissions, size, owner, timestamps)
  • Custom column API

And according to stevearc, the problem was:

Unfortunately this is not possible with the limitations that oil is working with. We have to have a unique ID column present in the buffer. Using extmarks could be an interesting approach, but for now there does not appear to be a way to yank and paste extmarks.

So I wonder if the issue above can be fixed.

This was something that didn't work in the original oil.nvim because files get all mangled, take a look at this issue to see what I mean: https://github.com/stevearc/oil.nvim/issues/388 I use oil.nvim as a general file manager, where I do mass renaming of files and son on. So it's annoying that I can't replace spaces in filenames with any other character like: `-` or `_`. While taking a look at this fork, I noticed this in the README: - Inline virtual text columns with [eza](https://github.com/eza-community/eza)-like highlighting (permissions, size, owner, timestamps) - Custom column API And according to stevearc, the [problem was](https://github.com/stevearc/oil.nvim/issues/388#issuecomment-2187924855): > Unfortunately this is not possible with the limitations that oil is working with. We have to have a unique ID column present in the buffer. Using extmarks could be an interesting approach, but for now there does not appear to be a way to yank and paste extmarks. So I wonder if the issue above can be fixed.
barrettruth commented 2026-04-29 15:40:12 +00:00

Thank you for the well-formatted issue with appropriate context.

I'm supposing that you're on the canola branch - all following discussion assumes so.

Unfortunately, despite major architectural changes, I never actually decided to mess with the fundamental way that oil.nvim stores files in the buffer (i.e. the /<id><space> prefix). This was simply because I was too scared (lol).

I will be investigating and seeing if this is something that I can change, perhaps in light of my discovery of how vim-dirvish stores paths.

I am sorry that this was not resolved as (sort of) advertised :/ - this was marked as out-of-scope in the upstream tracker. I'll give it another shot. Note that storing filepaths in buffers like this comes with some fundamentally intractable problems - so, it's not that it solving this is impossible - it's that every solution has a tradeoff no matter what.

Thanks for your consideration.

Thank you for the well-formatted issue with appropriate context. I'm supposing that you're on the canola branch - all following discussion assumes so. Unfortunately, despite major architectural changes, I never actually decided to mess with the fundamental way that oil.nvim stores files in the buffer (i.e. the `/<id><space>` prefix). This was simply because I was too scared (lol). I will be investigating and seeing if this is something that I can change, perhaps in light of my discovery of how [vim-dirvish](https://github.com/justinmk/vim-dirvish) stores paths. I am sorry that this was not resolved as (sort of) advertised :/ - this was marked as out-of-scope in the upstream tracker. I'll give it another shot. Note that storing filepaths in buffers like this comes with some **fundamentally intractable problems** - so, it's not that it solving this is impossible - it's that every solution has a tradeoff no matter what. Thanks for your consideration.
barrettruth commented 2026-04-29 16:07:49 +00:00

I found a prospective solution. Unfortunately, it's literally an entire massive codebase refactor.

I need to finish my finals :/ so I will tackle this in a week.

Sorry for the hypocrisy here as advertised - I'll get on it as soon as I can,

I found a prospective solution. Unfortunately, it's literally an entire massive codebase refactor. I need to finish my finals :/ so I will tackle this in a week. Sorry for the hypocrisy here as advertised - I'll get on it as soon as I can,
rafamadriz commented 2026-04-29 20:03:22 +00:00

@barrettruth You don't need to apologize for anything. I was asking out of curiosity, not with the expectation of this being "solved". Keep up with the great work, and good luck in your finals!

@barrettruth You don't need to apologize for anything. I was asking out of curiosity, not with the expectation of this being "solved". Keep up with the great work, and good luck in your finals!
barrettruth commented 2026-04-29 20:25:35 +00:00

No but - it is something that I want to do XD. No worries - I'll @ you in the thread with a branch with the MVP implementation when done. Thanks for using canola

No but - it is something that I want to do XD. No worries - I'll @ you in the thread with a branch with the MVP implementation when done. Thanks for using canola
Sign in to join this conversation.
No description provided.