Hyper: DAE hate the scrollbar?

Created on 5 Jul 2016 · 12Comments · Source: vercel/hyper

Should we hide it by default?

help wanted Enhancement

Source

rauchg

Most helpful comment

@rauchg: Just my five cents, if you don't mind.

I am on Linux and use rxvt-unicode (AKA urxvt), which is a popular terminal emulator. In urxvt it is common practice to hide the scrollbar because it is also very ugly. When hidden, it behaves like the hterm option you disagree with, where the scrollbar is always hidden. I find this to be preferable, as the mouse wheel handles the scrolling, and when I start typing the terminal snaps back to the bottom. No Ugly scrollbar takes up any of my precious ultrabook pixels or obscures my text.

Besides, many people are going to be using Terminal Multiplexers like tmux or screen where the scrollback buffer is completely handled by the multiplexer and mouse scrolling is absolutely void.

In both these cases, there is an argument to be made for hiding the scrollbar completely, which I support. At the very least, please consider making it an option in .hypertext.js, where the option can be either _Always show_, _Hidden when not in use_ or _Always hidden_.

esphen on 17 Jul 2016

👍9

All 12 comments

We should :)

montogeek on 5 Jul 2016

It does not hide it?

montogeek on 5 Jul 2016

It seems like the hterm options hides them completely, all the time. I don't like that. Upon the _user_ scrolling, they should be shown. I'll have to think more about how to do that nicely. One idea is listening on scroll events and ignore them whenever we know that the terminal itself is triggering scrolling.

rauchg on 5 Jul 2016

👍2

This actually sounds like a very difficult problem :(. Here's the best solution I can think of:

If the user places their mouse on the rightmost 50px[1] of the screen, mark overflow: auto (and get rid of it after the mouse leaves that area)
If the user triggers wheel events, mark overflow: auto (and get rid of it after a timer)

[1] 50 is arbitrary to encompass linux, windows, mac. Can probably be less on the mac.

rauchg on 5 Jul 2016

👍2

I like the second idea, is how iTerm works by default, it only shows the scrollbar if you scroll using wheel's mouse, when you stop it disappears after ~500 ms

montogeek on 5 Jul 2016

I occasionally run into a situation where the scrollback is super long, and I want to scrub it much faster than scrollwheel lets me. I usually start scrolling, then grab the scroll handle and drag it up and down. I noticed that unlike most OSX apps, this behavior is not the same (normally when you hover the scroll handle in an OSX app, it'll slightly expand it's width and become draggable), I'd love to see that act like the rest of the OS!

jesseditson on 5 Jul 2016

Here's a quick gif of that behavior in chrome:

jesseditson on 5 Jul 2016

@rauchg: Just my five cents, if you don't mind.

Besides, many people are going to be using Terminal Multiplexers like tmux or screen where the scrollback buffer is completely handled by the multiplexer and mouse scrolling is absolutely void.

esphen on 17 Jul 2016

👍9

On the other hand, scrolling far back is so difficult using only the scroll wheel. Neither arrow keys nor page up/page down keys control the scroll position...