[qutebrowser] Some feelings about v1.0

[Florian Bruhin]

Hey,

On Tue, Oct 17, 2017 at 05:51:27PM +0000, José Alberto Orejuela García wrote:
> I was very excited about qutebrowser 1.0 and now (hype is not good ever) I
> feel disappointed about some things, mostly when interacting with commands.

Phew, I was prepared for a rant about the new config, but this at least is
something constructive ;-)

> I don't exactly know which ones are all the differences, but I find the
> completion (url based on history or general command completion) very strange
> to me. I cannot test as I won't have access to another of my computers (with
> still outdated qutebrowser) until December, but these are two things I find
> strange:

FWIW the completion code was almost completely rewritten, and most changes in
behavior probably weren't intentional. 

They were mostly done by rcorre who's also on this list, and he probably knows
the completion code better than I do, so he'll probably be able to give you a
more detailed answer :)

> - Default behaviour for moving between completions is tab or shift-tab.

FWIW that's been the case since the completion existed.

> I know that I can make arrow keys also do the job in settings, but what is
> the point of having that disabled by default now?

Nothing is disabled - but arrow keys now navigate through command history (like
in a shell). Previously, alt-p/alt-n did that, but nobody knew it existed.

That being said, I had no idea how many people use arrow keys to navigate
through the completion, and I changed it because a lot of people expected
up/down to go through the history.

Can't please everyone I guess, but I'm tired of the bikeshedding[1] :P

[1] https://shed.bike/

> - Completion is sometimes sorted differently. For example, when I wanted to
> clear downloads, I used to write ":clear" and hit tab, the two results were
> download-clear
> history-clear
> and they were alphabetically sorted. Now, the completions for that are
> search
> history-clear
> download-clear
> config-clear
> and I cannot see what the pattern is, but it's not alphabetically in command
> or command description, for sure. Why is this now happening?

"search" is probably included because the descriptions are now searched as
well.

As for the order, automatic ordering was removed from the completion to be able
to e.g. display bookmarks in the order they are in the file. Instead,
completion functions now order the completions.

So this was probably an oversight, I agree the commands should be sorted.
I'll let rcorre comment on it before opening an issue though ;-)

On Tue, Oct 17, 2017 at 06:02:12PM +0000, Lukas Gierth wrote:
> i agree on the completion problem. It now seems to search not only in
> the command names but also the description of the commands. Thats why
> 'search' comes first in your completion example. Thats not a huge
> problem but I would like the behaviour of first showing all result where
> the characters are in the name of the command and the ones where only
> the description matches after that. Would make more sense honestly.

That'd be nice, but I have no idea how easy or hard it'd be to implement.

On Tue, Oct 17, 2017 at 05:51:27PM +0000, José Alberto Orejuela García wrote:
> By the way, relating completions, there are three things I have always found
> a little annoying in qutebrowser:
> - Not being able to go back to original. I think it could be useful to undo
> completion, for example, writing something, hitting tab (or down arrow) and
> then shift-tab (or up arrow). When I hit tab accidentally I have to start
> from scratch.

While QLineEdit (which qutebrowser uses for the input) has undo functionality,
it looks like the undo history gets cleared when setting the text
programmatically, so qutebrowser would have to implement that by itself.

I'd rather not add more complexity just do that as this part of the code
already is quite complex and handles various funny corner cases. Wonder what
@rcorre thinks, though ;-)

> - Taking into account substitutions in urls. For example, if I want to find
> an url that contained a bang, I cannot find it using ":open !" because that
> won't give any result as ! was changed to %21 in the url.

I have some URLs with ! and some with %21 in my completion, so I think we'd
have to search for both - at which point this really slows down the completion,
which I'd like to avoid ;-)

Also, it introduces special completion matching only applicable to :open, which
is another thing I'd like to avoid.

> - Completion until next difference: when I write ":set col" and hit tab, it'd
> be nice if it completed to color before completing directly to
> colors.completion.category.bg. This is certainly the feature that I see
> hardest to being useful given a proper implementation, because normally there
> could be a lot of partial different coincidences, for example typing
> "duckduck" maybe it should be changed to duckduckgo based on urls or
> DuckDuckGo based on page titles. It's also the thing I miss the least of
> these three.

I can see how that'd be useful for settings, but again, this would introduce
special handling for one particular completion.

> The other thing that disappoints me is that the browser is now significantly
> slower. For example, when I use DDG bangs, redirections are much slower than
> before.

On Tue, Oct 17, 2017 at 06:02:12PM +0000, Lukas Gierth wrote:
> I also agree that the browser somehow feels slower. But i do not really
> know why that is because the completion engine should be faster than the
> old one.

Were you using QtWebEngine before too? If not, that might be the source of it,
and you could try :set backend webkit (and :restart). However, using
QtWebEngine still has various benefits over QtWebKit, especially regarding
security.

On Tue, Oct 17, 2017 at 05:51:27PM +0000, José Alberto Orejuela García wrote:
> Overall, I'm not feeling bad about the update and I'd like to thank Florian
> and all the contributors for all the work you've done. =)

On Tue, Oct 17, 2017 at 06:02:12PM +0000, Lukas Gierth wrote:
> Anyhow, thanks to Florian and all the other contributers for their hard
> work!

Thanks for the constructive feedback!

Florian

-- 
https://www.qutebrowser.org  | me at the-compiler.org (Mail/XMPP)
   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/20171017/3ba600f8/attachment.asc>