Previous Entry Share Next Entry
jducoeur wrote in querki_project
A lot of bugfixes today, and changes to continue the move towards being Display Name centric.

Display Unknown Names (tags) correctly again (bug .3y284t3): this one was just mysterious -- somewhere along the line, I apparently had a brainfart and broke _showUnknownName so that the page for a Tag stopped showing the references to that tag. Now fixed, which means that clicking on a Feature in the Issues Space now lists the Issues relating to that Feature, like this. (This has always been the intended behaviour of Tags -- by default, they should list all the Things that refer to them. That makes them a magnificently easy way to cross-reference your Things.)

Creating a Thing with a Unicode Name now goes to its page correctly (bug .3y284zg): I confess, I was pleasantly surprised that Unicode Names work at all (see this page for an example of a Name and Display Name in Cyrillic), but there turned out to be a bug in the Play! web framework that was preventing us from navigating correctly after creating or editing it. Hacked around that for now.

I strongly encourage folks to mess around with whatever languages you feel like, and register bugs if you find them. I assume that we don't work correctly with languages that do hard things like right-to-left, and I would be greatly surprised if there weren't additional bugs, but at least the basics seem to work.

Properties (and other things) losing their Names entirely (bug .3y284zh): this was a horrible new bug that Alexx noticed -- if you edited a Property (or for that matter, any other Thing that didn't have the Display Name Property at all), it would lose its Name, and wind up with nothing but an OID.

Fixed that, and established that, at least for now, Properties should usually have a Name, *not* a Display Name. This is the old behaviour, and makes sense given that Properties are mostly used in the context of QL, which can't cope with Display Names. (But might yet change -- see the enhancement below, to allow Display Names in QL.) For now, the Name now shows up in the Editor for Properties again.

Now easier to create a new Tag (issue .3y284za): Eric asked the entirely reasonable question, "How the heck do I create a new Tag without tabbing to the next field?". The problem is that Manifest, the third-party we are using for Tag Sets, defaults to using *comma* for the new-item-create keystroke. This makes a certain amount of sense if you think of it as being a fancy version of a comma-delimited list of tags, but it certainly isn't obvious. So I've tweaked it so that Enter now does the intuitive thing, as well as comma. (The implication is that you still can't have a comma in a Tag. I think that's reasonable, but I'd be interested to know what folks think.)

Backspacing through a Tag Set is no longer dangerous (bug .3y284zb): Eric also discovered, the hard way, that if you are typing a new Tag, change your mind, and backspace too aggressively, you could kill your existing Tags: Backspace (or Delete) would change focus from the text-entry field to the last Tag, and then delete the last Tag and back up to the previous one. I think this was probably deliberate in Manifest, but it is too aggressive for my tastes. So I split Backspace from Delete. Backspace now changes the focus to the previous Tag (just like left-arrow), but does *not* delete. Delete deletes the currently-highlighted Tag, but then sets focus to the text area, so it doesn't multi-delete so easily.

I think this is a good balance: deleting existing Tags isn't *too* hard from the keyboard, but now requires an extra keystroke.

I can specify a Display Name in QL (issue .3y28507): I opened this issue, as a first step towards the more-important feature of being able to use Display Names as Tags.

This change is mostly going to be innocuous to most usage: in places where you've always used a Name in QL, to refer to something, you can now use the Display Name instead. This mostly means that some innocent and common errors will simply start to work. While I've always had good reasons for focusing on Name in QL instead of Display Name (and there are subtle traps you can fall into, especially if you have, eg, duplicate Display Names), it is something you wind up just intuitively wanting to do, so we might as well support it.

Note, however, that Display Names often aren't *legal* in QL -- in particular, if they contain punctuation, they're likely to break the parser. So I've added an important new language feature: backticks now work as a sort of "name escape", letting you put *any* Display Name in. So for example, the following is now legal for referring to a page by a Display Name that isn't otherwise legal in QL:
[[`This is the *display name* of my page, dammit!`]]
Note the implication, that backtick will probably become an illegal character in Display Name. (For now, it is legal but unwise.)

I expect that this is mostly going to be an edge-case feature for most purposes -- I still generally recommend using Name instead of Display Name in QL, simply to avoid cryptic errors. But it's going to be necessary to get all of the desired behaviour of Tags working.

Note that you can't use Display Names as Tags yet -- non-alphanumeric characters will still make things choke. I suspect that fixing this is going to require deprecating the current Tag Set Type and creating a new one; my apologies. (If so, I will try to do so in a way that leaves Properties of the old Tag Set Type intact using it. Unfortunately, automatically transitioning them may be more dangerous than it is worth, since the Types probably won't have compatible serialization formats.)


Log in

No account? Create an account