From trevor.robertson55 at gmail.com Fri Oct 6 11:22:30 2017 From: trevor.robertson55 at gmail.com (Trevor Robertson) Date: Fri, 6 Oct 2017 11:22:30 +0200 Subject: [qutebrowser] Updating Message-ID: Hi ... What is the best way to update Qutebrowser to a newer version? I currently have 0.10.1 on Windows 10 Home that I installed manually, on my home PC. Maybe I'm overlooking an update button or command. If I simply download & install it again: Must I uninstall the old one first? Or is one of the command-line focused installation methods that you list for Windows the nicest one for frequent updating. Most important: Will my {custom keybindings} and {bookmarks} be kept? Say if I should I rather ask such questions on Freenote Webchat. .... I would just like to be able to read your replies at work too; We can access gmail at work but not Freenode. Thanks so much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From trevor.robertson55 at gmail.com Fri Oct 6 12:03:43 2017 From: trevor.robertson55 at gmail.com (Trevor Robertson) Date: Fri, 6 Oct 2017 12:03:43 +0200 Subject: [qutebrowser] Updating In-Reply-To: References: Message-ID: Or maybe I just cannot find the web page that discusses it... On 6 October 2017 at 11:22, Trevor Robertson wrote: > Hi ... What is the best way to update Qutebrowser to a newer version? I > currently have 0.10.1 on Windows 10 Home that I installed manually, on my > home PC. > Maybe I'm overlooking an update button or command. If I simply download & > install it again: Must I uninstall the old one first? > Or is one of the command-line focused installation methods that you list > for Windows the nicest one for frequent updating. > > Most important: Will my {custom keybindings} and {bookmarks} be kept? > > Say if I should I rather ask such questions on Freenote Webchat. .... I > would just like to be able to read your replies at work too; We can access > gmail at work but not Freenode. > > Thanks so much! > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Fri Oct 6 14:27:06 2017 From: me at the-compiler.org (Florian Bruhin) Date: Fri, 6 Oct 2017 14:27:06 +0200 Subject: [qutebrowser] Updating In-Reply-To: References: Message-ID: <20171006122706.rjnqdxjleols2pii@hooch.localdomain> Hey Trevor, On Fri, Oct 06, 2017 at 09:22:30AM +0000, Trevor Robertson wrote: > Hi ... What is the best way to update Qutebrowser to a newer version? I > currently have 0.10.1 on Windows 10 Home that I installed manually, on my > home PC. > Maybe I'm overlooking an update button or command. If I simply download & > install it again: Must I uninstall the old one first? Copy and pasting from a mail I sent to someone off-list recently: Right, there is no updater. The reason is that doing this kind of thing right is really difficult, both from a security perspective (see e.g. 1.5.2 at https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.md ) and from a functionality perspective (with all the different OS' and ways of installing qutebrowser supports). I might take a look at it some day, but it's probably quite some effort benefiting a fraction of the userbase (most people are on Linux with a package manager), so it's really not a priority. You don't need to uninstall the old version, the installer should take care of it automatically. I added a note to the docs: https://github.com/qutebrowser/qutebrowser/commit/0d8edd54fbb0bfa4b846ec8da1b57bd1132ca30e > Or is one of the command-line focused installation methods that you list > for Windows the nicest one for frequent updating. You might want to try Chocolatey: https://chocolatey.org/packages/qutebrowser You'll still need to tell Chocolatey to update packages manually I think, but it'll take care of upgrading everything you manage with it. I don't have any personal experience with the qutebrowser package though, and it's been some years since I last used Chocolatey (I'm not using Windows regularily anymore). However, the maintainer seems to take great care of the package and updates so far. > Most important: Will my {custom keybindings} and {bookmarks} be kept? They should be, yes. However, v1.0.0 will come out soon-ish which has a completely new config system, so you'll need to reconfigure things once upgrading to that. This is a one-time thing though. > Say if I should I rather ask such questions on Freenote Webchat. .... I > would just like to be able to read your replies at work too; We can access > gmail at work but not Freenode. Don't worry, the mailinglist is fine. 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: From trevor.robertson55 at gmail.com Fri Oct 6 15:54:39 2017 From: trevor.robertson55 at gmail.com (Trevor Robertson) Date: Fri, 6 Oct 2017 15:54:39 +0200 Subject: [qutebrowser] fonts on web Message-ID: Hi, just for interest (I'll try not to use this mailing list *too* much!): Is there a reason why certain websites don't mix their fonts so nicely (large vs small) e.g. the page below. Or does the reason lie more on the web design side than the browser. (On my tablet I see this site mixes the fonts better on Dolphin browser than Chrome.) http://pandas.pydata.org/pandas-docs/stable/indexing.html#special-use-of-the-operator-with-list-objects [image: Inline images 1] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 15652 bytes Desc: not available URL: From me at the-compiler.org Fri Oct 6 16:27:57 2017 From: me at the-compiler.org (Florian Bruhin) Date: Fri, 6 Oct 2017 16:27:57 +0200 Subject: [qutebrowser] fonts on web In-Reply-To: References: Message-ID: <20171006142757.mhxkvio4ofl6vaou@hooch.localdomain> On Fri, Oct 06, 2017 at 01:54:39PM +0000, Trevor Robertson wrote: > Hi, just for interest (I'll try not to use this mailing list *too* much!): > Is there a reason why certain websites don't mix their fonts so nicely > (large vs small) > e.g. the page below. Or does the reason lie more on the web design side > than the browser. > (On my tablet I see this site mixes the fonts better on Dolphin browser > than Chrome.) Font rendering is still mostly a black box to me. The website doesn't seem to specify anything special for 
 tags (the monospaced part) here.

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: 

From me at the-compiler.org  Mon Oct  9 09:20:48 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 9 Oct 2017 09:20:48 +0200
Subject: [qutebrowser] qutebrowser v0.11.1 released!
Message-ID: <20171009072048.s3532hkqjwzhlktb@hooch.localdomain>

Hi,

I'm happy to announce that qutebrowser v0.11.1 has been released.
This just has a handful of small fixes compared to v0.11.0:

- Fixed empty space being shown after tabs in the tabbar in some cases.
- Fixed :restart in private browsing mode.
- Fixed printing on macOS.
- Closing a pinned tab via mouse now also prompts for confirmation.
- The "try again" button on error pages works correctly again.
- :spawn -u -d is now disallowed.
- :spawn -d shows error messages correctly now.

This will be the last release on the v0.11.x branch.

----------------

The next release (possibly already this week) will be v1.0.0 with many breaking
changes:

- The new config system
- The new completion, based on sqlite
- Dropping legacy support (old Qt/QtWebKit/Python versions)
- Making QtWebEngine the default backend

(Note that I decided per-domain settings won't be part of v1.0.0, to get the
new config out to people ASAP - but it'll come in v1.1.0!)

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: 

From me at the-compiler.org  Thu Oct 12 10:57:03 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 12 Oct 2017 10:57:03 +0200
Subject: [qutebrowser] qutebrowser v1.0.0 released!
Message-ID: <20171012085703.2ghl76w6p474ptz4@hooch.localdomain>

Hey,

I'm delighted to announce that I just released qutebrowser v1.0.0!

jhis release comes with many big breaking changes such as the new config and
QtWebEngine by default, so please take a look at the changelog.

As announced previously, per-domain settings unfortunately didn't make it into
v1.0.0 - it's the next thing I plan on tackling. However, there's more than
enough big things in v1.0.0! :)

Enjoy!

Florian

Major changes
~~~~~~~~~~~~~

- Dependency changes:
  * Support for legacy QtWebKit (before 5.212 which is distributed
    independently from Qt[1] is dropped.
  * Support for Python 3.4 is dropped.
  * Support for Qt before 5.7.1 and PyQt before 5.7 is dropped.
  * New dependency on the QtSql module and Qt sqlite support.
  * New dependency on the attrs[2] project (packaged as `python-attr` in some
    distributions).
  * The depedency on PyOpenGL (when using QtWebEngine) got removed. Note
    that PyQt5.QtOpenGL is still a dependency.
  * PyQt5.QtOpenGL is now always required, even with QtWebKit.
- The QtWebEngine backend is now used by default. Note this means that
  QtWebEngine now should be a required dependency, and QtWebKit (if new enough)
  should be changed to an optional dependency.
- Completely rewritten configuration system which ignores the old config file.
  See link:qute://help/configuring.html[] for details.
- Various documentation files got moved to the doc/ subfolder;
 `qutebrowser.desktop` got moved to misc/.
- `:set` now doesn't support toggling/cycling values anymore, that functionality
  got moved to `:config-cycle`.
- New completion engine based on sqlite, which allows to complete
  the entire browsing history. The default for
  `completion.web_history_max_items` got changed to `-1` (unlimited). If the
  completion is too slow on your machine, try setting it to a few 1000 items.

[1] https://github.com/annulen/webkit/wiki
[2] http://www.attrs.org/

Added
~~~~~

- QtWebEngine: Spell checking support, see the `spellcheck.languages` setting.
- New `qt.args` setting to pass additional arguments to Qt/Chromium.
- New `backend` setting to select the backend to use.
  Together with the previous setting, this should make most wrapper scripts
  unnecessary.
- qutebrowser can now be set as the default browser on macOS.
- New config commands:
  * `:config-cycle` to cycle an option between multiple values.
  * `:config-unset` to remove a configured option.
  * `:config-clear` to remove all configured options.
  * `:config-source` to (re-)read a `config.py` file.
  * `:config-edit` to open the `config.py` file in an editor.
  * `:config-write-py` to write a `config.py` template file.
- New `:version` command which opens `qute://version`.
- New back/forward indicator in the statusbar.
- New `bindings.key_mappings` setting to map keys to other keys.
- QtWebEngine: Support for proxy authentication.

Changed
~~~~~~~

- Using `:download` now uses the page's title as filename.
- Using `:back` or `:forward` with a count now skips intermediate pages.
- When there are multiple messages shown, the timeout is increased.
- `:search` now only clears the search if one was displayed before, so pressing
  `` doesn't un-focus inputs anymore.
- Pinned tabs now adjust to their text's width, so the `tabs.width.pinned`
  setting got removed.
- `:set-cmd-text` now has a `--run-on-count` argument to run the underlying
  command directly if a count was given.
- `:scroll-perc` got renamed to `:scroll-to-perc`.

Removed
~~~~~~~

- Migrating QtWebEngine data written by versions before 2016-11-15 (before
  v0.9.0) is now not supported anymore.
- Upgrading qutebrowser with a version older than v0.4.0 still running now won't
  work properly anymore.
- The `--harfbuzz` and `--relaxed-config` commandline arguments got dropped.

Fixes
~~~~~

- Exiting fullscreen via `:fullscreen` or buttons on a page now
  restores the correct previous window state (maximized/fullscreen).
- When `input.insert_mode.auto_load` is set, background tabs now don't enter
  insert mode anymore.
- The keybinding help widget now works correctly when using keybindings with a
  count.
- The `window.hide_wayland_decoration` setting now works correctly again.

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

From me at the-compiler.org  Fri Oct 13 09:50:48 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Fri, 13 Oct 2017 09:50:48 +0200
Subject: [qutebrowser] qutebrowser v1.0.1 released!
In-Reply-To: <20171012085703.2ghl76w6p474ptz4@hooch.localdomain>
References: <20171012085703.2ghl76w6p474ptz4@hooch.localdomain>
Message-ID: <20171013075048.cniq7jzbbhz4hzw7@hooch.localdomain>

Hey,

since v1.0.0 had two bugs preventing qutebrowser from starting in some
scenarios, I just released v1.0.1:

- Fixed starting after customizing fonts.tabs or fonts.debug_console.
- Fixed starting with old PyQt versions compiled against newer Qt versions.
- Fixed check for PyQt version to correctly enforce 5.7 (not 5.2).

I hope the release frequency will go down a bit now... :D

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: 

From me at the-compiler.org  Tue Oct 17 07:57:52 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 17 Oct 2017 07:57:52 +0200
Subject: [qutebrowser] qutebrowser v1.0.2 released!
In-Reply-To: <20171013075048.cniq7jzbbhz4hzw7@hooch.localdomain>
References: <20171012085703.2ghl76w6p474ptz4@hooch.localdomain>
 <20171013075048.cniq7jzbbhz4hzw7@hooch.localdomain>
Message-ID: <20171017055752.o57opukeblg2v6ta@hooch.localdomain>

Hey,

Another week, another release! :D

I just released v1.0.2, fixing some more issues:

- Fix workaround for black screens or crashes with Nvidia cards
- Handle a filesystem going read-only gracefully
- Fix crash when setting fonts.monospace
- Fix list options not being modifyable via .append() in config.py
- Mark the content.notifications setting as QtWebKit only correctly
- Fix wrong rendering of keys like  in the completion
- Nicer error messages and other minor improvements

The source release and macOS are up, Windows is still building but hopefully up
by the time you're reading this. The .deb gets updated manually, but will
probably follow later today.

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: 

From jose.gif at hotmail.com  Tue Oct 17 19:51:27 2017
From: jose.gif at hotmail.com (=?iso-8859-1?Q?Jos=E9_Alberto_Orejuela_Garc=EDa?=)
Date: Tue, 17 Oct 2017 17:51:27 +0000
Subject: [qutebrowser] Some feelings about v1.0
Message-ID: 

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


From lukas.gierth at mailbox.org  Tue Oct 17 20:02:12 2017
From: lukas.gierth at mailbox.org (Lukas Gierth)
Date: Tue, 17 Oct 2017 20:02:12 +0200
Subject: [qutebrowser] Some feelings about v1.0
In-Reply-To: 
References: 
Message-ID: <20171017180212.t6nccqzl2rdpnabm@mailbox.org>

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 +0000, 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


From me at the-compiler.org  Tue Oct 17 20:40:08 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 17 Oct 2017 20:40:08 +0200
Subject: [qutebrowser] Some feelings about v1.0
In-Reply-To: 
 <20171017180212.t6nccqzl2rdpnabm@mailbox.org>
Message-ID: <20171017184008.rxzu3onuaicoolkr@hooch.localdomain>

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: 

From jose.gif at hotmail.com  Tue Oct 17 22:39:38 2017
From: jose.gif at hotmail.com (=?iso-8859-1?Q?Jos=E9_Alberto_Orejuela_Garc=EDa?=)
Date: Tue, 17 Oct 2017 20:39:38 +0000
Subject: [qutebrowser] Some feelings about v1.0
In-Reply-To: <20171017184008.rxzu3onuaicoolkr@hooch.localdomain>
References: <20171017184008.rxzu3onuaicoolkr@hooch.localdomain>
Message-ID: 

Hello,

On Tuesday, October 17, 2017 8:40:08 PM CEST Florian Bruhin wrote:
> 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 ;-)

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

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

Yes, I was, and I don't want to go back, I'm tired of crashes in qtwebkit part, hahaha. If that's the price I have to pay, I'll pay. XD

Thanks a lot for your answers. =)

