Compatibility with mouse mode in vim/tmux

[tamagokun]

I'm thinking this is just a weird consequence of hterm, but I am experiencing some annoying scrolling behavior while inside of neovim.

Not sure if it matters, but I use a magic mouse which uses smooth scrolling.

• Scrolling up to the very top is difficult. As soon as I remove my finger from the magic mouse, it tends to scroll back down a few lines.
• Random insertion of characters. This one is really making it hard to use vim inside of hyperterm. If I am scrolling around in insert mode, sometimes characters will get randomly inserted in the buffer. I've seen ">" "e" and "%" so far.

I'm going to attempt to screen capture this and post to this issue.

[jwhitley]

I'm observing this same behavior in both neovim (recent HEAD build) and vim (8.0).

In fact, this exact same probem shows up with tmux if the mouse wheel is configured to browse the tmux backscroll history. My tmux scroll configuration is here.

In my replication, I'm also seeing something wierd: the tmux pane to the left of my test pane is running a gulp watcher task. Scrolling in tmux is an action isolated to the pane being scrolled. But when using Hyper, the left, non-scrolling gulp pane is getting character input during scrolling. See the 4's and forward slashes in the following screencap:

[nerdpad]

Also happens to me when I try to select & drag the mouse. Here is a demonstration.

https://youtu.be/7t-ReyyhtJk

[tamagokun]

Maybe mouse events are not 100% supported and Hyper is incorrectly interpreting them?

This is really the only thing preventing me from this app full time

[dotcypress]

Fixed in #1111

[flybayer]

This was fixed for me a month or more ago 👍

[caesar]

This is definitely not fixed for me in 1.0.0 (1.0.0.1303).
Or is that commit after the release of 1.0.0?

[ppot]

@caesar yes this will be in 1.0.1 releasing soon!

[caesar]

Thanks Philippe, looking forward to it!

[tamagokun]

Not fixed as of 1.0.1.

Screen capture of using neovim in Hyper 1.0.1 (no tmux). Trying to scroll while in INSERT mode.

[tamagokun]

I wonder if this is related to #1291

Both seem to indicate that actions that should not insert characters in vim are actually inserting random characters.

[jwhitley]

FWIW, this does appear fixed for me, in both normal and insert modes, using:

• macOS: 10.12.2
• Hyper.app: 1.0.1

and any of:

• vim: 8.0
• neovim: recent HEAD build at 29e6515
• tmux in combination with either of the above

However, I do get a "bounce back" effect: scroll using a mac trackpad. The editor will stay on the final line for a moment, then snap down three lines. E.g. if I scroll to the top of the file, line 1 will be at the top of the window, then a moment later, line 4 will snap to the top. Yet this snap-down behavior can occur anywhere in the file. In limited testing, it is very highly repeatable for me, close to 100% in all the combinations listed above. I thought there might have been a separate issue for this problem, but I can't find it now.

For comparison, the bounce-back problem doesn't occur at all in iTerm2 3.0.13.

[tamagokun]

@jwhitley I also see the bounce back with my magic mouse. This is because of "elastic scrolling" in the web view. Terminal windows normally don't have that.

As for my screen capture above, I can't reproduce it consistently, only occasionally, which makes it a pain to track down. I've found it happens more often if i'm using splits.

[flxsource]

I have the same problem (macOS 10.12.3, Hyper 1.1.0.1408) with insertion of character on mouse events (including scrolling and clicking). This only (and always) occurs within tmux. Interestingly, the click event only prints characters when I click on the right hand 3/4 of the screen...

[therealplato]

this is pretty painful! I observe this without tmux, including the behavior that clicks on the left side work and right side spams junk input.

macOS 10.12.3
Hyper 1.1.0.1408
vim 8.0.0094 installed through brew

[therealplato]

Still observing this with Hyper 1.3.0.1614 and vim 8.0.0344 and only this vim config (including mouse=a.)

Didn't realize till this bug how much my vim workflow relies on scrolling and mouse input, but it's irritating enough to make me give up on OSX hyper and go back to Terminal.

I'll come back when this gets fixed!

[justsee]

