[vim] <CR> in a quickfix-window would split a buffer if it's a HELP buffer (#516)
Bohr Shaw
Tested with :tab help eval | vimgrep quickfix % | cwindow | .+cc
—
Reply to this email directly or view it on GitHub.
Daniel Hahler
I have noticed this for buftype=nofile in general.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
Tomas Varneckas
I've encountered this issue as well.
For those who find this, this line of code is what's causing this:
https://github.com/vim/vim/blob/012eb6629337fdf8afca78a24faa132e9b42e7b4/src/quickfix.c#L2207
Any non-normal buffer (i.e. where buftype is not empty) is skipped from the list of buffers considered for reusing when doing <CR> in a quickfix window.
I've hit this with vimfiler buffers. They're also marked as nofile.
This could be circumvented with an extra option controlling this logic. Something like quickfixusablewindows with default of normal and possibility to add nofile and other buffer types.
For now I've done autocmd FileType vimfiler setlocal buftype= for myself. It fixes the issue with vimfiler, though introduces some others, like :qall getting blocked with "unsaved changes" for vimfiler buffers.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Daniel Hahler
A better workaround might be to map <cr> (or some other key) in qf windows to temporarily change buftype, triggering the real <cr>, and then restore it.
See https://github.com/blueyed/dotfiles/blob/master/vim/after/ftplugin/qf.vim for when you want to handle/wrap any existing <cr> mapping, and for the workaround for #908 in general.
Tomas Varneckas
@blueyed thanks for the tip!
Your proposed solution would work for <CR>, but there are more ways to trigger the bad behaviour. For example issuing :cnext or :cc <nr> from the quickfix window will also open a separate buffer instead of reusing a nofile one. I tend to hit this case because of unimpaired shortcuts ([q, ]q). So then you would need to wrap a lot of commands to completely cover this.
David le Blanc
A better workaround might be to map
<cr>(or some other key) in qf windows to temporarily changebuftype, triggering the real<cr>, and then restore it.
This is no good because the 'buftype' setting needs to be changed in the "target" buffer, not the currentl buffer. Remember a quickfix list contains entries for many possible buffers/filenames.
There are possibly many reasons to exclude no-file and no-write buffers when processing, but quickfix really shouldn't be one of them.
On a whim, I duplicated the bt_normal() as bt_mostly_normal(), a function to accept 'nofile' and 'nowrite' as "normal", then edited the functio qf_find_win_with_normal_buf() to use bt_mostly_normal() instead of bt_normal() when searching a window showing the required buffer. Vim failed about three quickfix related tests (which appear to specifically create nofile buffers and expect extra windows to be created). Otherwise it started behaving how I wanted.
Mark Woods
FWIW, this also bothered me but I've mostly worked around it using an existing plugin, https://github.com/yssl/QFEnter, which allows quickfix items to be opened in the previous window, even nofile windows, and supports custom exclusions (e.g. nerdtree). It remaps <cr> and redefines :cnext and friends and it mostly just works out of the box.
:cnext etc. seems a little buggy when the qf window is focused, but otherwise works fine (this is good enough for me, it's when the quickfix window is hidden or not-focused that I use :cnext, but YMMV).
I also added a custom mapping to improve handling of excluded files, rather than simply error when trying to open in an excluded window, try the next window, see yssl/QFEnter#26
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
FWIW, this also bothered me but I've mostly worked around it using an existing plugin, https://github.com/yssl/QFEnter, which allows quickfix items to be opened in the previous window, even
nofilewindows, and supports custom exclusions (e.g. nerdtree). It remaps<cr>and redefines:cnextand friends and it mostly just works out of the box.
:cnextetc. seems a little buggy when the qf window is focused, but otherwise works fine (this is good enough for me, it's when the quickfix window is hidden or not-focused that I use:cnext, but YMMV).I also added a custom mapping to improve handling of excluded files, rather than simply error when trying to open in an excluded window, try the next window, see yssl/QFEnter#26
vim-dev ML
On Thu, Feb 10, 2022 at 6:57 AM Mark Woods ***@***.***>
wrote:
> FWIW, this also bothered me but I've mostly worked around it using an
> existing plugin, https://github.com/yssl/QFEnter, which allows quickfix
> items to be opened in the previous window, even nofile windows, and
> supports custom exclusions (e.g. nerdtree). It remaps <cr> and redefines
> :cnext and friends and it mostly just works out of the box.
>
> :cnext etc. seems a little buggy when the qf window is focused, but
> otherwise works fine (this is good enough for me, it's when the quickfix
> window is hidden or not-focused that I use :cnext, but YMMV).
>
> I also added a custom mapping to improve handling of excluded files,
> rather than simply error when trying to open in an excluded window, try the
>
>
> When you select an entry in the quickfix window, the file will be opened
in a usable buffer.
Any buffer with the 'buftype' set is considered as not usable. This is
because many
plugins mark a buffer as special (by setting 'buftype') and then display
some information
in the buffer. For example, the taglist/tagbar plugins display the symbol
information in a
buffer. The same applies for 'terminal', 'prompt' and 'location list'
buffers.
If these buffers are used for opening a file from the quickfix list, then
it will affect the
plugin and user workflow.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Mark Woods
Thanks @yegappan, I do understand why only "usable" buffers are used to open items from the quickfix list, but I also want some additional control over what I consider to be a "usable" buffer, to allow some exceptions to the never re-use special buffers rule.
For example, I open your MRU plugin in the current window. I consider that to be a re-usable window, but I accept there is no way for vim to predict that I might consider that a re-usable window. The ability to configure a list of re-usable windows is what the QFEnter plugin gives me, though admittedly in a roundabout way.
It would be nice if the ability to customise the rules for what is considered a usable buffer was somehow supported in vim.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
Yegappan Lakshmanan
Thanks @yegappan, I do understand why only "usable" buffers are used to open items from the quickfix list, but I also want some additional control over what I consider to be a "usable" buffer, to allow some exceptions to the never re-use special buffers rule.
For example, I open your MRU plugin in the current window. I consider that to be a re-usable window, but I accept there is no way for vim to predict that I might consider that a re-usable window. The ability to configure a list of re-usable windows is what the QFEnter plugin gives me, though admittedly in a roundabout way.
It would be nice if the ability to customise the rules for what is considered a usable buffer was somehow supported in vim.
vim-dev ML
On Thu, Feb 10, 2022 at 9:32 AM Mark Woods ***@***.***>
wrote:
> Thanks @yegappan <https://github.com/yegappan>, I do understand why only
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Mark Woods
You can try setting the 'switchbuf' option to 'uselast'. With this setting, when you select a file from the quickfix window, it will be opened in the previous window (irrespective of the type of buffer in the window). If the file is already present in a window, then that will be used.
I already have switchbuf set to useopen,uselast (vim 8.2.2681), but this does not work consistently for me with special buffers. I thought it didn't work at all, but with some further testing just now I've noticed that it does work when there is at least one normal buffer open in a window (even if that window is not the target window for opening quickfix items), but if all windows contain special buffers, the quickfix item will still open split above, even with switchbuf=uselast.
For example, if I open vim and :set buftype=nofile | grep! foo | copen | cn the first match will open split above. Similarly, if I open vim and :vsplit foo | exec "windo set buftype=nofile" | grep! foo | copen | cn the first match will still open split above. However, if I open vim and :vsplit foo | set buftype=nofile | grep! foo | copen | cn the first match will open in the foo window, as expected.
Regardless of the above, while uselast is definitely useful, it still doesn't get me where I want to be, which is to open quickfix items in the first window I consider to be usable, starting with the last window. For the most part I consider usable to be the same as what vim considers usable, i.e. not a special buffer, but there are exceptions, in my case I want to reuse bufexplorer and MRU windows as I load these in the current window.
This is not a new problem, and I'm far from the only person to run into it. There is a feature suggestion on both vim and nvim projects in github for a "sticky" buffer which would address it. It's also an issue for navigation plugins as there is no consistent way to set what is a usable window. Some have built in workarounds, e.g. ctrlp.vim, others have documented workarounds, e.g. FZF.vim (see junegunn/fzf#453).
It would be great to see this addressed directly in vim. In the meantime, I'm using QFEnter to solve the problem for quickfix windows, and a custom FZFOpen() command to solve the problem for FZF.vim.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
Mark Woods
Just wondering... would a skipbuf setting make sense to tell vim to skip certain buffers when switchbuf is set to uselast?
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.