python 2.7.13
=============
- [x] Have you followed the [guidelines for contributing](https://github.com/Homebrew/homebrew-core/blob/master/CONTRIBUTING.md)?
- [x] Have you checked that there aren't other open [pull requests](https://github.com/Homebrew/homebrew-core/pulls) for the same formula update/change?
- [x] Have you built your formula locally with `brew install --build-from-source <formula>`, where `<formula>` is the name of the formula you're submitting?
- [x] Does your build pass `brew audit --strict <formula>` (after doing `brew install <formula>`)?
-----
I'm updating setuptools, pip and wheel to the latest versions. Also pulling out the embedded tk patch into formula-patches (https://github.com/Homebrew/formula-patches/pull/97), because it makes the formula cleaner. Let me know if you want it back.
Miscellaneous improvements
==========================
- Add -V, --version option (standard stuff);
- Reorder options in completion defs according to help text, so that checking whether any option's missing is easier;
- Add Debian and Ubuntu availability badges (can't give a version, so just point out which distro releases googler is available on, and link to respective package search pages).
We may want to cut a release some time soon.
> if we set n and p we can't search a keyword starting using n and p.
Not sure what that means. You can certainly search keywords starting with n or p. The only prohibited keywords are the letters n and p and other commands, verbatim, which are not very useful keywords to begin with.
You can figure out the raw input sequences arrow keys represent (if you ditch readline, otherwise they'll just be captured), but using arrow keys (or ^P, ^N, etc.) for control doesn't sound right outside curses.
> Also I' assuming that we didn't add this to omniprompt help because we show the message explicitly.
Yes, just like unfilter. The longer the help the less likely it is going to be read.
Major changes are required to get this to work because the a tags don't have classes.
1. Need to start from span, and register a custom set of handlers;
2. Need to distinguish between the two cases and pass around more states;
3. More complexity at printing stage.
I don't feel like handling this case. More results doesn't hurt (and this should only happen when the the quality of the results for the original keywords isn't good), unlike results about something else.
> "Including results for navy Search only for nevy"
When I search for nevy I only get results for nevy... Need the HTML from debug. I'll take a look tomorrow.
> Do you think it's reasonable to handle all these cases or leave it to the user to correct in the omniprompt... now that we have cmdline arg correction in place?
Not sure without digging in, but I dont' think including extra results hurt, and not showing auto-correction info in this case is at least justifiable.
Just realized I pasted the wrong demo link...
https://asciinema.org/a/2veowecoo2hpznua9k1bgsnxj
The query above (demonstrating the quoting dilemma) is shown there.
> I checked the changes in regular as well as --noua mode. Both show same results with auto-correction warning. What's not working with --noua (you mentioned something)?
The code as I initially wrote it (following my understanding of the structure of that block, as documented in the new parser comments) didn't work under --noua, because the block's structure is different under --noua. See the added note under "User Agent disabled (differences)".
I have accounted for the difference, so the code works in whatever environment (hopefully).
> Also, how about highlighting the corrected spelling? At least within quotes?
I don't think we [have a suitable color for it](https://github.com/jarun/googler#colors) so coloring isn't an option. I thought about quotes but rejected that idea, because
```
$ googler -n 3 \"googler news\"
Showing results for "google news"; enter "exact" for an exact search.
1 Google News
https://news.google.com/
Comprehensive up-to-date news coverage, aggregated from sources all over the world by Google News.
2 Google News & Weather on the App Store - iTunes - Apple
https://itunes.apple.com/us/app/google-news-weather/id913753848?mt=8
Oct 3, 2016 - Your comprehensive and personalized view of headline stories and local news & weather. ° Coverage from
75,000 publications ◦ Instant-load ...
3 Google News - Mashable
http://mashable.com/category/google-news/
Google is killing Reader tomorrow, and as a sort of consolation prize, they've added some new features to Google
News. There's now a box that features a ...
googler (? for help) q
```
> just trying to keep it low if we can.
I'm afraid we can't optimize here. There's a bit of nickle and diming you can do in the conditions at the cost of overall consistency in the code base. Not much you can do otherwise in a linear search for a bunch of things in rather hostile, poorly structured input.
To truly improve the sensitivity to one added condition, what you can do is scan the tree once, cache the results in some sort of search tree(s), then select with logarithmic (or better) complexity. It would be super hardcore though, and whether it will actually save time is questionable for what we do. I checked bs4 source code and it's simply doing a linear traversal for finding and selector queries; see [here](https://git.launchpad.net/~vivekchandola/beautifulsoup/+git/trunk/tree/library/bs4/element.py#n1296) and [here](https://git.launchpad.net/~vivekchandola/beautifulsoup/+git/trunk/tree/library/bs4/element.py#n1518). I don't know how JavaScript folks implement CSS selector queries (`querySelectorAll` and simple special cases).
Anyway, this consideration is not very helpful, since processing time is dwarfed by I/O.
> Doesn't this condition alone indicate auto-correction?
It doesn't. See parser docs:
```
# 1. When npfr=1 (exact), there could still be an
# a.spell, in a block that reads (English version) "Did you mean:
# ...". Therefore, we only consider the query autocorrected when a
# meaningful .spell_orig is also present (self.autocorrected).
```
> we do around 7000 pattern matches and 800+ tag parsing for a page on an average.
I recall a benchmark earlier demonstrating that I/O is the real bottleneck.
Addressed comments.
> we have ample scope to optimize our parser if we use elif
As mentioned in an inline comment, because we always return from if bodies, using elif hardly ever helps. Also, the conditions are seldom mutually exclusive (if ever), at a glance.
This "exact" command is like a poor man's version of the originally planned dynamic option manipulation (for the single option `--exact`). Just saying.
Improve autocorrect handling: detect autocorrected query and add a prompt command "exact"
=========================================================================================
Details are in commit messages and additions to parser docs. This PR should be considered on a commit-by-commit basis, and each of the latter two commits (cdfe3d0 and ac6e13c) is optional, although I think they are worthy improvements.
Demo: https://asciinema.org/a/2veowecoo2hpznua9k1bgsnxj.
Closes #154.