This adds the ability to open new tabs in the last-focused window
instead, which fixes#1801.
Right now the only other option is probably not that useful for human
users but it's required to make tests behave deterministically and
consistently. (But with #881 on the roadmap, I would implement this as
another choice)
To this end, also make the test framework set this option to preserve
the invariant against which existing tests are written: that spawning a
new window would effectively also focus it.
This was currently almost completely broken, yet nobody complained. The
new behavior (in the previous commit) makes this always hide the mouse
cursor, even when an input field has focus.
Since the only two easy options to implement are "never hide" and
"always hide", combined with the fact that both are sort of useless to
an end-user, just remove the option until somebody wants it back.
Right now, get('last-focused-main-window') essentially returns the same
as qApp.activeWindow(), since it's None when no window is focused. This
seems somewhat contrary to its original intent, so I've changed it to
only ever update the object.
This actually fixes another bug as well: on_focus_changed's new is not
always a MainWindow - in fact it's a WebView on my end. To fix this,
directly use the QApplication.activeWindow() to find the current focus.
That second bit in particular actually some related bugs that probably
nobody ever noticed or bothered reporting:
* _maybe_hide_mouse_cursor currently pretty much never gets called
* :adblock-update doesn't actually show any downloads
* ... probably more
This allows a specific keybinding, for whatever reason, to override the
default mode. Examples of when this could be useful:
* :hint --rapid --mode=word (to type them more rapidly)
* :hint --mode=letter input (if the default mode is number)
Also reword the description of 'group' to make the distinction between
'group' and 'mode' clearer.
We set PYTHONPATH so we can import qutebrowser.app in run_vulture.py
without installing it.
We also need to make sure all dependencies are installed so we can
actually import qutebrowser.
Since we now use QWebEngineScript, we can't easily know when the script
finished running and we can access window._qutebrowser.scroll.
We instead assume the initial position (if we don't get a
scrollPositionChanged) will always be (0, 0), and explicitly set it
to (None, None) (displaying ???) if we can't connect that signal.
We now load the JS code as a QWebEngineScript, which sets up
window._qutebrowser with various "modules". That means we don't have to
pass the whole module every time we want to execute something.
- *Major packrat upgrade*, inspired by patch provided by Tal Einat -
many, many, thanks to Tal for working on this! Tal's tests show
faster parsing performance (2X in some tests), *and* memory reduction
from 3GB down to ~100MB! Requires no changes to existing code using
packratting. (Uses OrderedDict, available in Python 2.7 and later.
For Python 2.6 users, will attempt to import from ordereddict
backport. If not present, will implement pure-Python Fifo dict.)
- Minor API change - to better distinguish between the flexible
numeric types defined in pyparsing_common, I've changed "numeric"
(which parsed numbers of different types and returned int for ints,
float for floats, etc.) and "number" (which parsed numbers of int
or float type, and returned all floats) to "number" and "fnumber"
respectively. I hope the "f" prefix of "fnumber" will be a better
indicator of its internal conversion of parsed values to floats,
while the generic "number" is similar to the flexible number syntax
in other languages. Also fixed a bug in pyparsing_common.numeric
(now renamed to pyparsing_common.number), integers were parsed and
returned as floats instead of being retained as ints.
- Fixed bug in upcaseTokens and downcaseTokens introduced in 2.1.5,
when the parse action was used in conjunction with results names.
Reported by Steven Arcangeli from the dql project, thanks for your
patience, Steven!
- Major change to docs! After seeing some comments on reddit about
general issue with docs of Python modules, and thinking that I'm a
little overdue in doing some doc tuneup on pyparsing, I decided to
following the suggestions of the redditor and add more inline examples
to the pyparsing reference documentation. I hope this addition
will clarify some of the more common questions people have, especially
when first starting with pyparsing/Python.
- Deprecated ParseResults.asXML. I've never been too happy with this
method, and it usually forces some unnatural code in the parsers in
order to get decent tag names. The amount of guesswork that asXML
has to do to try to match names with values should have been a red
flag from day one. If you are using asXML, you will need to implement
your own ParseResults->XML serialization. Or consider migrating to
a more current format such as JSON (which is very easy to do:
results_as_json = json.dumps(parse_result.asDict()) Hopefully, when
I remove this code in a future version, I'll also be able to simplify
some of the craziness in ParseResults, which IIRC was only there to try
to make asXML work.
- Updated traceParseAction parse action decorator to show the repr
of the input and output tokens, instead of the str format, since
str has been simplified to just show the token list content.
(The change to ParseResults.__str__ occurred in pyparsing 2.0.4, but
it seems that didn't make it into the release notes - sorry! Too
many users, especially beginners, were confused by the
"([token_list], {names_dict})" str format for ParseResults, thinking
they were getting a tuple containing a list and a dict. The full form
can be seen if using repr().)
For tracing tokens in and out of parse actions, the more complete
repr form provides important information when debugging parse actions.
