We already had some duplicated logic for completion/keyhint/messageview,
and plan to add prompt overlays too now - so here we refactor related
code to have a list of overlays instead, which are all
resized/positioned by the mainwindow when needed.
This also changes the size management, which gets moved into the
sizeHint of the respective overlay widgets.
This is needed when we want to display an error page after the user
requested a qute:// URL, as qute:// URLs can't access file:// content
with QtWebEngine.
Simplify the CompletionWidget/Completer interface by changing
on_selection_changed to pass the newly selected text rather than the
index of the newly selected item.
This moves the logic from Completer to CompletionWidget but simplifies
the interaction between the two and makes testing easier.
It was checking that every expected item was in the actual item list,
but not visa-versa. This meant that extra completion items could show
up without failing the test.
This caught one bad test case. Bind completion includes aliases, but
the test did not expect this.
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.
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.
Turns out re.escape also escapes spaces, so we'd need to replace '(\\ )'
groups after escaping. At this point it's easier to just combine spaces
before escaping the pattern.
Fixes#1934.
Supersedes #1935.
On Windows, no echo.exe exists normally, so calling echo from the tests
is no good idea, since it relies on Cygwin to be installed and in %PATH%
(so that echo.exe is available).
This fixes this by providing a small echo.bat which is callable from the
tests, and then using a platform-specific path to the executable instead
of the hardcoded "echo". This should ensure that the tests pass even on
systems where echo.exe is not installed.
Note that we can't simply use a do-nothing exe (like rundll or hh.exe),
as we're passing parameters, and those executables may behave
differently in the presence of those parameters.
