previous window not quickfix window when jumping back from already open split about qfenter HOT 12 CLOSED

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

from qfenter.

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.

from qfenter.

Thank you!

from qfenter.

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.

from qfenter.

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.

from qfenter.

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.

from qfenter.

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)?

from qfenter.

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.

from qfenter.

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?

from qfenter.

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

from qfenter.

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

from qfenter.

Thank you! It's working now.

from qfenter.