Re: [qutebrowser] Some feelings about v1.0

[Florian Bruhin]

On Wed, Oct 25, 2017 at 04:02:27PM +, José Alberto Orejuela García wrote:
> > Yes - if you filter for ! in e.g. the setting value completion or whatever, 
> > you
> > wouldn't expect qutebrowser to filter for %21.
> 
> But the point is that it doesn't matter as there won't be strings like that
> in settings, don't you think?

It's not just "!", it's a lot of other special chars as well. They can very
much occur in e.g. setting values, and probably other places as well. Treating
them specially everywhere just because they happen to be special in URLs is not
acceptable.

> By the way, I also find the browser more slow when scrolling, is that due to
> qtwebengine as well?

Might be - the latest master branch also has some improvements for scrolling
performance.

> I also have 2 issues more:
> 
> - Sometimes, when I use hints to go to a form box to fill it, it doesn't
> enter insert mode (and if I enter insert mode manually with "i", nothing is
> written as I type). I will find a concrete example in a page (I forgot to
> write it down when it happened) and send it, so you can skip this by now
> until I find a place to reproduce it.

The code finding out about editable elements is just a heuristic - related 
issues:
https://github.com/qutebrowser/qutebrowser/issues/253
https://github.com/qutebrowser/qutebrowser/issues/2471

> - Randomly, qutebrowser seems to get stuck but it's not, it's only the
> graphical part. For example, if I open a new tab (it should focus on it as
> that's the usual case), I keep seeing the same in the window (except that I
> can see that page title is different, as if I were on the new tab); I can
> even click on other tabs and see that page title changes, but not the content
> or tabs bar, those are frozen, even though I can click on them and I can see
> that they're interacting. If I minimise the window and then restore it,
> everything is fixed; BUT sometimes, before I can minimise it, it gets all
> graphics in the computer stucked and I see a notification like "desktop
> effects were restored due to a graphic problem" (I'm using plasma on Arch). I
> guess this will be hard to debug, so if I can help in any way, I'm willing to
> do it.

Sounds like a bug with your graphic driver, or possibly QtWebEngine.

Florian

-- 
https://www.qutebrowser.org  | m...@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/


signature.asc
Description: PGP signature

Re: [qutebrowser] Some feelings about v1.0

[Florian Bruhin]

On Wed, Oct 18, 2017 at 07:57:44AM -0400, Ryan Roden-Corrent wrote:
> > 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.
> 
> This depends on how you got to the url. If I navigate to example.com/foo!bar,
> that exact string will show up in my completions, and will show up with 
> ":open !". If I navigate explicitly to example.com/foo%21bar, then we will not
> automatically decode it. I think maybe we could with QURL.FullyDecoded? If so,
> do we want to? Florian?

The problem is that QUrl::FullyDecoded is lossy, so we'd need to display the
FullyDecoded variant, but store e.g. FullyEncoded in the database.

That means we'd need to introduce some way to have HistoryCategory modify the
data before it's being shown, which I bet would slow down things again.

Florian

-- 
https://www.qutebrowser.org  | m...@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/


signature.asc
Description: PGP signature

Re: [qutebrowser] Some feelings about v1.0

[José Alberto Orejuela García]

Hello,

I'm a bit late (I had a lot of work last week), but here is my answer. =)

> I think Florian addressed this one -- up/down are used for history, leaving 
> just
> tab/shift-tab for completion selection. I think this mirrors what people are
> used to from a shell.
> 
> I find I use tab for completion, alt-p/n for history, and never touch those
> annoying arrow keys :)

Yes, I agree that's the best, and now I will get used to it.

> How about  to delete the last word?

It just deletes everything if it's an URL or something like seem to be a word.

> So something like vim's completeopt=longest? That is, complete the longest
> substring of the available completions? I could see this being useful for 
> things
> like settings. It seems nearly useless for URL's though. I almost never type
> `:open http://`, but without that, you wouldn't be matching anything by a 
> prefix
> plus you'd miss out on https://, ect. I'm not sure I'd want to implement
> different completion behaviors for different completion types, but it isn't a
> bad suggestion.

