[qutebrowser] Feature request: Alternative to c.tabs.show_switching_delay

[Florian Bruhin]

Hey Martin,

On Sat, Jan 04, 2020 at 11:17:51PM +0100, Martin wrote:
> for the feature
> "c.tabs.show = 'switching'"
> one can set
> "c.tabs.show_switching_delay = 1200"
> in order to control, how long the tab bar is shown.
> 
> Since the tabs are switched with shift+j or shift+k, I think a better
> solution would be to show the tabs as long as the shift key is held
> down, after pressing shift+j.
> 
> From a user perspective, this seems very natural behavior to me, and it
> is least annoying, since:
> Sometimes I want to see the tabs for a long time (searching a long list)
> Sometimes I want the tabs to disappear asap.
> 
> What do you think?

qutebrowser's input model is centered on commands being bound to keys. Without
hardcoding things (which isn't really a possibility - there are no hardcoded
keybindings), that means there's no way to say "do this when shift is
pressed/released". Also, other people might use non-default keybindings (like
gt/gT) for switching tabs.

It's a bit similar to this:
https://github.com/qutebrowser/qutebrowser/issues/4768

If you have an idea how any of those ideas would fit in well with qutebrowser's
configuration, I'm all ears! The only thing I could think of so far is
qutebrowser doing some magic (if tab switching commands happen to be bound to a
keybinding with modifier, do what you proposed with that modifier key), but
that seems quite cumbersome (both to implement and to explain).

Florian

-- 
me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
       https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
       GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
             I love long mails! | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20200104/3e1f39dd/attachment.asc>