wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.28k stars 781 forks source link

Poor mouse grab interaction with hyperlink click #945

Closed rodolf0 closed 3 years ago

rodolf0 commented 3 years ago

Describe the bug

When using an app that captures the mouse (eg: vim with setting mouse=a) clicking a hyperlink shouldn't interact with the application. Current behavior is passing the event and mods which results in the application responding in unexpected ways.

Relevant config snippet

  mouse_bindings = {
    -- Change the default click behavior to only selects text, not to open hyperlinks
    {
      event={Up={streak=1, button="Left"}},
      mods="NONE",
      action=wezterm.action{CompleteSelection="PrimarySelection"},
    },
    -- and make CTRL-Click open hyperlinks
    {event={Up={streak=1, button="Left"}}, mods="CTRL", action="OpenLinkAtMouseCursor"},
  },

To Reproduce

Broken scenario

  1. Open blank file in vim
  2. Type a URL in insertion mode, example: http://www.google.com
  3. In command mode: set mouse=a
  4. With the above wezterm config, hover mouse over hyperlink and Ctrl+Click to open the link.

Scenario that works because app ignores mouse

Same as above but in step 3 in command mode, disable mouse set mouse=

Expected behavior

Ctrl + Mouse-Click while hovering on top of the hyperlink should trigger the action (per the config OpenLinkAtMouseCursor) and suppress sending the click to vim.

What actually happens is that vim gets a Ctrl+Click event which triggers some unexpected action.

Alternatively if hyperlinks are not expected to work within applications such as vim, should hyperlink highlighting be disabled? (hopefully expectation is that hyperlinks can be used within apps!)

Environment:

bew commented 3 years ago

I've added a note in the docs specifically for this case, in #916 !

rodolf0 commented 3 years ago

I've had this problem for a while and hadn't checked recent docs. Thanks!

rodolf0 commented 3 years ago

Actually adding a "Nop" action for mouse down as suggested in the new docs didn't work for me. I believe this is a different issue. This is the config I used:

  mouse_bindings = {
    -- Disable left click from opening hyperlinks
    {
      event={Up={streak=1, button="Left"}},
      mods="NONE",
      action=wezterm.action{CompleteSelection="PrimarySelection"},
    },
    -- and make CTRL-Click open hyperlinks
    {event={Up={streak=1, button="Left"}}, mods="CTRL", action="OpenLinkAtMouseCursor"},
    {event={Down={streak=1, button="Left"}}, mods="CTRL", action="Nop"},
  },

It feels (maybe I'm wrong) that the updated docs explaining the gotcha are incorrect? Per https://wezfurlong.org/wezterm/config/mouse.html there isn't a "Single Left Down" default assigment with CTRL modifier, so I'm assuming it doesn't actually send any event. To verify this, if I try the default mouse bindings and try to click, double-click, click-and-drag, etc. while holding CTRL then no mouse interaction happens (note, trying this directly in the terminal, not inside vim).

I'm back to my original suspicion, that even when wezterm attempts OpenLinkAtMouseCursor when using CTRL modifier, the event is propagated to the underlying application. Maybe for applications that capture the mouse there should be a way to prevent event propagation if OpenLinkAtMouseCursor is going to be executed.

wez commented 3 years ago

If you're running vim in mouse mode, vim grabs the mouse input which means that you need to hold down SHIFT in order for your mouse bindings to match.

I recently added https://wezfurlong.org/wezterm/config/lua/config/bypass_mouse_reporting_modifiers.html which describes this behavior and allows changing the modifiers for that if you don't like it being SHIFT; it has to be something though, rather than nothing.

I tried the config in https://github.com/wez/wezterm/issues/945#issuecomment-881167764 and it seems to behave if you hold both CTRL (to match your assignment) and SHIFT (to bypass the mouse capture).

I did find a minor issue that didn't seem to affect this: fcd55127092717b876f65361f6a7123e8ede82ed

rodolf0 commented 3 years ago

In both vi and nvim with no plugins and a null config (vi --noplugin -u /dev/null or nvim --noplugin -u /dev/null), then command se mouse=a, holding SHIFT+CTRL + LeftClick in my case prevents the OpenLinkAtMouseCursor but still sends the event to vim which makes vim show the following

E433: No tags file
E426: tag not found: google
Press ENTER or type command to continue
wez commented 3 years ago
; cat /tmp/945.lua
local wezterm = require 'wezterm';

return {
 mouse_bindings = {
    -- Change the default click behavior to only selects text, not to open hyperlinks
    {
      event={Up={streak=1, button="Left"}},
      mods="NONE",
      action=wezterm.action{CompleteSelection="PrimarySelection"},
    },
    -- and make CTRL-Click open hyperlinks
    {event={Up={streak=1, button="Left"}}, mods="CTRL", action="OpenLinkAtMouseCursor"},
    {event={Down={streak=1, button="Left"}}, mods="CTRL", action="Nop"},
  },
}
; cat /tmp/wat.txt
http://example.com
; wezterm --config-file /tmp/945.lua start vim /tmp/wat.txt

ctrl+shift+click on the example.com URL doesn't cause the vim tag messaging for me; instead it opens up the URL.

; wezterm --version
wezterm 20210711-220223-ac5199c2

Can you try the nightly build? There were a couple of other mouse reporting related fixes that went in since the last release, so I wonder if that's what's really causing you trouble.

rodolf0 commented 3 years ago

OK, tried the nightly build (20210715-222535-fcd55127). holding SHIFT+CTRL seem the issue goes away. I see nightly introduces some vim background rendering issue but that's another matter. I'll try a few nightly versions. Thanks!

wez commented 3 years ago

Please file a separate issue for what you're seeing in vim!

github-actions[bot] commented 1 year ago

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.