wincmd p unreliable

[languitar]

Explain the issue

As explained in mhinz/vim-signify#193 I have encountered a jumping cursor when combining fugitive, vimtex and an autocmd to update vim-signify. I could get rid of this issue, by applying the following patch to the vimtex code:

diff --git a/autoload/vimtex/latexmk.vim b/autoload/vimtex/latexmk.vim
index 939d192..bf340b9 100644
--- a/autoload/vimtex/latexmk.vim
+++ b/autoload/vimtex/latexmk.vim
@@ -346,6 +346,8 @@ function! vimtex#latexmk#errors_open(force) " {{{1
   if !exists('b:vimtex') | return | endif
   cclose
 
+  let winid = win_getid()
+
   let log = b:vimtex.log()
   if empty(log)
     if a:force
@@ -386,7 +388,7 @@ function! vimtex#latexmk#errors_open(force) " {{{1
   if s:open_quickfix_window
     botright cwindow
     if g:vimtex_quickfix_mode == 2
-      wincmd p
+      call win_gotoid(winid)
     endif
     redraw
   endif

[lervag]

Interesting. I wasn't aware of the win_... functions. They seem to be relatively new. That makes it a little bit scary to use them, since it would/could lead to errors for people who use old Vim versions.

Perhaps we could fix this with "older" syntax? Perhaps we could use the more "standard" winnr() function and then execute l:winnr . 'wincmd p'?

[languitar]

@mhinz used a conditional version in the experimental commit he prepared for me to test this. Use that function if it exists, else winnr. Maybe that could be way to go?

[mhinz]

win_getid() and win_gotoid() were both introduced in the same commit: 7.4.1557. Thus I just check if that function is available and fall back to using winnr()/wincmd p otherwise: mhinz/vim-signify@3a8b31d

That said, the fallback isn't 100% reliable as well, since window numbers can change when new windows open (or close). The reliable way for older versions would be setting a w:var and searching that window at the end by looping over winnr('$').

[lervag]

Thanks, @mhinz! Is there a good reason not to just use the fall back in all cases? I'm doing that now, and if there is a good reason to use the newer functions if available, then I might add that later.

[languitar]

Thanks for fixing this!

[lervag]

No problem. Thanks for reporting the problem :)

[languitar]

Hm, seems I am back at this situation. Did anything change in the meantime that could influence what is happening here?

[languitar]

Seems that I am hitting the unreliability @mhinz has explained. Any chance to go to the new API per default?

[lervag]

I think this should be fixed for you through the PR #735.