I only said it because I felt I was missing something like that, but they were 
settings sections, and I agree with how it's done now (see next answer).

> I was one of the ones who pushed for this change. I could never seem to 
> remember
> what section a given option belonged in. Is "User-Agent" general or network?
> What about "private-browsing"? I frequently had to try several sections. Now I
> just type ":set user_agent" and it completes to "content.headers.user_agent".

Yes, yes, I completely agree on that, I had to try several sections as well to 
find things. The point is that I was missing that and I didn't realise, but I 
prefer it as it is right now.

> FWIW, there is a more detailed explanation here:
> https://github.com/qutebrowser/qutebrowser/blob/master/doc/help/configuring.asciidoc#migrating-older-configurations

Ah, great, thanks. =)

> Sorry, that was poorly worded on my part, I wasn't blaming you. That was more
> of a general statement.

OK. =)

> Yes - if you filter for ! in e.g. the setting value completion or whatever, 
> you
> wouldn't expect qutebrowser to filter for %21.

But the point is that it doesn't matter as there won't be strings like that in 
settings, don't you think?

> Kind of - sections just don't exist anymore, because they made both the code
> and using :set (as you needed to know what section something was in) more
> complicated.
>
> That does indeed mean qute://settings is a bit less organized now, but I'm not
> sure what to do about that.

Well, they could be split using the parts between full stops, but I think it's 
not worth it.

By the way, I also find the browser more slow when scrolling, is that due to 
qtwebengine as well?

I also have 2 issues more:

- Sometimes, when I use hints to go to a form box to fill it, it doesn't enter 
insert mode (and if I enter insert mode manually with "i", nothing is written 
as I type). I will find a concrete example in a page (I forgot to write it down 
when it happened) and send it, so you can skip this by now until I find a place 
to reproduce it.

- Randomly, qutebrowser seems to get stuck but it's not, it's only the 
graphical part. For example, if I open a new tab (it should focus on it as 
that's the usual case), I keep seeing the same in the window (except that I can 
see that page title is different, as if I were on the new tab); I can even 
click on other tabs and see that page title changes, but not the content or 
tabs bar, those are frozen, even though I can click on them and I can see that 
they're interacting. If I minimise the window and then restore it, everything 
is fixed; BUT sometimes, before I can minimise it, it gets all graphics in the 
computer stucked and I see a notification like "desktop effects were restored 
due to a graphic problem" (I'm using plasma on Arch). I guess this will be hard 
to debug, so if I can help in any way, I'm willing to do it.

Regards,

José Alberto


On miércoles, 18 de octubre de 2017 13:57:44 (CEST) Ryan Roden-Corrent wrote:
> Hi José!
> 
> Thanks for the great email, there's lots of clear, constructive feedback here.
> 
> > Default behaviour for moving between completions is tab or shift-tab. 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? 
> 
> I think Florian addressed this one -- up/down are used for history, leaving 
> just
> tab/shift-tab for completion selection. I think this mirrors what people are
> used to from a shell.
> 
> I find I use tab for completion, alt-p/n for history, and never touch those
> annoying arrow keys :)
> 
> > 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
> > 

Re: [qutebrowser] Some feelings about v1.0

[Florian Bruhin]

Hi,

On Tue, Oct 17, 2017 at 08:39:38PM +, José Alberto Orejuela García wrote:
> > 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.
> 
> Yes, I also liked it, the point is that I didn't know it was that. Maybe you
> put it in the changelog and I missed that part (I usually read them), sorry.
> =P

I did indeed forget to put it in the original changelog and then added it a bit
later, so that might be me to blame ;-)

FWIW, there is a more detailed explanation here:
https://github.com/qutebrowser/qutebrowser/blob/master/doc/help/configuring.asciidoc#migrating-older-configurations

