Unsearchable tag bug

We have an artist called foo*, which is unsearchable for. Try clicking on the tag in post #431590, you'll see how it clashes with our wildcard searches. Do we have any syntax for escaping chars in tag queries? If yes, it's a bug it doesn't use it in the link. If no, it's a bug we don't.

Reminds me of Blood+, which was more or less fixed, but still occasionally causes problems, especially where Javascript is concerned. (Note how it works with things like the Endless Danbooru greasemonkey script)

The easy (read: lazy) solution would be to forbid tags from containing asterisks, just like how they can't contain commas. Otherwise we'll need an escaping mechanism for searching the artist and tag indexes as well, not just for the post index.

foo** makes the wildcard search work, but obviously doesn't fix the underlying problem. Forbidding asterisks and changing the artist to foo is the simple solution.

foomidori would be the better choice as it's the username he uses for both accounts and his email.

When I was actually inputting the name of the artist, I was debating whether or not to include the asterisk. Sorry for any inconveniences or problems I may have caused. I don't mind recreating the artist with foo or foomidori and deleting foo*. Just tell me what you would like done and I'll fix it.

+1 foomidori for the short term issue.

+1 forbidding asterisks from tags, unless there's a way to keep them in, still allow all wildcard searches, and not demand an inordinate amount of programming time from albert.

I guess I can't conceptualize how it could be programmed to instinctively know what the user is asking for if they type "foo*". Ether you mean the artist or you mean "give me tags starting with f o o", but it seems indistinguishable on the programming end, right?

We could offer a disambiguation page that you have to go through before results display, but that's just an extra hassle to go through and would still break all sorts of things.

Edit: Well, okay, there's the escape character idea, but it'd be hard to spread the word about that, I'd think. Just not using asterisks seems the better idea.

Even if you like the escape character idea it'd be trickier to do than you might first think. You could use backslashes to mark literal asterisks (as in foo\*), but that still wouldn't be able to handle the unlikely case of a tag having a name that conflicts with a metatag, such as source:foo.

So..should I create a new artist by the name of foomidori and delete foo*?

photonlancer said: So..should I create a new artist by the name of foomidori and delete foo*?

Correct.

photonlancer said:
So..should I create a new artist by the name of foomidori and delete foo*?

Looking at the artist's website, the full information on her name is ”碧　風羽　（みどり　ふう) ( foo* ) Foo Midori" so I'd rather go with midori_fuu or midori_foo.

Dakanya said:
Looking at the artist's website, the full information on her name is ”碧　風羽　（みどり　ふう) ( foo* ) Foo Midori" so I'd rather go with midori_fuu or midori_foo.

You're lucky you said this now, I was about to enter foomidori. I'll just use midori_foo. No one should have any objections with that. Also, thank you for the appropriate name, Dakanya.

**EDIT: So apparently midori_foo already exists. I was unable to pull up the artist's name before due to the pictures that I was uploading were from the pixiv account. I have now added the two pixiv url and changed the posts that include foo* to midori_foo. Sorry about that.

::looks:: Oh, good call Dakanya.

But Photonlancer, it'd be midori_fuu, for correct romanization. I'll alias it now.

I'd allow wiggle room for "foo" if it were done in katakana without a kanji equivalent or something (they could be trying to approximate a non-Japanese spelling), but in this case it just looks like a romanization issue. I'd probably also go with _foo if it conflicted with an existing midori_fuu, but that's not the case here.

It's good that we got this example taken care of, but perhaps this is something we should discuss further, to ensure future tags don't end up broken. Danbooru is much looser than most systems in its naming restrictions, but perhaps we should restrict the use of some characters to ensure proper operation?

Most importantly, we should be careful with symbols Danbooru actually uses ("*", "~", "-", ":"), and other characters, (such as "+" as I mentioned before) can cause problems with JavaScript in URLs). Some of these are being used without issue currently "-" as a medial hypen, ":" as a prefix in emoticons, so if we banned them entirely there could be issues. But perhaps we should have restrictions such as "-" can't be a prefix, "*" can't be used (as asterisks have semantic meaning anywhere), ":" can't follow a known metatag or perhaps must be a prefix.

I'm not sure exactly what we should restrict ourselves to, but it would be good to be unable to create tags that break Danbooru's operation.

There's already a restriction that - and ~ can't be used as a prefix.

It disappears, leaving the rest of the tag intact: "-tag-name-" becomes "tag-name-", and so on. Even "----~~~---test" is correctly trimmed to "test".

evazion said:
Even if you like the escape character idea it'd be trickier to do than you might first think. You could use backslashes to mark literal asterisks (as in foo\*), but that still wouldn't be able to handle the unlikely case of a tag having a name that conflicts with a metatag, such as source:foo.

Why not? source\:foo. Correctly done escaping mechanism can handle everything, that's the point. As for training people to use backslashes, it'd be somewhat (although not fully) relieved by it happening automatically when you search by clicking links.

I suppose that'd work. It's just that it seems unintuitive to me that you'd escape only the colon and not the metatag prefix as a whole. Although I guess it doesn't really matter how intuitive it is as long as it lets the site generate the right search links.

Another idea would be to have a 'literal:' metatag, so that literal:foo* or literal:source:foo are interpreted literally without extra parsing. It's not a true escaping mechanism since it doesn't let you mix wildcards and literal asterisks (ie, you can't say literal:*foo* with the first star meaning a wildcard and the last meaning an actual asterisk), but it would be good enough to handle the broken link problem. I also think it'd be a little easier for people to understand than backslashes.

evazion said:
I suppose that'd work. It's just that it seems unintuitive to me that you'd escape only the colon and not the metatag prefix as a whole.

Oh, I see. You're not a programmer I take it? http://en.wikipedia.org/wiki/Escape_character is what I and pretty much every other self-respecting programmer will think of when you say "escaping". The idea is that a single escape sequence takes out the special meaning of anything that follows, including instances of the escape sequence itself. Thus if you wanted to search for a backslash, you'd say \\.

I'd rather just strip them out in the future.

Looks like your patch only strips leading asterisks.