AFAIK that would be OK for typical “English” letters.
I don’t know for certain if POSIX regex considers \w the same as PHP PCRE - i.e. “word” characters are based on locale - but I believe it does and I think that would be safer if you’re using a character class
Feature suggestion: this (amazing, by the way) new UI is not accessible from search until you enter full-screen search. That means if I am sitting here in this topic and click search, I don’t see the UI. If I click options, I get the old text based popup.
Could the “options” button redirect you the full-screen search, or add a button that does that? At the moment I have to actually type something and click enter to reach full-screen search (or right search and open in new tab). Not intuitive or accessible.
I think the next step is to build auto-complete ability into the existing search so it can help populate the advanced search features. Whether that helps with intituitiveness, I’m not sure, but I believe that is the next up-coming step.
Granted, changing “options” to “advanced” and linking it to the full page search, may be something worthwhile now, since the UI now exists.
Yes, I agree – clicking “options” should trigger full page search with the Advanced panel pre-expanded. I’ve removed all the old search help copy entirely to expedite this.
I’m going to throw this on my plate for this week in my spare time (hoping I get to it tonight)
One minor tweak. When filling in the user and populating the search field, don’t use
user:username
but instead
@username
That old search help copy was a nightmare to localize and maintain, it will be really nice to get rid of it all.
Yes this is a case study in “better UI” replacing “bad help pages”.
K, will work that in tonight too. 
This is done. I also updated the qunit tests so they stopped failing due to the removed markup from
Seems the removal of the old search help broke the build by making eslint unhappy. I’ve fixed it (just waiting on build to run to verify it is fixed).
https://github.com/discourse/discourse/pull/4491
Any chance this could also give an option for number of results returned? Still getting killed by MAX 50 results issue #WishFullThinking
Cool, this looks good. Two questions:
Some 
s/UX issues
The default for “In Category” is “uncategorized” but it doesn’t actually search for “uncategorized” categories but all categories.
“Posted” before/after should use a date picker and we can expand that to support “in between” searches.
‘With Tags’ input field is much longer than other input fields.
That is intentional (hence why it is on its own line), as it can support multiple entries.
You will lose the ability to search for before X days or after X days if you use a date-picker. Since the feature supports both, I elected to leave it a text field.
Yeah, the category-chooser defaults to that… 
Has for ages, there are multiple topics about it here on Meta because it impacts Admins when Uncategorized is disabled. (but it seems setting it to Null, solved this?)
It isn’t. So the uncategorized also only applies to instances that permit uncategorized topics. It seems to be due to the fact Uncategorized is treated in a special manner, which is the same reason you can’t default a New Topic off of Latest to “Select a Category”, that option doesn’t exist when Uncategorized is present.
tag-chooser has a variable height so we don’t really need it to be that long
I’ve actually never known about the before: and after: advanced search terms until today and it wasn’t easy for me to determine how to use it from the search UI. The format of the date required is a mystery as well. I think we should just drop support for before:5 in the search UI and just use a date picker since selecting 7 days ago in a date picker isn’t difficult.
That’s fair. I’ll switch it to use type=“date” here shortly. That should get it operational.
So should I add a width of 70%? I really don’t want to end up with a squashed tag selector on mobile.
Also, I just pushed a change to fix removing the filters via the search-term text field.