> > Can't please everyone I guess, but I'm tired of the bikeshedding[1] :P
> > 
> > [1] https://shed.bike/
> 
> I was only asking for understanding, not trying to demand anything. I'm sorry
> about making you feel like that.

Sorry, that was poorly worded on my part, I wasn't blaming you. That was more
of a general statement.

> > Also, it introduces special completion matching only applicable to :open, 
> > which
> > is another thing I'd like to avoid.
> 
> You could implement it everywhere, do you thing it will lead to problems with
> other commands?

Yes - if you filter for ! in e.g. the setting value completion or whatever, you
wouldn't expect qutebrowser to filter for %21.

> > > - 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.
> 
> Yes, I have just realised why I was thinking about that. The point is that
> settings were split in sections before, so I could hit tab step by step to
> complete, and that was (I think) what I was missing subconsciously.
> 
> Also, that led to a qute://settings page split in sections, tidier than the
> new one (it's a minor thing, of course). Is that intentional?

Kind of - sections just don't exist anymore, because they made both the code
and using :set (as you needed to know what section something was in) more
complicated.

That does indeed mean qute://settings is a bit less organized now, but I'm not
sure what to do about that.

Florian

-- 
https://www.qutebrowser.org  | m...@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/


signature.asc
Description: PGP signature

Re: [qutebrowser] Some feelings about v1.0

[José Alberto Orejuela García]

Hello,

On Tuesday, October 17, 2017 8:40:08 PM CEST Florian Bruhin wrote:
> Hey,
> 
> On Tue, Oct 17, 2017 at 05:51:27PM +, 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 ;-)

That was the intention. I really appreciate your work and I like all the new 
features. =D

> > - Default behaviour for moving between completions is tab or shift-tab.
> 
> FWIW that's been the case since the completion existed.

Well, I meant that it's now the only way to do it.

> > 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's a good feature, I like that reason for making the effort of getting used 
to that new behaviour for me (new because I'm completely used to navigate with 
arrows through completion).

> 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.

Yes, I also liked it, the point is that I didn't know it was that. Maybe you 
put it in the changelog and I missed that part (I usually read them), sorry. =P

> Can't please everyone I guess, but I'm tired of the bikeshedding[1] :P
> 
> [1] https://shed.bike/

I was only asking for understanding, not trying to demand anything. I'm sorry 
about making you feel like that.

> > - 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.

Yes, that's the case, I know, I was just wondering about the order. As you 
said, let's wait for rcorre comments.

> > 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 ;-)

OK, let's see. If you think that's not convenient, I trust you. =P 
Unfortunately, I cannot contribute to the code. I hope I'll be able somewhen.

> > - 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 ;-)

On this topic, in my opinion it's not consistent now. I can type an url with a 
bang and I see it at the bottom right, at the url displayed, but I have to 
remember that I should type %21 to find it (the problem is more about other 
characters, not specially !, it's just an example).

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

You could implement it everywhere, do you thing it will lead to problems with 
other commands?

> > - 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 

Re: [qutebrowser] Some feelings about v1.0

[Lukas Gierth]

Hi Jose,

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.

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.

Anyhow, thanks to Florian and all the other contributers for their hard
work!

Greetings,
Lukas

On Tue, Oct 17, 2017 at 05:51:27PM +, José Alberto Orejuela García wrote:

Hi,

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.

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:

- Default behaviour for moving between completions is tab or shift-tab. 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? I think it was default behaviour 
before, but maybe I changed it in settings long time ago and I don't 
remember... =P

- 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?

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.
- 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.
- 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.


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.

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. =)

Regards,

José Alberto

[qutebrowser] Some feelings about v1.0

[José Alberto Orejuela García]

Hi,

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.

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:

- Default behaviour for moving between completions is tab or shift-tab. 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? I think it was default behaviour 
before, but maybe I changed it in settings long time ago and I don't 
remember... =P

- 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?

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.
- 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.
- 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.


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.

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. =)

Regards,

José Alberto