Yes I've just tried Hyper Version 1.3.1 (1.3.1.1628) as a full-time terminal for a web project, and this is a showstopper in Vim NeoVim 0.1.7

My own brief experiments with the bug yielded similar weirdness as outlined above:

• split a window into two panes : | Vim | shell |
• start and stop scrolling in the shell pane
• move the mouse focus to the vim pane
• the machine gun of random text input begins firing at vim for as long as the usual scroll deceleration period would be

[therealplato]

@justsee well observed - i reproduced that junk input continues during scroll deceleration.

I also observed something i hadnt spotted before:

• when my cursor is in the left pane, and i click the right pane, the cursor remains in the left pane, and junk input is sent to the left pane

edit - for anyone who looks at fixing this - even when scrolling worked in Hyper it was approximately 2-4x more sensitive than Terminal or xterm, i.e. the same finger movement scrolled lines 4x faster. this plus the "jumps back a few lines after scrolling to top" makes me wonder if the other terminals are getting a raw osx mouse input and hyper is getting signals modified by osx with i.e. deceleration and no-further-scroll stretch

[justsee]

A workaround (for my workflow at least) is to simply disable the mouse in Vim's config:

set mouse=

Alternatively you could just disable it in insert mode: set mouse=nv, but I still noticed if you scroll/stop in one pane and move mouse focus over to the vim pane it manages to insert a limited number of characters occasionally. It's great to have git and vim undo as protection but I can't be dealing with random character entries when writing code.

I only really need the mouse to focus back on the vim pane when finishing scrolling in a side-by-side webview of the related next.js app, as the webview has focus and so key sequences to switch pane focus don't work.

It's not ideal, and there are other issues (performance, janky window resizing) but I'm giving Hyper a litte more time to explore how far away it is from a usable primary terminal for web work.

Having a side-by-side vim + webview (with no browser chrome) in a terminal is too delightful at the moment not to persist a bit longer.

[tamagokun]

As @justsee has said, I can also confirm that this is directly related to using mouse mode in vim. Disabling it results in no problems.

[jkrup]

The same issue seems to happen in tmux with the same workaround solution (disabling mouse)

[apriendeau]

So I think there is a larger issue here with tmux and mouse because I have a setting that works in terminal and iTerm that allow me to click on an open split pane which does not work in hyper.

I am on 1.3.1 and this maybe separate issue but the mouse reporting into tmux are failing for me.

[wmarbut]

I can confirm with a very similar config to @jwhitley that the issue isn't fixed on HyperTerm 1.3.3

Scrolling is extremely twitchy
I cannot click on different panes with VIM/NeoVim; which does work inside of iterm2 and terminal

Mac OS 10.12.4 (16E195)
Hyper 1.3.3
NeoVim 0.1.6
Vim 8.0

[veryjos]

Same here, tmux with mouse works in iterm2 and not here. Same behavior of pressing a bunch of keys instead of scrolling. Selecting a pane with mouse also doesn't work.

[tamagokun]

This appears to be fixed after upgrading to 2.0.0+ which introduced using xterm rather than hterm.

Scrolling is still super touchy/fast, but i've been using mouse mode in neovim for a few days now and have had 0 issues.

[caesar]

Great! I had eventually switched back to iTerm2, but just gave Hyper 2.0 a try and haven't had any issues with the scrolling so far - apart from still being very sensitive/fast (clearly they are taking the pixel values returned by the mousewheel event and using them without dividing by a suitable factor to make them equivalent to line-based scrolling).

I have to say Hyper is still noticeably slower than iTerm – that's probably inevitable with all the overhead of a browser rendering engine – but at least this showstopper bug has been fixed by the change to xterm. Bravo!

[ntkoopman]

I still have a weird mouse issue in 2.0.4 in combination with vim. After you hold shift and select text in vim the mouse will start inserting characters when moved. This continuous until there is another vim mouse event.

[jbbudzon]

Any clues as to why scrolling is so twitchy but only inside vim/tmux? This is my last real mouse related issue with hyper I'm trying to track down.

[ppot]

@jbbudzon Frankly this is outdated we aren't on hterm anymore. I will close this issue. Feel free to open new one if relate to xterm.