Dont know if this has been asked before or theres a reason its not a feature.

With the (not very recent, lol) change to be able to enable/disable specific blacklisted tags under the searchbar individually of one another, would it be possible to either
1. auto-disable a specific blacklisted tag when explicitly searched for or
2. make the blacklist ignore tags that are explicitly searched for completely (not changing the "enabled/disabled" status of the tag, so it wouldnt affect other searches afterward for example)?

I personally think theres a handful of applications for this functionality, an example i personally come across often would be stuff like gore. i have that tag blacklisted as i usually dont wanna see it during normal browsing, but sometimes like to check out art specifically with that tag, so being able to see those posts when i specifically search for them, without having to worry about re-enabling the blacklisted tag for other/later searches (as suggested in 2.) would make browsing a lot easier and more intuitive; especially while browsing in 2 or more tabs at the same time (having a tab with i.e. gore open and one with any other broad search query makes it difficult to browse as between each page reload, including clicking through images or altering the search query, the tag updates to enabled/disabled based on the other tab as well.

thanks in advance for any responses ^.^

If there's specific contexts where you don't want it to be enabled, you can just add that to the blacklist (e.g. adding fav:me to avoid blacklisting favorited works, adding -some_artist to avoid blacklisting their works).

If you're still dead set on it, there's a few problems with it.

1. We'd have to resolve aliases client-side instead of server-side, which would required redundant load on the server & adding additional bespoke client code to do so
2. We'd likely want to exempt explicitly negated tags
3. Properly handling negated tags would require properly propagating the negation when part of a grouped query; I did implement some code to do this server-side, and I abhore the thought of porting that to JavaScript and running it client side

aacafah said:
If there's specific contexts where you don't want it to be enabled, you can just add that to the blacklist (e.g. adding fav:me to avoid blacklisting favorited works, adding -some_artist to avoid blacklisting their works).

If you're still dead set on it, there's a few problems with it.

1. We'd have to resolve aliases client-side instead of server-side, which would required redundant load on the server & adding additional bespoke client code to do so
2. We'd likely want to exempt explicitly negated tags
3. Properly handling negated tags would require properly propagating the negation when part of a grouped query; I did implement some code to do this server-side, and I abhore the thought of porting that to JavaScript and running it client side

4. In the cases where people might search a tag, not knowing it's aliased to a blacklisted tag (e.g. out of curiosity, accidentally selecting an incorrect autocomplete entry, etc.), I imagine they'd be rightly frustrated
5. How would we appropriately reflect this in the UI, while also allowing users to override this?

It sounds nice, but in most cases, this could be better handled by more narrowly scoping your blacklist, and I doubt the mild convenience in the few cases where it is desired would be worth the strife in the potentially more frequent cases where it isn't, and that's assuming we can get the detection handled satisfactorily, which would require a lot of extra work for developers (at the cost of handling other tasks) & add a lot of extra load on the server & the client. A system like the blacklist being overridden based on an assumed intent is generally asking for trouble.

aacafah said:
4. In the cases where people might search a tag, not knowing it's aliased to a blacklisted tag (e.g. out of curiosity, accidentally selecting an incorrect autocomplete entry, etc.), I imagine they'd be rightly frustrated
5. How would we appropriately reflect this in the UI, while also allowing users to override this?

It sounds nice, but in most cases, this could be better handled by more narrowly scoping your blacklist, and I doubt the mild convenience in the few cases where it is desired would be worth the strife in the potentially more frequent cases where it isn't, and that's assuming we can get the detection handled satisfactorily, which would require a lot of extra work for developers (at the cost of handling other tasks) & add a lot of extra load on the server & the client. A system like the blacklist being overridden based on an assumed intent is generally asking for trouble.

2/3. am i missing something? it seems like that wouldnt matter. unless ofc the blacklist works by adding those tags to the original search query. tbh i always thought its just a secondary query that gets applied after the results for the unfiltered search are returned, also always thought that was the reason you get less than 75 results when theres blacklisted posts, like it returns your original 75 results for your query, THEN blocks out your blacklisted stuff after a second query. im realizing now that'd probably be horrible performance wise but i just always thought thats how it worked. seems like a pain in the ass to work around tho if its only 1 combined query
4. i mean i dont fully disagree but realistically how common is people accidentally specifically searching for tags aliased to something they blacklisted VS people doing that intentionally? and about the curiousity thing, that already happens when people find a tag for the first time. i just think an "accident" falling into neither of those 2 categories seems pretty rare
5. reflected in the search ui seems easy enough with just somthing like a * next to the ignored tags, maybe color code it differently (similar to how currently disabled tags are greyscaled), maybe even a cute little infobox along the lines of "ignored because you specifically searched for this" when you hover it. and overriding this new functionality seems easy enough since i imagine most of the logic for it would have be entirely new, so just having an option in the user settings to disable/enable this behavior coupled with only doing it if the flag for it is true seems relatively easy

bread69 said:
2/3. am i missing something? it seems like that wouldnt matter. unless ofc the blacklist works by adding those tags to the original search query. tbh i always thought its just a secondary query that gets applied after the results for the unfiltered search are returned, also always thought that was the reason you get less than 75 results when theres blacklisted posts, like it returns your original 75 results for your query, THEN blocks out your blacklisted stuff after a second query. im realizing now that'd probably be horrible performance wise but i just always thought thats how it worked. seems like a pain in the ass to work around tho if its only 1 combined query
4. i mean i dont fully disagree but realistically how common is people accidentally specifically searching for tags aliased to something they blacklisted VS people doing that intentionally? and about the curiousity thing, that already happens when people find a tag for the first time. i just think an "accident" falling into neither of those 2 categories seems pretty rare
5. reflected in the search ui seems easy enough with just somthing like a * next to the ignored tags, maybe color code it differently (similar to how currently disabled tags are greyscaled), maybe even a cute little infobox along the lines of "ignored because you specifically searched for this" when you hover it. and overriding this new functionality seems easy enough since i imagine most of the logic for it would have be entirely new, so just having an option in the user settings to disable/enable this behavior coupled with only doing it if the flag for it is true seems relatively easy

now gonna be honest i did wanna answer 1. last because i kinda wanted to talk/think about everything else on its merits but (me completely forgetting about) the fact that aliases would have to be resolved clientside sounds like absolute hell and i wouldnt wish refactoring for that on my worst enemy, so cheers and thanks for the response

on a side note, about narrowing down my blacklist and similar: its not that i want specific tag combinations (dis)allowed, i actually want to NEVER see something until i specifically do. broadest example would again be something like gore. if im browsing for porn 9/10 times i dont ever wanna see that stuff, but then if im just browsing to look at art when im bored i might specifically seek out that genre. and browsing art out of boredom usually also leads to having at least a dozen tabs open at a time, so thats where the issue with dis-/enabled blacklist tags updating across multiple tabs comes in :/

bread69 said:
...i always thought its just a secondary query that gets applied after the results for the unfiltered search are returned, also always thought that was the reason you get less than 75 results when theres blacklisted posts, like it returns your original 75 results for your query,...

Correct.

bread69 said:
...THEN blocks out your blacklisted stuff after a second query...

It's not a second query, it checks the (alias-resolved) tags on the posts against the (alias-resolved) blacklist client-side, & hides those posts; as a result, the terms in the query, which may include aliases, might not match the de-aliased blacklist terms.

bread69 said:
...realistically how common is people accidentally specifically searching for tags aliased to something they blacklisted VS people doing that intentionally...

I'd agree it's possible the ratios are slanted, but the problem is, unless you can properly guess the user's intent 100% of the time, you're sacrificing the strong disgust & irritation of one group for the mild convenience of the other. It's similar (although far less severe) to self-driving cars (at least for the time); the problem in depending on them isn't the 99% of cases where they work & alleviate a mild inconvenience, it's the 1% where they don't and kill someone.

Idk, toggling the blacklist on/off is pretty trivial. If I am feeling particularly masochistic and search paw_patrol it's literally only one extra click to disable that blacklisted term.

At the end of the day, in both cases, getting to the desired state is equally inconvenient. As such, the side that should prevail is the one that would suffer the greatest harm should they not get their way (regardless of how trivial that harm is in the grand scheme of things), and the party that's occasionally ok with viewing blacklisted content is going to lose every time, with that loss being exaggerated by the non-trivial work that would need to be done to facilitate this.

Honestly, I'd argue the better solution would be to invalidate the cached blacklist state after x time, maybe with a persistent option in the gear menu to persist that state indefinitely. If the primary inconvenience is remembering to re-enable the blacklist, this would likely solve that, & it'd save people who forgot they turned it off last night from getting a shock today.