Right Form Must Match Case

Support Ticket

+status
+tags
 

Is this a bug or a feature.  I expected tag templates to match based on keys, not names.

Source of example

I already have a card: FlowPlace

I add: FlowPlace+*rform

I try to use it as

It doesn't use the rform

Use

 

Hrm. We're case-insensitive at the beginnings of words, but apparently not in the middle. I think this is a bug, will check w Ethan and Lewis...

 

(It's nothing to do with the rform, btw. See http://wiki.flowplace.org/FlowPlace vs. http://wiki.flowplace.org/flowplace )

 

--John


It's not a bug per se, it was a design decision. Should nowhere and NowHere be the same card? Maybe, but it's not obvious. At least three choices: (1) we get rid of spaces in keys altogether, (2) we treat mid-word capitalizations (WikiWords) as separations between words, or (3) midword capitalizations never separate words.

 

2 is what we have. 1 seems defensible. 3 sounds like a mess. I would hate for JohnAbbe and John Abbe to be two different cards. Question is whether it makes sense for McCutchen and mccutchen to be two cards, as it is now. maybe not.

 

Note: converting key algorithms is a messy procedure and not one to be undertaken lightly.

  --Ethan McCutchen.....Thu Sep 24 08:15:06 -0700 2009


Thanks, that's clear, and i will document it somewhere. document handling of WikiWords. Could links to JohnAbbe find John Abbe if it exists, and otherwise offer to create JohnAbbe?

  --John Abbe.....Thu Sep 24 11:38:35 -0700 2009


Yes, I think that's the current behavior. However, johnabbe (all lower case) would be a separate card.

  --Ethan McCutchen.....Thu Sep 24 11:42:22 -0700 2009


pretty much same issue as be case-insensitive mid-word as well

  --Ethan McCutchen.....Thu Sep 24 11:48:52 -0700 2009


Yeah, i created that in response to this support ticket. Will adjust it or delete it depending on what we end up with here.

  --John Abbe.....Thu Sep 24 12:43:53 -0700 2009


Sorry, i did not actually give the behavior i'm exploring. Could it be:

links to JohnAbbe find John Abbe if it exists, otherwise johnabbe if it exists, otherwise offers to create JohnAbbe

links to johnabbe find JohnAbbe if it exists, otherwise offers to create johnabbe

 

(Current behavior is that http://test.dwagn.org/wagn/RiTest does not find http://test.dwagn.org/wagn/ritest and http://test.dwagn.org/wagn/wrotest does not find http://test.dwagn.org/wagn/WroTest )

  --John Abbe.....Thu Sep 24 12:51:11 -0700 2009


Hmm. names either have the same key or not. Sometimes we call this being in the same "casespace", though it's kind of a clumsy parallel to namespace.

 

If you make a link to a name and there is a card with that key (that is, a card in that casespace), then it will link to it. If not, it will offer to create one with whatever name you're using.

 

There can only be one card within a casespace. We don't decide which name it has, but we enforce that there can be only one.

 

JohnAbbe and John Abbe are in the same casespace. RiTest and ritest are not, and nor are wrotest and WroTest. If we changed the key algorithm to get rid of spaces in keys, they would be. Make sense?

 

Does that clarify things at all?

  --Ethan McCutchen.....Thu Sep 24 13:25:06 -0700 2009


Yes, it tells me why my proposed solution would be a pain to implement. (I knew enough to have figured that out, but did not think it through.)

  --John Abbe.....Thu Sep 24 17:31:02 -0700 2009


Ok, so this does seem to be an artifact of Safari getting internally corrupted. I upgraded Safari and will file a bug on that if I manage to create the situation again ...

 

One thing I just noticed when I tried to post this comment and wasn't signed in. The screen can go haywire in a similar way when javascript is waiting for the server. Typically, I will see the "done" notice over the previous notice, and mousing over corrupts the screen until the server action is done. It may be that in my hung Safari tab, it was internally hung in network code. Or one thread of the browser was ...

  --Gerry Gleason.....Fri Sep 25 06:09:23 -0700 2009

 

Why is there so much space at the bottom of Basic edit windows?  BTW, it would help to have save, cancel and delete available on the top too.


eliminate extra vertical space in edit mode

  --John Abbe.....Fri Sep 25 09:12:51 -0700 2009


I think you can close this one. I understand the CamelCasing for keys, I think the origin of this was brokenness in my Wagn's cache and/or that other issue we found with templates which is ticketed seperately.

  --Gerry Gleason.....Sun Oct 04 05:21:08 -0700 2009