Different behavior, but perhaps-related — http://ainability.wagn.org/wagn/Walnut_frontyard_garden+land_holder (you can see what's in there with http://ainability.wagn.org/card/edit/Walnut_frontyard_garden+land_holder )

http://ainability.wagn.org/wagn/land_holder+*options

Tried to duplicate it with http://test.dwagn.org/wagn/a+User_or_Org but it doesn't happen there.

I know work has been done here, but it's very hard to see at a glance.

  --Ethan McCutchen.....Mon Oct 26 07:47:05 -0700 2009

What's not working?

  --Ethan McCutchen.....Tue May 04 16:32:59 -0700 2010

Don't recall what was up with crashes, that's not happening now.

I've rewritten the solution, it should be clearer now, and removed the inclusion syntax suggestion to a new idea.

  --John Abbe.....Sun May 09 00:35:22 -0700 2010

d'oh - inclusion syntax is part & parcel of this; merged it back in

  --John Abbe.....Mon May 10 15:26:10 -0700 2010

to clarify, this syntax is needed for default types on pointers to work using their current mechanism, but it would allow narrowing of default types in any inclusion situation.

now that I think about it, we could probably use commas as a separator, but it would mean that we need to use comma-less versions of the names. Since keys don't have commas, that should be fine...

--Ethan

That would mean Wagneers having to know to key-ify the names of cards with commas in them when they write this inclusion syntax by hand. Might be nice to have a single, always-used character to separate Wagn card names. We're thinking semicolons for implement textbox for Pointer input...

  --John Abbe.....Mon May 10 15:27:33 -0700 2010

they don't have to make it the exact key; they just have to take out commas. This is going to be true of inclusion syntax regardless. I kind of think we should separate on just about any non-alphanumeric character that isn't already significant in inclusions (like semicolons)

  --Ethan McCutchen.....Mon May 10 16:27:31 -0700 2010

by the way, I seriously doubt we'll ever have many comma-laden cardtypes.

also, we eventually want it to be possible to have slashes in canonical card names, it was just a rails issue that stopped us from starting off that way. Restricting characters in cardnames shifts the burden from wagneers to editors, which we definitely want to avoid.

  --Ethan McCutchen.....Mon May 10 16:29:55 -0700 2010

I'm all for allowing more characters. implement textbox for Pointer input will require either a character not allowed in names, or some other clever solution.

Not sure i'm getting what you're saying about taking out commas (or is it punctuation in general?) in inclusions. That works now; is it something we want to change, and if so why?

  --John Abbe.....Mon May 10 18:01:43 -0700 2010

no, it won't require a character not allowed in names. it only requires a character not allowed in keys. in fact, I think we should allow *any* character not allowed in keys to be the separator. that just means we have to use alphanumeric-only versions of the names (not necessarily the key).

I'm not talking about changing the handling of the card name part of inclusion syntax - just the parts after the pipe, like "type" (which is the solution we're discussing).

Point is that only really weird characters (like pipes) if any should be disallowed from cardnames, but that shouldn't mean that we build a syntax out of really weird characters.

  --Ethan McCutchen.....Tue May 11 13:46:24 -0700 2010

Perhaps related, it would be nice if cards added through the Pointer had their type set if one of the "or"s is a type, e.g. set created cards to type tag if the *options WQL is:

{"or": {"type": "tag", "referred_to_by": {"right": "tag" } } }

  --John Abbe.....Sun Dec 05 21:05:07 -0800 2010