Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed default search engines. Closes #533. #542

Merged
merged 1 commit into from Mar 11, 2015

Conversation

error800
Copy link
Contributor

@error800 error800 commented Mar 11, 2015

This change is Reviewable

@The-Compiler
Copy link
Member

Not sure what to think about this. It should be possible to remove those search engines by setting it to an empty value, though that seems to be broken... Whoops! 😊

But I'd still like to ship a minimal useful set of default search engines, especially ddg so something like :open ddg QWebView::load still works.

I suggest keeping them for now, and fixing this properly with the big config revolution at #499. Other opinions? /cc @oed

I'll take a look at why :set searchengines ddg "" doesn't work later today.

@oed
Copy link
Contributor

oed commented Mar 11, 2015

I agree, it's not that important right now. No real reason to do anything before the switch to yaml.

@error800
Copy link
Contributor Author

It doesnt work because {} is expected in the searchengine string. And if i set google = {}, searching for 'google sucks' tries to open http://sucks :/

@drlight-code
Copy link
Contributor

But I'd still like to ship a minimal useful set of default search engines, especially ddg so something like :open ddg QWebView::load still works.

I suggest keeping them for now, and fixing this properly with the big config revolution at #499. Other opinions? /cc @oed

Well I think that having the DEFAULT should actually be sufficient.
That :: problem when not typing an engine explicitly actually
occured to me several times already. I expected to be able to just
paste it into :open. What exactly are those :: links anyways, is
that a standard URI form for external applications? Maybe we can
parse/qualify it somehow differently to make searching for scoped C+

  • symbols work as expected?

Patric Schmitz bzk0711@aol.com

@error800
Copy link
Contributor Author

I've kept duckduckgo as the DEFAULT search engine. Thats enough I think. Custom search strings should be the choice of the user imo.

@The-Compiler
Copy link
Member

What exactly are those :: links anyways, is that a standard URI form for external applications? Maybe we can parse/qualify it somehow differently to make searching for scoped C++ symbols work as expected?

QUrl parses foo::bar as a valid URL with foo as scheme and :bar as path. I'm not sure if this is something sensible to do according to the URL standard. I guess qutebrowser.urlutils.is_url should handle this as a special case, and maybe a Qt bug should be submitted if this is invalid according to RFC3986 and the WHATWG living URL standard? Do you want to look at this, @flvi0?

I've kept duckduckgo as the DEFAULT search engine. Thats enough I think. Custom search strings should be the choice of the user imo.

I still think qutebrowser should offer some sensible defaults for configs, like e.g. for the ad block lists as well. As said, currently you should be able to remove entries by setting them to an empty URL (will look at why this is broken this evening), and with #499 I've to think about how to handle default values in general. But this is just a quick workaround for a debatable topic, so I'm closing this - sorry!

@The-Compiler
Copy link
Member

After talking with @flvi0 a bit I got conviced this actually might be a good idea indeed. I'll reopen and merge. Sorry for the hassle!

@The-Compiler The-Compiler reopened this Mar 11, 2015
@The-Compiler The-Compiler merged commit 94666fe into qutebrowser:master Mar 11, 2015
@error800
Copy link
Contributor Author

yay, thanks! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants