[vim/vim] Sticky Buffers (#6445)
Amit Levy
Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
You have a file manager plugin installed (like NERDTree) and you wish to keep it's buffer through your vim session.
The main problem is that if you try to open another file (For example with :FZF) you need to check if your focus is not on the file manager buffer or else this would happen:
(Taken from junegunn/fzf#453)
Plugin developers cannot make their plugin to act nicely with other plugins as fzf developer describes the problem perfectly in junegunn/fzf.vim#326 (comment)
Describe the solution you'd like
Opening a file when the focus is on a buffer that I would like to keep, the file will be open in a different buffer or a vertical split if there are no more buffers.
Maybe marking buffers with sticky mode which can only be close only with :quit ?
Describe alternatives you've considered
The workaround is to use hacky vimscript to try detect the buffer name and then shift the focus:
nnoremap <silent> <expr> <Leader><Leader> (expand('%') =~ 'NERD_tree' ? "\<c-w>\<c-w>" : '').":FZF\<cr>"
But you'll have to use the prefix (expand('%') =~ 'NERD_tree' ? "\<c-w>\<c-w>" : '')." for each possible command you would like, which is tedious.
What if you would like to switch from NERDTree to other file manager? You would have to change everything to match the new buffer name.
This use case is also relevant when using a terminal buffer in normal mode, I don't want to accidently overwrite it with something else.
Additional Context
I'm aware there are mapping to open files in vertical or horizontal split. But the main issue is that I constantly need to know where my focus is and be careful not to overwrite a buffer that I want to keep.
Is there a better solution for this problem other than detecting buffer names?
Please note: I have suggested the same for neovim - neovim/neovim#12517
Thank you for your time.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Dave Kerr
Love it - this would actually serve many use cases, where plugin authors are using buffers for something which is 'not really a file', e.g. looking at git logs, lists of results, etc.
Colin Kennedy
To get an idea of what the implementation for this could be like, maybe it’d be something like
- Add a new setlocal option. Such as setlocal sticky_buffer
- I don’t think there would be a global equivalent for this option. Maybe someone may want it as a global option
- When opening a new buffer, if the current buffer that would be changed is sticky, open a different buffer. Possibly according to :help ‘switchbuf’ ?
- Allow closing a sticky buffer with :close / :quit
- Make sure calls such as :edit fail gracefully when sticky_buffer is enabled
- Maybe if
:edit!is used, allow the buffer to be switched (The documentation for:help edit!does say “Edit the current file always.”)
- Maybe if
Off the top of my head here's some commands that affect the current buffer in a window which would be impacted:
Commands
:edit:buffer:bfirst,:blast,:bnext/:bprev:cabove,:cbelow,:cfirst,:clast,:cnext/:cprev:cdo
I don't think location list mappings matter since they're tied to a single window. I could be wrong?
Mappings
<C-^>
<C-o> / <C-p>
- Capital-letter jump marks. e.g. ``M
or‘M`) - Buffer switching commands such as
gfand other variants K
Neovim
vim.api.nvim_set_current_buf(bufnr)
I think that’s all of them. Am I missing any?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Colin Kennedy
I gave this a shot and it turned out to be simpler than expected. Though because this change affects many commands, writing the unittests will take time. I can't work on this as often as I'd like but at this rate, my branch should be PR-able in a month or so.
I just hope this feature has enough buy-in with Vim maintainers so the PR can be accepted. It's an important feature and I think anyone who has ever made a terminal and quick-fix buffer next to one another has experienced :cnext switching their buffer out accidentally. To say nothing of many plugin maintainers/users who will greatly benefit from this feature.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Colin Kennedy
Taking longer than expected as there's a lot of commands and edge cases. For anyone curious, you can track progress at https://github.com/ColinKennedy/neovim/tree/add_stickybuf (it's Neovim and I'll make a proper Vim branch + PR once it's actually ready to show).
Once the holiday season is over I'll be able to focus on completing the missing commands + polish
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
There's already an option winfixheight and winfixwidth. IMO calling it winfixbuf (or winfixbufnr, winfixbuffer) would make more sense than stickybuf.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Colin Kennedy
Sure, I can change it. Since this is now a "local to window" feature rather than "local to buffer", having a "win" / "winfix" prefix or similar makes sense to me. Before or after the PR is ready we can lock down the name and I'll change all of the code & documentation to match :)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Colin Kennedy
Regarding switchbuf, currently I have got the current logic 100% working without any modifications to 'switchbuf''s code nor its values. All that was needed was to simply not store a window ID as a previous window if that window has 'stickybuf' enabled. The quickfix logic already handles finding a fallback window quite nicely. So my previous suggestion of modifying 'switchbuf' was unneeded.
@Shane-XB-Qian If you meant something else, please let us now
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
ok, i was facing similar situation like the description of this ticket said, operation on quickfix may open buf/fs into 'netrw' window (like here it is nerdtree), i was told 'switchbuf' was the solution, but sometime i found it maybe still jumped into 'netrw' window, so later i personally forced it jump to 'preview window' only.
// this is my solution, i was thinking it is similar to you, but looks you designed more, just a FYI, please donot mind my proposal.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #6445 as completed via 2157035.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.