Jos? Alberto


From me at the-compiler.org  Wed Oct 18 06:32:29 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 18 Oct 2017 06:32:29 +0200
Subject: [qutebrowser] Some feelings about v1.0
In-Reply-To: 
References: <20171017184008.rxzu3onuaicoolkr@hooch.localdomain>
 
Message-ID: <20171018043229.khmzwygfg7bqhtuj@hooch.localdomain>

Hi,

On Tue, Oct 17, 2017 at 08:39:38PM +0000, 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  | 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: 

From ryan at rcorre.net  Wed Oct 18 13:57:44 2017
From: ryan at rcorre.net (Ryan Roden-Corrent)
Date: Wed, 18 Oct 2017 07:57:44 -0400
Subject: [qutebrowser] Some feelings about v1.0
In-Reply-To: <20171018043229.khmzwygfg7bqhtuj@hooch.localdomain>
References: <20171017184008.rxzu3onuaicoolkr@hooch.localdomain>
 
 <20171018043229.khmzwygfg7bqhtuj@hooch.localdomain>
Message-ID: <20171018115744.GA5551@zen-arch>

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

I'm calling this a bug. They are sorted initially but we lose sorting when you
filter. I created https://github.com/qutebrowser/qutebrowser/issues/3156 to
track.

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

How about  to delete the last word?

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

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

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.

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

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

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

