Description
-making the search bar able to use () to be able to search for example for -(solo male -female). Any other way to realize that would be nice, too.
If this is already possible the help:search page needs to be updated.

Why would this be usefull?
I don't really think that I need to elaborate about why this would be usefull but here is an example
-You can't filter out your blacklist because that can do exactly that like filtering (solo male -female).
This would become possible.
If wished for I could ellaborat

Which part/s of the page/s would be affected?
GUI wise like nothing maybe the search bar in the posts section. Implementing wise I don't know

just some high-level thoughts to start off with:

i recall danbooru devs have implied in the past that a significant syntax enhancement like this would probably require a complete rewrite of the existing search expression parser.
however, i'm not sure exactly what this means for e621 because it sounds like there may have already been major alteration to cater for its Elasticsearch database (as opposed to danbooru which runs searches on the postgres DB instead).

bipface said:
just some high-level thoughts to start off with:

i recall danbooru devs have implied in the past that a significant syntax enhancement like this would probably require a complete rewrite of the existing search expression parser.
however, i'm not sure exactly what this means for e621 because it sounds like there may have already been major alteration to cater for its Elasticsearch database (as opposed to danbooru which runs searches on the postgres DB instead).

I'd like to offer an improved(and alternate) search syntax at some point, but it's a "nice to have" on the TODO list. Elasticsearch at least makes it pretty trivial to construct something like this, and the number of search terms tends to have only minor performance impact. So "maybe in the future."

A small addition: I wrote ( ) but it could be any other way to realize that
it could be a connectingsymbol/character which the parser (don't know if that is a legal expression but you understand what I mean?) don't uses already
Example: -tagA&-tagB&tagC
or any other symbol/s or character/s which do the grouping
Example: '-tagA -tagB tagC' (while it's possible to choose only one symbol it's better to choose an opening symbol and a closing one)
or double brackets/symbols/characters (no example)

I was thinking on something like this:

- tag0 tag1 -tag2 -tag3 - tag4 tag5

In this example; exclude posts that have tag0 and tag1, but not tag2 and tag3, while searching for posts that have both tag4 and tag5 . A lone dash makes it behave like it was on the blacklist, another lone dash turns it back to normal. You can also use

tag4 tag5 - tag0 tag1 -tag2 -tag3

for the same results.

agiant said:
A small addition: I wrote ( ) but it could be any other way to realize that
it could be a connectingsymbol/character which the parser (don't know if that is a legal expression but you understand what I mean?) don't uses already
Example: -tagA&-tagB&tagC
or any other symbol/s or character/s which do the grouping
Example: '-tagA -tagB tagC' (while it's possible to choose only one symbol it's better to choose an opening symbol and a closing one)
or double brackets/symbols/characters (no example)

The query parser doesn't currently use (), to my knowledge. Nor {} or [].
We do have plenty of tags which use () (this isn't really a significant problem for the parser, but nesting parentheses could cause user confusion). We have a few tags which use [] but most of them look like they are mistakes that should be reformatted to use the foo_(bar) format.

Personally I prefer [] slightly because it is easier to type, as well as almost never occurring in legitimate tag names.

I'd also suggest that the spacing rules should be permissive so that people can write either [solo male -female] or [ solo male -female ] -- the former being more compact, while the latter is more clear.

I don't see any particular benefit to using a connecting symbol (in the manner of | in regexps, if I understand you correctly) instead of a parenthetical.

Felix, I think what you are writing would be much clearer by instead postulating that you can negate parentheses
( -(tag0 tag1 -tag2 -tag3) tag4 tag5).

savageorange said:
The query parser doesn't currently use (), to my knowledge. Nor {} or [].
We do have plenty of tags which use () (this isn't really a significant problem for the parser, but nesting parentheses could cause user confusion). We have a few tags which use [] but most of them look like they are mistakes that should be reformatted to use the foo_(bar) format.

Nice elaboration of the idea. My thoughts were similar but most likely not understandable from the amount and content I wrote.

Personally I prefer [] slightly because it is easier to type, as well as almost never occurring in legitimate tag names.

You compare () , [] and {} right? () is used in many tags and could lead to errors or difficulties. [] is not used so much while also when used most times wrongly. {} is left and right of [] and therefore slighty more difficult to tip.
And this is what you mean?

I don't see any particular benefit to using a connecting symbol (in the manner of | in regexps, if I understand you correctly) instead of a parenthetical.

I just wrote every possible method to realize that. Who knows maybe one is easier to implement or another one shows better performance. Something like that.

Felix, I think what you are writing would be much clearer by instead postulating that you can negate parentheses
( -(tag0 tag1 -tag2 -tag3) tag4 tag5).

What Felix has are not negating parantheses but a grouping on-off switch. A lone dash toggles the grouping ON like opening parentheses while another one turns the grouping OFF. Therefore a closing parenthese is not needed in his second example.

Sooo....Three months passed. Is this now denied or what is up with this?
I would really like to see this.

agiant said:
Sooo....Three months passed. Is this now denied or what is up with this?
I would really like to see this.

@KiraNoot said it's on the wishlist but not a top priority right now.

Although I'll go ahead and add my vote that a more robust search logic would be nice. [] gets my vote for grouping, as I feel the lone dash isn't intuitive as a grouping character, especially since the dash function as the negation operator when it isn't alone.

I posted my post accidentally but after checking again how the feature suggestions work, I thought if this gets on the to do list it gets this [Feature/Approved] or get the [Feature/Denied] or something. So I thought maybe leaving it as it is doesn't hurt that much.
Anyways I will not pursui this feature further for now.

On rule34 xxx it is implemented like this: baz ( foo ~ bar ) ( quux ~ bat ). To make this parsable they enforce strict spaces placement: they are mandatory after "(", before and after "~" and before ")". It makes possible to search everything I ever wished to and get the most accurate results (especially, given that there are a lot of synonyms on rule34).

+1, the r34 implementation allows for very complex searches

Don't necropost, especially to add a useless "+1"