2

I tend to use GVim a lot. Very frequently, I'll click on some other window and then when I click on vim to regain focus, my cursor will end up in some random location depending on where I clicked. I find this extremely obnoxious. I can generally remember where my cursor is before navigating away, but I don't like having to hunt it down every time I return to using gvim.

I thought I could fix this by adding this to my .vimrc:

au FocusGained * normal <C-o>

(where <C-o> is the actual control character) but this doesn't work. It usually just navigates away from my current file. This happens even if I add

au FocusLost * normal m`

too.

So I gave up on fixing this through the use of the jumplist. Instead, it seems like I could fix this by setting mouse. In general, I'd prefer to have

set mouse=a

I initially tried the following autocommands:

au FocusLost * set mouse=
au FocusGained * set mouse=a

But it seems like the autocommand is processed before the mouse click is registered and the cursor is moved.

My next thought is to asynchronously re-enable the mouse so that the mouse click will be ignored before my mouse setting is changed. Something along the lines of:

au FocusGained * async_call("set mouse=a", 200ms) "pseudocode

But I'm not sure exactly how to do this step. I can't find any info on the correct way to asynchronously call vimscript. I would like an answer either for how to do this asynchronously like I explained, but if there's a simpler way too achieve this then that would be appreciated too.

Any help would be appreciated. I am using vim 8.0 GUI version on Windows.

  • The au FocusLost * set mouse= technique works for me on GUI Vim 7.4 on Windows (10). I wonder if this is a bug introduced in Vim 8? Alternatively, perhaps a plugin you're using is mucking with something? – brhfl Apr 13 '18 at 20:54
  • 1
    @brhfl When you do that, are you including both autocommands? au FocusLost * set mouse= to disable it, and then au FocusGained * set mouse=a to reenable it? I'd like to have mouse=a in general, otherwise I could just do mouse= so that I don't need to bother with autocommands. – DJMcMayhem Apr 13 '18 at 21:00
  • Yes, sorry for being unclear. When I do both commands as you presented them, the behavior is what I expect (which, I believe is what you desire): when I click into gVim from another window, the cursor doesn't move, window/split isn't changed, that click effectively didn't click. All further mousing works as expected until I switch focus again. Interestingly enough I can still scroll using the scroll wheel with the window out of focus. – brhfl Apr 13 '18 at 21:10
  • @brhfl I tested it with gvim -u NONE and clicking in the window still moves the cursor. Which OS are you running? – DJMcMayhem Apr 13 '18 at 21:23
  • Windows 10 Enterprise Version 1607 Build 14393.2125 – brhfl Apr 13 '18 at 21:27
2

I guess mouse clicks don't update the jump list. (:help jump-motions seems to confirm this is the case.)

Try this, for the async solution:

augroup MouseHack
  autocmd!
  autocmd FocusLost * set mouse=
  autocmd FocusGained * call timer_start(200, 'ReenableMouse')
augroup END

function ReenableMouse(timer_id)
  set mouse=a
endfunction

Note that this requires the +timers feature, introduced in v7.4.1578. If you're likely to be running an earlier version of Vim, you'll want to surround all the above with a if has('timers') guard.

  • This works perfectly. Thanks for the help! – DJMcMayhem Apr 20 '18 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.