I'm just not a fan of when I search "juice_that_makes_you_cum" and then while typing I gotta see "juice_that_makes_you_fart"

kerocylinx said:
I'm just not a fan of when I search "juice_that_makes_you_cum" and then while typing I gotta see "juice_that_makes_you_fart"

Yeah... Understandable

autocomplete is completely separate and blacklisting is clientside only, I do not personally think it's worth it to try inserting blacklisting code into the code that parses the autocomplete response, especially considering blacklisting can be toggled on and off without any change to the page

donovan_dmc said:
autocomplete is completely separate and blacklisting is clientside only, I do not personally think it's worth it to try inserting blacklisting code into the code that parses the autocomplete response, especially considering blacklisting can be toggled on and off without any change to the page

I personally do think it's worth it because there are fetishes that I don't want to be reminded of when searching this site and that's the entire purpose of the blacklist feature. I'm just asking for similar code to be applied to the dropdown list received by the server, which then becomes clientside and can be filtered by the blacklist.

donovan_dmc said:
autocomplete is completely separate and blacklisting is clientside only, I do not personally think it's worth it to try inserting blacklisting code into the code that parses the autocomplete response, especially considering blacklisting can be toggled on and off without any change to the page

well, it's also that the blacklister just marks stuff to be hidden from view, and it dosn't remove them entirely. for posts that's fine but on the autocomplete it could cause some weird issues since the list elements would still be selectable using the arrow keys even if they were hidden. like, on the user end you could just:

.ui-menu-item[data-autocomplete-value="<tag>"] { display: none; }

but the list entry would still be "there" even if you can't see it.

also, I don't know anything about how JavaScript does, but a script that runs through your entire blacklist to check the autocomplete entries every single time you do something that would update the searchbar seems like it'd be pretty inefficient.

kerocylinx said:
I personally do think it's worth it because there are fetishes that I don't want to be reminded of when searching this site and that's the entire purpose of the blacklist feature.

The purpose of the blacklist is to filter posts, not words
Honestly, if a word in a search suggestion can trigger you that much just fully disable autocomplete at that point

dba_afish said:
well, it's also that the blacklister just marks stuff to be hidden from view, and it dosn't remove them entirely. for posts that's fine but on the autocomplete it could cause some weird issues since the list elements would still be selectable using the arrow keys even if they were hidden. like, on the user end you could just:

.ui-menu-item[data-autocomplete-value="<tag>"] { display: none; }

but the list entry would still be "there" even if you can't see it.

also, I don't know anything about how JavaScript does, but a script that runs through your entire blacklist to check the autocomplete entries every single time you do something that would update the searchbar seems like it'd be pretty inefficient.

That's a pretty resourceful pure CSS solution and if memory serves, not the first I've seen from you.

I don't think we'd be opposed to an inefficient brute force manual filter on the autocomplete entries due to performance, as long as it's a toggle; after all, it would be client-side anyway, so if you wanted it despite the hit, you could make that call. It's moreso that
1. While many people use it that way, the blacklist is divided into *lines*, not *tags*, and reconciling that is likely to be a pain
2. There are times when you want to search a blacklisted term (e.g. to remove such entries from favs/sets), and it'd be frustrating to deal with that
3. It's a lot of work for such a niche concern; especially one that, if it's such a big problem for a user, does already have a workaround (like Donovan said, you can just turn auto complete off)
Given that, I don't really see a dev putting this on the to-do list anytime soon. Of course, the site's open source & you're always welcome to try it yourself but I wouldn't hold my breath on someone taking up the mantle.