previous window not quickfix window when jumping back from already open split

[Konfekt]

If the quickfix window, the buffer that contains the line of a quickfix entry and another window are shown the current tab, then,

1. inside the quickfix window with the cursor on the line of the quickfix entry, hitting the mapping bound to g:qfenter_keymap.hopen, by default <Leader><Space> (to jump to the buffer of that quickfix entry), and
2. hitting <c-w>p (see :help CTRL-W_p), now inside the window of the buffer that contains the quickfix entry

then the focus should expectedly go back to the previous window, the quickfix window.

Instead, it will be that of the other window.

[yssl]

I've noticed there was a discrepancy between the 'prev win / tab' behavior of new win commands (such as vopen) and new tab commands (such as topen).

Prior to the new version 2.4.1, the previous window is the window focused before the quickfix window for new win commands, whereas the previous window and tab are set to the quickfix window from which the QFEnter open command is invoked and the tab the window belongs to for new tab commands.

To match these two behavior, I've add a new option g:qfenter_prevtabwin_policy.
The default value is 'qf', which makes the previous window and tab be set to the quickfix window from which the QFEnter open command is invoked and the tab the window belongs to, because I believe this is more desirable.

You can just use let g:qfenter_prevtabwin_policy = 'qf' to get the result you want.

[Konfekt]

Thank you!

[Konfekt]

Albeit, it only works on the first invocation of g:qfenter_keymap.hopen. The second time it jumps back to the other window instead of the quickfix window. That is, after two invocations of g:qfenter_keymap.hopen on two different quickfix entries the alternate window is not the quickfix window. Expected: It is the quickfix window.

[yssl]

Could you give me more details about your test settings?
When I tested "two invocations of g:qfenter_keymap.hopen on two different quickfix entries" it works fine.
Executing wincmd p both on the first and second splitted window moves the cursor back to the quickfix window.

[Konfekt]

In a tab with two windows,

• a window of the quickfix list with two entries 1 and 2 from different files,
• a window of the file of entry 1,

hopen on entry 2 and windcmd p returns to the quickfix list, but then hopenon entry 1 and wincmd p jumps to the window of entry 1 instead of the quickfix list.

[yssl]

I've just pushed a commit that fix a bug with 'open' command, not 'hopen' command.
I'm not sure why 'hopen' makes such a result, but anyway could you try it with the latest code again?
And is it right that your 'hopen' means <Leader><Space> key input (by default)?

[Konfekt]

Yes, hopen means hitting the mapping bound to g:qfenter_keymap.hopen, by default <Leader><Space>.

Thank you fixing the bug but this specific issue persists. On the second wincmd p the focus is on the window of the other file instead of the quickfix list.

[yssl]

I've tested the scenario with a freshly installed vim 8.1.2269 on freshly installed Ubuntu 20.04 which is installed as a singularity container from https://cloud.sylabs.io/library/_container/5baba99394feb900016ea433, but cannot reproduce the reported behavior. The qf option works correctly in that system as well.
There are no initial settings and plugins except vim-plug and this QFEnter in the test system.
I'm wondering whether some of your plugins or settings might affect this behavior..? Could you test the scenario with a "fresher" system?

[Konfekt]

I can reproduce on Vim 8.1568 and the vimrc reading

let &rtp = '~/.vim/plugged/QFEnter/' . ',' . &rtp
filetype plugin indent on
syntax on
set switchbuf=useopen

[Konfekt]

I am sorry, I missed mentioning in the initial post that set switchbuf=useopen is used.

[yssl]

Okay, it's from the use of switchbuf.
I've committed the fix, so try it with the latest code.

[Konfekt]

Thank you! It's working now.