Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use 'mousetime' to recognize multi clicks #77

Closed
wants to merge 1 commit into from

Conversation

djjcast
Copy link

@djjcast djjcast commented Sep 30, 2015

Use the value of the Vim mousetime setting to recognize multi clicks. MacVim currently uses the mouse event property clickCount to recognize mulit clicks.

@jpetrie
Copy link
Contributor

jpetrie commented Oct 5, 2015

From what I can tell, this makes MacVim ignore the OS settings for double-click threshold, which may be undesirable for some users. If so, I'd expect this kind of behavioral change to be toggled via an option, rather than replace the existing behavior wholesale.

@djjcast
Copy link
Author

djjcast commented Oct 5, 2015

Yes, it ignores the OS settings and relies on mousetime instead. I agree that this change might catch some users off-guard. Here are a couple of ways to handle it:

  1. Add a preference to either use the OS settings or mousetime like @jpetrie suggested
  2. Use the OS settings if mousetime is set to it's default value (500) and/or a negative number

The reason I want MacVim to support mousetime is to be able to dynamically disable multi clicks through vimscript. Here's my use case:

map <silent> <LeftMouse>
    \ <LeftMouse>:<C-u>if &filetype ==# 'vimfiler' \|
        \ set mousetime=0 \|
        \ let cursorchar = matchstr(getline('.'), '\%' . col('.') . 'c.') \|
        \ if (cursorchar ==# g:vimfiler_tree_opened_icon) \|\|
           \ (cursorchar ==# g:vimfiler_tree_closed_icon) \|
            \ execute "normal 0\<Plug>(vimfiler_expand_tree)" \|
        \ else \|
            \ execute "normal 0\<Plug>(vimfiler_cd_or_edit)" \|
        \ endif \|
        \ unlet cursorchar \|
    \ else \|
        \ set mousetime=500 \|
    \ endif<CR>

This disables multi clicks in all vimfiler windows by setting mousetime to 0.

@jpetrie
Copy link
Contributor

jpetrie commented Oct 21, 2015

I definitely think this needs preference toggle (and should default to off to preserve existing behavior). There's examples of adding these sorts of preferences in the recent ligature pull request you could base the work off of.

@chdiza
Copy link
Contributor

chdiza commented Oct 22, 2015

I was thumbs-down on this, but now I think I may have turned 180 degrees. Is it the case that: mousetime is supposed to govern gVim's double-clicking threshold for all GUI implementations, but our implementation happens to not obey this? :help 'mousetime' suggests so.

If that is the case, then this PR should be merged[1] and there should be a new entry under :help macvim explaining that MacVim, like all gVims and indeed like console Vim, is supposed to ignore your system's thresholds.

And, there should be either no preference option to toggle this, or at worst, if we're going to include yet another divergence from Vim behavior, I would strongly favor @djjcast's idea "2".

Since Vim in the console (including the Vim buried in MacVim when run in console mode) already obeys mousetime at the expense of the system threshold, I see no reason to default MacVim to doing anything else. The worst option to me appears to be to make this a GUI preference checkbox that defaults to ignoring mousetime altogether. To be unpleasantly surprised by the change this PR introduces, a user would have to (a) be the sort of person who uses the mouse with Vim, and specifically, for double-clicking, (b) not have mousetime set in vimrc, and (c) have the system threshold set to significantly less than 500 milliseconds. I doubt the number who meet all three of these is great enough warrant making a bugfix an opt-in affair, especially when it would be so easy to opt-out.

[1] Subject, of course, to this being the right way to make MacVim obey mousetime, and subject to there being no hidden technical reasons why Bjorn didn't just make MacVim obey mousetime in the first place way back when. I have zero qualifications to comment on that.

@djjcast
Copy link
Author

djjcast commented Oct 22, 2015

I think :help mousetime implies that all GUI implementations should respect mousetime. It seems wrong to ignore mousetime or favor the GUI toolkit's interpretation of double-clicks.

There isn't a consensus between the core GUI implementations on how to interpret double-clicks - some use mousetime while others rely on the GUI toolkit.

The GTK+ version uses mousetime in favor of the GDK GDK_2BUTTON_PRESS event. Maybe mousetime wasn't considered when the other GUI implementations were developed - it's an obscure setting that's easy to overlook.

Also, this README outlines how the GUI implementations should work as a "clever terminal".

@jpetrie
Copy link
Contributor

jpetrie commented Oct 22, 2015

Hm, the mousetime documentation does make it sound like mousetime should apply in a GUI context.

But at the same time, there's a lot of (I would argue correct) divergence between vim, gvim and MacVim when it comes to GUI-related options; much of that divergence is based on things that the Windows and Mac GUIs don't do or which aren't idiomatic or sensible in the context of being a reasonably well-behaved and convention-conforming application. And for the GUI variants like gVim and MacVim I'd argue that being "well behaved" in the appropriate OS context is an important feature.

I don't see what's so special about vim that it gets to dictate an override to my double-click speed; I've always been annoyed by gVim's adherence to mousetime with no way to disable it. So one way or another I feel very strongly that MacVim should allow fallback to the OS double-click interval somehow.

I feel less strongly that such fallback should be the default (although MacVim already jumps through a lot of engineering hoops to try to preserve previously-existing behavior, so I'd say there is convention in place for doing so).

I feel even less strongly about how the fallback should be enabled. It's true MacVim has a growing number of preference toggles that exist outside the realm of the vimrc/gvimrc and that is somewhat concerning. It would probably be better if mouse click behavior could be entirely configured in one's vimrc. I don't think @djjcast's suggestion of "use the OS default if mousetime is 500" is a great idea, but falling back to the previous behavior if mousetime is negative might be. The documentation doesn't say what effect a negative mousetime has, so it's possibly at some point it might change to have meaning, but that seems unlikely.

Another option would be to look at how the antialias option is plumbed through, as that appears to be one of the few OS X-only options you can set in vim.

@kopischke
Copy link

But at the same time, there's a lot of (I would argue correct) divergence between vim, gvim and MacVim when it comes to GUI-related options; much of that divergence is based on things that the Windows and Mac GUIs don't do or which aren't idiomatic or sensible in the context of being a reasonably well-behaved and convention-conforming application. And for the GUI variants like gVim and MacVim I'd argue that being "well behaved" in the appropriate OS context is an important feature.

I don't see what's so special about vim that it gets to dictate an override to my double-click speed; I've always been annoyed by gVim's adherence to mousetime with no way to disable it. So one way or another I feel very strongly that MacVim should allow fallback to the OS double-click interval somehow.

👍🏻

@splhack
Copy link
Contributor

splhack commented Dec 9, 2015

@djjcast could you check #168?

@splhack splhack closed this Dec 9, 2015
splhack added a commit that referenced this pull request Dec 9, 2015
`MMUseMouseTime` allows to override the time threshold for detecting multiple
mouse down events using Vim `mousetime` option.

    $ defaults write org.vim.MacVim MMUseMouseTime -bool TRUE
splhack added a commit that referenced this pull request Dec 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants