List of Currently Opened Tabs?

Matt mattator at gmail.com
Fri Jan 29 22:54:02 CET 2016


I suppose you use a tiling WM ? in which case you could force every
new tab as a new window and use rofi window switcher (works for
i3wm.com, not sure for other WM though).
Then I am not sure qutebrowser is capable of syncing history between
instances (like zsh or neovim do) ? which can be annoying

2016-01-29 10:54 GMT+01:00 Florian Bruhin <me at the-compiler.org>:
> Hey,
>
> * Stefan Tatschner <rumpelsepp at sevenbyte.org> [2016-01-29 10:28:51 +0100]:
>> I often have a lot of tabs open in qutebrowser. So I am looking for a
>> solution to deal better with a lot of tabs. I have come to the idea that
>> some dmenu/rofi userscript would be fine.
>
> IMHO ideally this would be integrated into qutebrowser's completion,
> see this issue: https://github.com/The-Compiler/qutebrowser/issues/32
>
> Unfortunately I'm working on stuff which is higher priority right now,
> probably for some more months (tests, QtWebEngine, per domain
> settings, plugins).
>
> I'm still hoping someone will contribute that one ;)
>
>> That script should get a list of all currently opened tabs, pipe it into
>> dmenu/rofi and finally send some "please change to tab number soandso"
>> command to qutebrowser.
>>
>> I have not yet found a qutebrowser command to get a list of all opened
>> tabs. Am I missing something?
>
> There isn't. You'd typically do this via an userscript, and there's
> currently no way for an userscript to request more information (or get
> "answers" to commands it sends).
>
> qutebrowser could expose this information to userscripts via an
> environment variable, e.g. some $QUTE_TABS variable set to something
> like:
>
> 0 0 url title of first tab in first window
> 0 1 url title of second tab in first window
> [...]
>
> The problem with that approach is that it might be too much data for
> an environment variable, so maybe $QUTE_TABS would need to be a
> filename of a temporary file, like $QUTE_HTML and $QUTE_TEXT is.
>
> Then again I'm not sure how much it makes sense to shoehorn all
> possible usecases into somewhat fragile userscripts. I'd rather see
> plugins written in Python (or possibly JS at some later point), but it
> might still take a while until that's ready.
>
> Florian
>
> --
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/



More information about the qutebrowser mailing list