Replies: 1 comment 1 reply
|
the gap is real, the help overlay listed every key and never the glyph next to it, so the legend lived only in the README. That part is fixed in #352, merged to master and in the next release: the hover part I'm not going to take. This is a keyboard-driven TUI and a mouse tooltip is the last thing I'd expect in one. There is also the same problem I ran into on #317: ctrl+mouse is claimed by iTerm2, xterm, tmux and zellij before the app sees it, and those are backends the plugin launches into, so the feature would work in some terminals and silently do nothing in others. All-motion reporting on top of that means an Update+View cycle per cell the pointer crosses, which the wheel coalescing in #179 exists to avoid. Too much machinery for a legend that the help overlay can carry in one line per icon. |
Uh oh!
There was an error while loading. Please reload this page.
The status bar uses compact icons for modes such as collapsed view, filtering, etc. This keeps the interface pretty, but the icons are difficult to understand for new or occasional users. Opening the full help screen works, but it removes the immediate connection between an icon and the mode it represents.
I experimented with an interaction inspired by IDEA’s modifier hints: hold
Ctrland move the pointer over a status bar icon to display a small tooltip. The tooltip shows:The implementation is opt-in using
--mouse-hover(REVDIFF_MOUSE_HOVER, ormouse-hover = true). Enabling it switches terminal mouse handling to all-motion reporting. The default remains unchanged.I did a little POC where mouse motion identifies the icon under the pointer, while the tooltip is composed as a one-line overlay above the status bar, and it's look like that(attached). It's dismissed when the pointer leave, another input event occurs, the terminal is resized or modal popup is opened.
WDYT?
All reactions