dirbuf.enter(): Buffer is not 'modifiable' error

[lalitmee]

First of all, I would like to say thanks for this awesome and innovative directory explorer. The idea of editing like a buffer is the first and last thing which is attracting me to install this plugin. I just don't care that I have nvim-tree.lua too.

But I am not able to use this plugin heavily in my workflow because of some weird errors which shows up in my flow. Among all of them I decided to tell you about this one because not sure whats happening.

:bug: Issue

When I click <CR> on a directory it simply throws this error.

:+1: Expected

Not to throw this error.

nvim --version

❯ nvim --version
Alias tip: vi --version
NVIM v0.7.0-dev+1287-g315858bf6
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by lalitmee@pop-os

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

Run :checkhealth for more info

Help

Please let me know if there is something wrong with my config or is there some issue with dirbuf.nvim

Edit

I noticed that this error is coming when I have lir.nvim installed.

[elihunter173]

Hi! Thank you for the bug report. I'm glad you like the plugin and I'm sorry you're facing these issues.

I've managed to reproduce the issue and I'm looking into the cause. I suspect it's lir.nvim's BufEnter autocmd but I'm not sure yet. I'll keep you posted.

I also notice from your screenshot and my testing that for some reason syntax highlighting on directories, symlinks, etc. is not working in your config, so I'm investigating that as well

[elihunter173]

I've fixed the syntax highlighting issue locally. Will do one push once I fix the actually important issue at hand :sweat_smile:

Dirbuf previously would look at just at g:terminal_color_xxx for the colors (which cobalt2.nvim doesn't define) and give up on highlighting if they weren't there. Now I define a series of fallbacks to ensure that there is always some highlighting

[elihunter173]

Okay miraculously I believe this was a one-line fix. @lalitmee please try out branch issue-27 and see if that fixes your issue. The syntax highlighting should also work now

[lalitmee]

@elihunter173, yup its working on branch issue-27.

EDIT: sometimes I noticed that my buffer highlight is gone. You were mentioning something about cobalt2.nvim doesn't define something. Can you tell me what is that? I can make the changes there.

[elihunter173]

Hmmm. Buffer highlighting used to not work because the colors g:terminal_color_0, g:terminal_color_1, etc. weren't defined in cobalt2.nvim (see "Terminal Colors" under :help terminal-config). But the buffer highlighting issue should be fixed on the issue-27 branch even tho those colors aren't defined because of the fallback colors I added

[lalitmee]

@elihunter173, I think it may be due to my use of filetype.lua and not filetype.vim. I am not using vim filetype detection. Do you think so?

One more thing I noticed that, if I am using both lir.nvim and dirbuf.nvim and lets say I have mapping for lir to open key. If I press this key dirbuf opens. I am not sure if both can be used side by side.

[elihunter173]

I think it may be due to my use of filetype.lua and not filetype.vim. I am not using vim filetype detection. Do you think so?

I don't think so? Run :set filetype and see if filetype=dirbuf. At the very least, using the most up-to-date version of your dotfiles I can't reproduce the buffer highlighting issue. If you could provide a series of steps to get the buffer highlighting to be gone, I'll see if I can reproduce it.

One more thing I noticed that, if I am using both lir.nvim and dirbuf.nvim and lets say I have mapping for lir to open key. If I press this key dirbuf opens. I am not sure if both can be used side by side.

I think this issue occurs because both lir.nvim and dirbuf.nvim using BufEnter autocmds to open directories whenever you :edit a directory. You can disable dirbuf.nvim's autocmd which makes it so it doesn't open directories with :edit. This should prevent the issue you're seeing and makes it so you always have to directly open dirbuf.nvim.

autocmd VimEnter * autocmd! dirbuf

You should be able to do something similiar to lir.nvim's autocmd, but I think that breaks lir.nvim whereas dirbuf.nvim can function without its autocmds.

Side note: This is a common enough setting that I'll probably add a configuration option to disable auto-opening directories.

[elihunter173]

@lalitmee Please test the following config on the issue-27 branch. I've just done additional testing and I believe fixes all your issues, including the buffer is not 'modifiable' error, the syntax highlighting, and the issue of lir opening dirbuf.

The only change from your current config is that it re-enable dirbuf.nvim and runs the autocmd VimEnter * autocmd! dirbuf fix that I suggested earlier.

use {
  "elihunter173/dirbuf.nvim",
  branch = "issue-27",
  cmd = { "Dirbuf", "DirbufSync" },
  config = function()
    vim.cmd("autocmd VimEnter * autocmd! dirbuf")
  end,
  disable = false,
}

In the future I might add a configuration option called something like auto_open_directories which you can set to false rather than doing this autocmd hack, but I'm still thinking about the best way to do that.

So in the meantime, if this fixes your issue, then I will merge issue-27 as is.

[lalitmee]

@elihunter173, yeah it fixes my issues. Thanks for this fix and obviously the plugin.

I just wanted to ask one thing and that is, can we show folder icons before the folders or not? I was guessing that because dirbuf.nvim works differently so it may be difficult to add the folder icons.

What do you think?

[elihunter173]

Excellent! I'll merge the change shortly.

I just wanted to ask one thing and that is, can we show folder icons before the folders or not? I was guessing that because dirbuf.nvim works differently so it may be difficult to add the folder icons.

It should be possible to show icons theoretically but it would take a little bit of work. I've thought about it and I think using virtual text would be the way to go but I'm not sure.

I've been semi-planning on doing a face-lift to the way directory buffers look, so I'll look into this.

[elihunter173]

Merged to main as of b019f8ad86033381babd617e427f58bcfc5e5b9c and 982f6ab5106e9418bb8b32e5ba79a10487449bb6