The CommandRunner's fallback parsing behavior treated whitespace
differently than the normal flow. When a user entered an unknown
command, trailing whitespace would be stripped and the cmdline length
would be less than the cursor position.
This is fixed by making the fallback use the ShellLexer just as the
'normal' parsing does.
When the commandline reads ':open |', quick-completing the only offered
completion will set the commandline to ':open some_url |'. Since `open`
has `maxsplit=0`, everything after ':open' is (correctly) treated as
one argument. This means completion is opened again with 'some url '
as the pattern (note trailing whitespace), which makes the comletion
menu 'flicker' and stay open even though it was 'supposed' to quick
compelte.
This is fixed by ignoring the next completion request if we just
completed something after maxsplit (because we don't expect any more
completions after the last split).
Resolves#1519.
After the refactoring, _split is only called by _partition so just make
it part of the same method. This also removes the use of
_empty_item_index, as it can be figured out on the fly.
Remove the class variables _cursor_part and _empty_item_index. Instead,
split up the commandline around the cursor whenever that information is
needed. Using locals instead of class variables makes the logic easier
to follow and ends up requiring much less code.
Remove the dependency on the class variables _empty_item_index
and _cursor_part to make the code easier to follow. If
_update_completion is refactored in a similar way these variables can
be removed.
The test was flaky because waiting for scrolling didn't actually wait,
as the page logged a scroll position change to 0/0 directly after
loading.
We work around this by making the generic "And I wait until the scroll
position changed" not wait when it changed to 0/0.
With QtWebEngine, inserting text into the field is async, so if our
test runs too fast, it would fail. Now we instead log stuff via JS on
changes insteaad, and wait for those log messages in the tests.
We had some funny segfaults reported during scrolling (i.e. with
QApplication.sendEvent), and some code already had to use postpone=True
so there was no segfault...
So now we're back to postEvent again, and eliminated the main reason for
segfaults with it, which was re-using (and -posting) events which had
already been posted.
At least during tests this seems to run stable, let's hope it helps for
the people having crashes as well.
