Improved Regex handeling when searching

[jannisCode]

What it does

This PR improves the handeling of the Regex search when searching in the new or old find/replace dialog or the Big Search (strg+h). This is regarding #1204

Before

After

while typing:

when hovering:

Additionally to the functional changes the new class helps with reusing the code that handles the regex search.

[fedejeanne]

Revert this change

[jannisCode]

done

[fedejeanne]

Revert this

[jannisCode]

done

[fedejeanne]

@jannisCode thank you for the contribution. I made some comments regarding coding style and naming conventions.

I haven't tested it yet, I can do it once the PR is ready to be reviewed.

[jukzi]

the screenshot looks nice

changes applied

[Wittmaxi]

This looks like a promising change. I wonder

1. how easily can this be incorporated into the FindReplaceOverlay?
2. how does this behave for multiline RegEx error messages?

It would be nice if you could provide 1) as a follow-up PR.

[fedejeanne]

Looks better but I found one change in AbstractTreeViewer that doesn't belong here and I have another question regarding some removed invocations of evaluateFindReplaceStatus (which was renamed to decorate). Maybe the latter is the reason why @Wittmaxi asks for integration with the new find & replace overlay? I remember testing the previous version of this PR and the f&r overlay was working exactly as the other searches i.e. it was integrated before.

I haven't tested again, I will do it later today.

[fedejeanne]

I haven't tested again, I will do it later today.

After testing, the behavior looks almost OK, I have only 1 finding (read further):

What works

The expression is validated in all 3 requested places:

The finding

It would be better if the f&r dialog deactivates all of the buttons below once the regex is found invalid, just like the Search dialog (Ctrl + h) does:

@Wittmaxi please test it too and let us know if you have any findings. Also, please elaborate on your request:

1. how easily can this be incorporated into the FindReplaceOverlay?

I see the behavior already in it, maybe you meant something else by "incorporated" (it's a ambiguous term).

w.r.t. your other request:

2. how does this behave for multiline RegEx error messages?

I also saw it and the solution is to "merely" adapting the (old) method SearchDecoration::getValidationError. Since I'm interested to know why it wasn't done like that in the first place (the method was already there, it was only moved in this PR) and there are some nuances with that request, I want to leave that for another Issue / PR --> vi-eclipse/Eclipse-Platform#130 (it's labeled with "Student" and it has no assignee yet so you may work on it too :-) )

[fedejeanne]

@jannisCode there are conflicts that need to be resolved.

[fedejeanne]

@jannisCode remove the "merge" commit

Better to rebase on top of origin/master when you want to bring the latest changes into your branch ;-)

Since the "committer" is GitHub, I assume it was done by clicking "Update Branch" in this PR?

The changes in AbstractTreeViewer were reverted

[fedejeanne]

@jannisCode rebase again and then force-push your changes.

In the end, your commit (currently 31fefe3 but later it will be "renamed") should be on top of the commit 1eead54 (origin/master).

EDIT: you'll need to resolve conflicts when rebasing.

EDIT 2: you did it while I was writing the comment ✔️ ✔️ ✔️

[fedejeanne]

The failing tests are unrelated --> eclipse-platform/eclipse.platform.swt#1518

Let's wait until the I-Build is done and re-trigger the checks to make sure nothing broke.

[jannisCode]

#2373 (comment)
#2373 (comment)

done

[fedejeanne]

Ignoring random test failure #1941

@jannisCode please create a N&N entry