Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"E37: Buffer would be deleted" from startify #221

Open
nickspoons opened this issue May 4, 2022 · 14 comments
Open

"E37: Buffer would be deleted" from startify #221

nickspoons opened this issue May 4, 2022 · 14 comments
Labels

Comments

@nickspoons
Copy link

The latest commit 7e41cd7 causes the E37: Buffer would be deleted error to be displayed when using - or :Dirvish from a vim-startify window.

Of course there is a simple workaround to open vim with vim . instead of just vim followed by -, but that won't help when opening startify manually from a vim session etc.

I'm not sure what the best solution is, whether some plugin/buffer types should be whitelisted, or whether the latest commit should have applied more specifically to git commits, or if a user-defined buffer variable should be introduced to bypass the error, e.g. au FileType startify let b:dirvish_allow_close = 1

@justinmk
Copy link
Owner

justinmk commented May 5, 2022

what does startify set 'bufhidden' to?

@justinmk justinmk changed the title Cannot enter dirvish from startify "E37: Buffer would be deleted" from startify May 5, 2022
@nickspoons
Copy link
Author

bufhidden=wipe

@justinmk
Copy link
Owner

justinmk commented May 5, 2022

I suppose [count]- could force it, so 1- would skip the warning.

@nickspoons
Copy link
Author

Ah ... I thought of a problem with this solution regarding startify specifically: startify by default presents a list of up to 10 recent files, and maps the numbers 0-9 to open those files. Meaning that 1- from startify still requires some custom mappings.

@nickspoons
Copy link
Author

nickspoons commented May 10, 2022

I'm going to resolve this in my config with this mapping:

nnoremap <silent> - :bwipe <Bar> Dirvish<CR>

I don't know whether it's something you want to follow up here, or whether it's more of a startify issue, or just an unusual edge case for users to work around. Feel free to close.

@justinmk
Copy link
Owner

Let's see how common this is. The condition added in 7e41cd7 was somewhat hopeful.

@blkwtkns
Copy link

blkwtkns commented Aug 1, 2022

I just updated my dirvish, it's been awhile, but I'm encountering this as well when trying to navigate files with "-" to move up a directory. Is there anymore info about this? I tried out what @nickspoons suggested but that's not working for me.

@justinmk
Copy link
Owner

justinmk commented Aug 3, 2022

but I'm encountering this as well when trying to navigate files with "-" to move up a directory.

which files...? It certainly shouldn't happen for normal files.

I tried out what @nickspoons suggested but that's not working for me.

Because the mapping there was buffer-local. I've updated the comment, try again.

@blkwtkns
Copy link

blkwtkns commented Aug 3, 2022

@justinmk I just tried the updated comment, unfortunately it's still happening. This is happening while navigating through JS files. If I'm in a file, when I press - it opens the directory explorer, but pressing that key again does nothing for me. And then if I press enter on a target file, I get the dirvish: E37: Buffer would be deleted error.

@justinmk
Copy link
Owner

justinmk commented Aug 3, 2022

@blkwtkns well, what does :verbose set bufhidden? report in these buffers? Sounds like you have a plugin or configuration issue, has nothing to do with dirvish.

If you actually want 'bufhidden' behavior for all of your buffers, just set 'hidden' ...

@blkwtkns
Copy link

blkwtkns commented Aug 3, 2022

So the output of :verbose set bufhidden? should be hidden?

@blkwtkns
Copy link

blkwtkns commented Aug 9, 2022

I figured some workaround in my configs, I had the following setup, and just commenting the bufhidden=wipe line out makes things work again...which seems strange based on what's been discussed here. But it works!

  aug DirvishGroup
    au!
    au FileType dirvish setlocal relativenumber
    " au FileType dirvish setlocal bufhidden=wipe
    au FileType dirvish nnoremap <buffer><silent> v   yy<c-w>p:vs <c-r>=fnameescape(getreg('"',1,1)[0])<cr><cr>
    au FileType dirvish nnoremap <buffer><silent> h   yy<c-w>p:sp <c-r>=fnameescape(getreg('"',1,1)[0])<cr><cr>
    au FileType dirvish nnoremap <buffer> Q <C-w>q
    au BufEnter * call NormalizeWidths()
  aug END
  " command! -nargs=? -complete=dir Vexplore leftabove vsplit | vertical resize 25 | silent Dirvish <args>
  " nnoremap - :Vexplore<CR>
  command! -nargs=? -complete=dir Vexplore leftabove vsplit | silent Dirvish <args>

With this, output for :verbose set bufhidden? is just bufhidden=

@justinmk
Copy link
Owner

justinmk commented Aug 13, 2022

So the output of :verbose set bufhidden? should be hidden?

No. :set hidden. In general 'bufhidden' shouldn't be set at all, that is the purpose of this warning.

au FileType dirvish setlocal bufhidden=wipe

Why do you want this? Dirvish depends on Vim to remember the cursor position for visited Dirvish buffers, and other state. Wiping the buffer will break those Dirvish features.

@mxngls
Copy link

mxngls commented Aug 16, 2024

Why do you want this? Dirvish depends on Vim to remember the cursor position for visited Dirvish buffers, and other state. Wiping the buffer will break those Dirvish features.

My rationale behind wiping the Buffer on BufLeave or BufWinLeave is, that I do not want Dirvish buffers to be part of my jumplist in order to prevent unnecessary buffers to appear (i.e. the Dirvish buffer) when switching between buffers with <C-O> or <C-I>.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants