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 <[email protected]>: > Hey, > > * Stefan Tatschner <[email protected]> [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 | [email protected] (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/
