please implement a more efficient system of tag-searching:
say you're looking for material under "demon-girl", this forces a search to only include posts with said tag, however, since "demon-girl" is similar to "succubus" or "demon" one would have to search those three separately. Additionally there are no methods to filter tags that you don't want from each tag individually

my solution to this is introducing in-search-logic that would function in a manner akin to a formula:


* AND-statement: this is currently what we have, a system which requires all tags to be present. For sake of simplicity the syntax for an and statement would inherently be the search itself as any search would have to fill all the parameters of the syntax and tags present, hence to include a tag under an AND-statement all that would be needed is to add it outside of other syntax

* OR-statement: a way to search for post which contain any of the included tags. This might be done by searching using all the tags grouped and comparing the ID of any posts that are found with an array to which said ID gets appended when it's displayed, if an ID already exists in the array the post simply gets skipped as to prevent duplicates. The syntax for such a function could be ["tag1" "tag2" "tag3" "tag4"] where the square brackets[] create an array of the included tags. Thereafter when searching for posts the engine will compare the array to the database and using the aforementioned ID-system include 1 of each post where any of the tags apply. Functionally the square brackets[] create a new tag which groups the contained tags together and treats them as a single tag

* NOT-statement: as simple as it sounds, a system to exclude certain tags which you don't want to show up. Say you are looking at material where it occurs commonly but you really don't want "rape" as a tag by including said tag in a 'NOT-statement'. the syntax for such a statement might be ~"tag1" "tag2" "tag3"~ where, after the engine first collected a set of material, it then does a second pass and removes any posts with any of the tags contained between the tilde~~. However, since tilde~~ don't allow for the beginning and end of a statement, a different symbol - or to be precise, pair of symbols - could be employed such as comparatives<> or squiggly brackets{}. The Reason i am excluding simple brackets() is due to how common they are in pre-existing tags; trying to implement that would be a recipe for front-end-developer-trauma. (as a side note, i am aware that -"tag" would do the same thing, however i fret that it may cause unwanted results if combined with my suggested syntax such as [-"tag1" "tag2"] where the engine might respond in an unexpected maner. Though since i'm not working on the engine this is merely guesswork on my behalf)


with these statements a search could either be preformed using the inherent AND-statement system:
| "tag1" "tag2" "tag5" |
| "female-focus" "succubus" "animation" |
or using the syntax:
| "tag1" ["tag2" "tag3"] ["tag5" "tag6"] {"tag4"} |
| "female-focus" ["succubus" "demon-girl"] ["animation" "gif"] {"rape"} |


since these syntax are starting to resemble arrays i have a feeling that an implementation of these features would be best fit in a more user friendly manner such as separate search fields or buttons

i would enjoy to hear feedback and thoughts on this concept as i think it would make - if you forgive the joke - a fine addition to this collection

there are several other UI-features which i would enjoy to see but i acknowledge that it's a lot easier for me to sit on the side-lines and point than what it is to actually update and implement such features

Took me a second what you meant.



This line is in the first paragraph and reads like you mean there is no way to exclude a tag in your query. Reading that early could lead to people skipping the rest of your post thinking you don't know what you are talking about. Instead I would say

not exactly what i meant when it comes to feedback but a valid point none the less

I don't think many people will care tbh. The tag and search query system is good enough for most users to get what they want.
Having this much control in refining your single query is a super niche scenario, I assume.
The only one that might be interested in it are devs, to make their search query system more powerful.
But I can also see them dismiss it as they might seem it overcomplicating the system and maybe confuse users.

This is basically never going to happen. Not because nobody wants it, but because the one programmer with access to things like that on the site only gets on once or twice a year. That's why features like "favorite tags" have been broken for pretty much ever.

well, fuck-

Does the programmer even get paid lol