Thank YOU for writing this email. We can't fix things we don't know about :)

- Ryan (rcorre)

On Wed 10/18/17 06:32AM, Florian Bruhin wrote:
> Hi,
> 
> On Tue, Oct 17, 2017 at 08:39:38PM +0000, 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  | 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/



From jose.gif at hotmail.com  Wed Oct 25 18:02:27 2017
From: jose.gif at hotmail.com (=?iso-8859-1?Q?Jos=E9_Alberto_Orejuela_Garc=EDa?=)
Date: Wed, 25 Oct 2017 16:02:27 +0000
Subject: [qutebrowser] Some feelings about v1.0
In-Reply-To: <20171018115744.GA5551@zen-arch>
References: <20171017184008.rxzu3onuaicoolkr@hooch.localdomain>
 <20171018043229.khmzwygfg7bqhtuj@hooch.localdomain>
 <20171018115744.GA5551@zen-arch>
Message-ID: 

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
> > 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?
> 
> I'm calling this a bug. They are sorted initially but we lose sorting when you
> filter. I created https://github.com/qutebrowser/qutebrowser/issues/3156 to
> track.
> 
> > 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.
> 
> How about  to delete the last word?
> 
> > 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?
> 
> > 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. 
> 
> 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.
> 
> > 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.
> 
> 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".
> 
> > 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. =)
> 
> Thank YOU for writing this email. We can't fix things we don't know about :)
> 
> - Ryan (rcorre)
> 
> On Wed 10/18/17 06:32AM, Florian Bruhin wrote:
> > Hi,
> > 
> > On Tue, Oct 17, 2017 at 08:39:38PM +0000, 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
> > 
> 
> 


From me at the-compiler.org  Wed Oct 25 18:53:03 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 25 Oct 2017 18:53:03 +0200
Subject: [qutebrowser] Some feelings about v1.0
In-Reply-To: <20171018115744.GA5551@zen-arch>
References: <20171017184008.rxzu3onuaicoolkr@hooch.localdomain>
 
 <20171018043229.khmzwygfg7bqhtuj@hooch.localdomain>
 <20171018115744.GA5551@zen-arch>
Message-ID: <20171025165303.y7poa6gua3as27so@hooch.localdomain>

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

From me at the-compiler.org  Wed Oct 25 20:05:15 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 25 Oct 2017 20:05:15 +0200
Subject: [qutebrowser] Some feelings about v1.0
In-Reply-To: 
References: <20171017184008.rxzu3onuaicoolkr@hooch.localdomain>
 <20171018043229.khmzwygfg7bqhtuj@hooch.localdomain>
 <20171018115744.GA5551@zen-arch>
 
Message-ID: <20171025180515.qh52725j36m7etzg@hooch.localdomain>

On Wed, Oct 25, 2017 at 04:02:27PM +0000, 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  | 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: