The QFS bar does not need the required complexity. QFS is intended for simple quick find--the *optional* Regular expression search is *only* appropriate on the Find and Replace dialog.

-1

-1

-1 too. => WF

I'm challenging the WF, drawing your attention to the fact that the ask is either for a visible-by-default or invisible-by-default toggle, which wont the "complexity" argument is side-stepped entirely.

Remember that the find bar is often used to search when you want the dialog not to obstruct the document contents. User should not be required to choose between search capability and result inspection convenience.

Also, let us recall "find bars"/"find pop-ups", used in most popular applications which support regexp search at all - typically _do_ have regexp capability. This is true in particular for text editors, such as Sublime Text, gEdit, Featherpad, VS Code, JetBrains IDEs, etc. 
(Of course, it is off by default.) So, people are used to this "complexity", and those app authors have determined it is merited.

About the complexity, I'll also challenge the claims made here:

* "Find bars"/pop-ups in most applications I know, which support regexp search at all, typically _do_ have regexp capability. This is true in particular for text editors, such as Sublime Text, gEdit, Featherpad, VS Code, JetBrains IDEs, etc. 
(Of course, it is off by default.) So, 

* The "complexity" is only there if the user cares to explore it. They don't have to worry about widgets others than the search box, if they don't want to.

* "simple quick find" - using regular expressions _is_ simple and quick, when you know how to use them.

Finally, I want to draw your attention, Heiko, to the fact that none of the opponents of this suggestion made an attempt to rebut the use-case/motivation.

The search "engine" for Find bar (including Sidebar 'Repeat search' mode) and the Find & Replace dialog follow different implementations.

The "cross over" of search attributes bleeding between has been a long running nuisance that we've been able to reduce.

Every "feature" we add to the Quick Find Search has to be maintained relative to the Find & Replace instance--with user experience impacts considered for both.

Decisions have consistently been to keep F&R features and configurations isolated from the QFS, that doesn't change. But legitimately we ask why regex based search would be necessary to implement on the QFS--when it is already implemented as a selectable option on the more robust F&R dialog?

The QFS toolbar does not need the added complexity, and it is not worth the dev effort, UX impact, and maintenance requirements to add the feature.

Still a -1, and => WF

In the past we decided against additional options and rather made the QFS as simple as possible. The RegEx button would contradict this effort. => WF

(In reply to Heiko Tietze from comment #6)
> In the past we decided against additional options and rather made the QFS as
> simple as possible. The RegEx button would contradict this effort. => WF

Heiko, was that a design meeting decision? Because we often make those with very little to go on beyond a few minutes' consideration. Do you happen to have the minutes of that? 

Anyway, to dig a little deeper:

* Was that a decision to _prevent_ the user from adding functionality to the QFB? I tend to assume the decision regarded the default QFS complexity.

* What was the stated rationale for that decision?

QFS should be quick and simple, everything else has to be done in the dialog (or the sidebar). Please use BZ's search function for more details.

(In reply to Heiko Tietze from comment #8)

That doesn't answer my questions... but to reply to these points again:

> QFS should be quick and simple

1. Searching is not slower or more complex because there are other controls on the QFB, one can just ignore them.
2. The ask isn't even to place the toggle on the QFB, just to offer it as an optional button, which can be added via customization. The users who want maximum simplicity will never be bothered by it.
3. Without regular expressions, finding things is slower and more complicated.

>, everything else has to be done in the dialog (or the sidebar).

1. On the contrary, it is a boon if searching can be done without the dialog being up on screen. The dialog occludes much of the contents.
2. One can make the same points regarding the sidebar as the QFB and vice-versa.
3. The sidebar shows results in the sidebar, I want to see them in the main window pane.
4. The sidebar doesn't have regexp's either!

Still, looking at the sidebar - in order to keep it simple, we put a bunch of options in a gear-wheel dialogbutton. I wouldn't mind it if we have the same thing on the QFB, so that the text and widgets of additional search settings were not always on display. Would that be more to your liking as a way to introduce regexp support, rather than a separate optional toggle?

Wait a minute... 

Have any you guys been talking about the Quick Find _Sidebar_ (QFS)? I haven't... This bug is abound the Find _Toolbar_. Just making it clear in case there was a misunderstanding.

QFS stands for _quick_ find & search, which is the toolbar.

(In reply to Heiko Tietze from comment #11)
> QFS stands for _quick_ find & search, which is the toolbar.

Yess the toolbar. But I think there has been a bit of bleed over while defining bug 95405

Personally I try to refer to the toolbar as the Find bar (it is Toolbar framework) and the Find deck results GUI on the Sidebar and discussion here has been pointed at the toolbar.

As noted bug 166061, would agree the search configuration of the SB Find deck should conform more closely to the Find toolbar; with something additional needed to support results GUI for the Find & Replace dialog.

If regex search support is implemented for the Find toolbar, it should probably also be implemented for the SB Find results GUI search.

*** This bug has been marked as a duplicate of bug 119200 ***