Recently I tried a search for tauric characters using just taur as a search term, but I noticed that it wasn’t detecting characters with their species set to wolftaur, foxtaur, or dracotaur.
I also noticed the behavior with herm not matching to hermaphrodite.
I understand that blob searching most likely wasn’t added to avoid situations where searching for male would also produce all results with female due to the trailing male match, but would it be possible to have wildcard functionality using *,%, or $ introduced to filter for situations like the above?
( Also, if the client is open to additional developer volunteers, I’d be happy to try and tackle this myself and open up a PR. ^^ )
It is currently possible to match multiple using pipe (|), such as:
wolftaur|foxtaur|dracotaur
But a wildcard would be nice. And I would prefer *, being the most commonly used.
There is one minor issue with tags though; tags themselves may contain all of the suggested characters.
Though, I think the solution might either be to disallow * in tags (something I would have to do on the server), or to just ignore the issue - if someone choose to have a tag called *^_^*, maybe it is okay if filtering with that tag would also match: (^_^)?
Also; how should the matching work?
Should we allow it anywhere in a word? E.g. fox*, *taur, fox*taur (matching foxytaur?)
Should it match space (for tags with space in them)? E.g. size* matching size difference
Should empty match be allowed? E.g. fox* matching fox.
Should multiple wildcards in a word be allowed? E.g. *wolf* matching direwolftaur
Just some thought on the idea.
And pull requests are always welcome! But it is always good to discuss the feature first, like we do now. Then I can have a say, and the community can have a say.
To save yourself having to embed regex into your filter, I would think that an * at either or both ends of a filter entry should be enough for 99% of most searches. The * should match 0 or more of any printable character.
I think ignoring should be fine. In the specific case you provided (^_^) I think *^_^* matching it would provide the same functionality as searching for (^_^) directly, and I cannot think of any situations where the wildcard matching behavior could provide a negative impact.
It did also make me think about how there are a few legitimate use cases where custom tags use * for flavor cases, and those shouldn’t be affected by wildcarding. For example, I’ve seen someone using the tag *glomp* to add a bit of silly flavor for their character, and then *demisexual to denote the sexuality of a specific profile when they have it active. Even in these situations * as a wildcard shouldn’t affect them.
I think the approach of a general fuzzy search would be the best way to tackle it.
Allow for a match anywhere in a word
Ignore spaces - eg. wolf*would match wolf demon and stuffed* would match both stuffed full and stuffed-full
Empty match should be allowed unless we introduce a separate wildcard that is more strict and looks for some form of match to be present, but I think that’s complicating the matter.
I would think that if you have a fuzzy search wildcard, multiple should be allowed. As egregious as it might be for an example, I do think the search should be able to find itty-bitty-ditty-committee from a wildcard as obtuse as*ty*mit*
I did stumble across this as I was digging through other stuff in the developer section, as well as the preference to work on GitHub issues first. I don’t think there was any foul in my unfamiliarity with the process, but if so, my apologies. Either way, happy to see what you’re doing here and happy to pitch in where I can!
I agree that a subset of characters would be sufficient enough for 99% of most tags, but I have seen a few people that use specific ASCII characters, emojis, and a few other little touches to add some nuance and flair to their tags. I’d hate for my suggestion to lead to anyone being unable to express themselves in a way they’d like and want to.
Not really. If I would have done it again, I would have allowed a much smaller set of characters.
The primary reason for tags is 1) quick info and 2) searchability. And allowing too many characters makes it less searchable.
But I don’t feel it harms enough for me wanting to suddenly withdraw a lot of used unicode characters.
Yes. I prefer to create an issue of it first, where I can summarize and specify what we think is the solution we are after.
I have just now made an issue that you can work on, if you’d like!
