Tag Sets

_tagRefs doesn't know that space and dash are equivalent: Noticed in the Period Games Space. If, say, an External Link points to "Byzantine-Chess", the Byzantine Chess page's _tagRefs doesn't catch it. This is presumably because _tagRefs doesn't know to normalize spaces in link names.

Add Smart Tags feature (tags implying other tags): In most tagging systems, some tags will always accompany others - eg, if I'm tagging my URLs, and one tag is "Eclipse", that URL should always additionally be tagged with "IDE", "programming", "Java", "Java SDK", and about a dozen other things. It would be lovely to be able to specify an "Implied Tags" Property on a Tag Thing, and have it Just Work. (Ideally multi-level, so if X implies Y and Y implies Z then X implies Z, though that's obviously more work.)

Can't input a Tag whose name is a subset of an existing tag: As an example, the Features has an existing Tag "Tag Sets". I can't create a new Tag named "Sets".

Creating a new tag by itself fails on mobile: Needs further examination, but something seems broken.

From a Tag / Link Set Editor, I can browse the options: Currently, we have an annoying drop-down for single Links, and a prompting input for Tags. But we really should have the prompting input plus a way to ask, "Remind me what all the Features are, again?".

I can *easily* enter an existing hierarchical Tag: That is, if I have already defined the tag Clothing/Dresses/Long, I should be able to enter that by typing, eg, "cl/dr/l", with the system auto-prompting for each level separately.

I can define a hierarchical Tag: This used to work, but got broken along the line. Get it working again, and create some improved UI for it.

I can query a higher level of a hierarchical Tag: In other words, if I have an existing Tag hierarchy, containing "Clothing/Dresses/Long", I can navigate to "Clothing/Dresses" and that will include everything in the sub-categories.

I should be able to change an Old Tag Set to a New Tag Set: It is a major hassle for Spaces that have existing Tag Sets to not be able to switch them over easily. This Space is a good example: I want to be able to switch the Features Tag over to New Tag Set.

I should be able to define hierarchical, slash-separated Tags: This has always been part of the design, but it is hard to implement in Manifest. But what with Heather possibly wanting an Inventory Space, it's time to make it happen.

I should be able to rename a Tag: This is one aspect of the general Curate Tags feature, along with being able to merge Tags. But this one's the highest priority.

I should be able to specify that a Set contains at least one element: This is similar to the new notion of Required -- the page should provide feedback if you don't fill it in.

I should be able to specify the number of characters required to cause auto-filling in Tag Set: Currently, Tag Sets prompt you with auto-fill options after three characters. In Eric's use case, he would prefer that to be two, since the number of possible options isn't very large.

I should be able to turn off the input for a Manifest: This has been driving me crazy in my Shopping Space for ages. I want a checkoff only Manifest.

I should have a better UI for a *single* Tag/Link: We have this lovely auto-completing UI for Tag/Link Sets. But the UI is primitive and sucky for a single Tag. There really should be a way to do this better.

If I navigate to #!.-1, I get nonsense: That button should probably go away in general, but check first whether there is a more general bug to look into.

It is sometimes too difficult to remember my options in Link/Tag Sets: When there are more than a modest number of Tags/Links to choose from, the Manifest UI on its own becomes hard to use -- the solution space is too large, and it's hard to remember the name of what I'm looking for.

MarcoPolo should clear its cache any time we refresh the page: This is a really annoying bug, especially if working multi-window. If I change the backing data, MarcoPolo's internal cache doesn't get updated until I reload the entire effing client -- refreshing the page isn't good enough.

On the default Space Page, merge Things and Tags: By default, a Space's front page shows the hierarchy of all Things, followed by lists of the Tags used for each Thing. Having the two separate lists makes sense from a programmer's perspective, but from a typical end user's viewpoint it's just confusing. These two lists should be merged.

Tag Models shouldn't show in the Things section, by default: Currently, in the default Space Root page, we show all local models. This includes Tag Models, as well as Choice Models. It probably shouldn't show either.

Tagset Properties restricted to the same Model should use the same "pool" of tags: If I have two different properties, each of which is a Tagset (or Optional Tag) restricting to the same Model, they should share a "pool" of Tags? (Ie, should tags entered into Property A show up in autocomplete on Property B even if unreified.)

Right now, they don't seem to.

Undefined Tag View from an App is used in preference to the child Space's version: That is, if the App Model defines the Undefined Tag View, and the child Space overrides it, the App version is still used.

Unhelpful error message when there are too many Tag options: This becomes obvious, now that I am dropping the minimum number of characters for Manifest prompts from 3 to 1. This means that we frequently get too many options back, which blows the Manifest maximum. The resulting error message is "Your search could not be completed at this time". It should be "Many possible completions -- please type more", or something like that.

Unreified Old Tag Set names show up with dashes instead of spaces: When I have a Tag in an Old Tag Set (the only Tag Set Type prior to 0.4.6), and I click through to its pseudo-page, the Title shows up with dashes instead of spaces.

We should do something more sensible with the default of Exactly One Tag: Eric stumbled across this: if you define a Property as Exactly One Tag, that all works fine -- but if you fail to enter anything, you get an ugly and problematic empty-name Tag.

_createButton doesn't work with a Tag Set Link Property: Specifically, in the Period Games Space, Game should be able to say External Link -> Games._createButton() and have it get populated. But it doesn't -- presumably because it only works with single-valued Links currently.

_showUnknownName doesn't seem to be including _tagRefs: When I click on a Tag (that isn't actually a Thing), the resulting page should show me all the references to that Tag. It doesn't seem to be doing so, at least in this example. Why isn't that working?

_showUnknownName should work on Models: Eric tried to apply _showUnknownName on a Model, expecting that all Tags whose Link Model was set to that Model should pick it up. That isn't how _showUnknownName actually works -- it was originally intended to just be Space-wide -- but it is an entirely reasonable expectation, and probably quite useful in complex Spaces that have several different Link Models.

_tagRefs can only deal with one tag, not a List of them: Turns out to even be known -- there's a TODO for this in the code

_tagRefs can't find tags on Properties or Types: Nothing fancy -- it's just not looking at them.

_tagRefs does not pick up on Link Name correctly: See The Church of the Fourth Star for an illustration. The Display Name is "The Church of the Fourth Star", but the Link Name is "Cult", and that is what's being used as the tag in the Factions property. Cultist points to it, and the link resolves properly, but the _tagRefs from Cult back to Cultist does not work correctly. Why not?

_tagsForProperty doesn't work for tags inside Model Types?: In the Cooks Space, note that Secondary Source._tagsForProperty is showing [](), so something is kind of broken.

_tagsForProperty doesn't work with New Tag Set: In the Add Property dialog, when I select a New Tag Set Property, it should list the existing Tags. But it currently shows an error message saying that _tagsForProperty can only be used on (presumably old) Tag Sets.

Ampersand in unreified tag is causing problems when indirected through a function: This is currently repro'ed in New MySQL Space with the "Branch & Claw" Tag, which fails to display its Page Header, while "Core Game" succeeds.

Ampersands in Tag name break _class:

Can't specify a Print View for unreified tags: I'm a bit surprised that this doesn't already work -- look into it.

Default Space main page only shows old Tags, not new ones: Look at my Songbook for an example. All of my mistakenly-created old Tags are listed, but none of the new ones.

Fetching a Property from an unknown name should result in an error: Currently, you just silently get None if you fetch a Property off of an unknown name in QL. But it's most or less always a mistake (most often because the name is a typo), so it should be an error.

Handling of unknown names in QL is inconsistent: This the the straw that breaks the camel's back for the current behavior of, There is no Thing named "Foo" -- might be a typo?

Hitting Delete from text-entry area in Tag Set can accidentally delete other tags: In particular, if I'm entering text, and I backspace too far, it can wind up deleting existing tags.

I can't delete my Old Tag Set Properties: In my Recipes Space, I have an "Old Equipment" Property, which is one of the Old Tag Sets. For the life of me, I can't get the damned thing off of my Things. Investigate this, and figure out why not.

I should be able to display a Tag's name *not* as a Link: You can currently display a Tag using ____, but that shows up as a link. How can you simply show its text?

I should be able to filter _tagRefs by Property: This is the motivating story for unifying _refs and _tagRefs. Currently, _tagRefs shows all Things that refer to this Tag, and there is no good way to filter that by Property.

I should be able to render a Tag as simple text: See this page as an example of why -- I want to simply use Tags in a header, without them being links.

If I use Tags in a Computed Name, I can make my Thing unreferenceable: See the recipe below, but Tags and Computed Name play really badly together at the moment.

Link lookup doesn't respect Computed Names: Found in the Comics Space, and not really surprising: Marco Polo link sets works with Name or Display Name, but not Computed Name.

Looking at an unreified Tag's Page displays a browser Error: For instance, look at the page for Internals in this Space. When you navigate to the page, you get a mysterious "Error" dialog.

Make Tag and Link Sets Display Name centric: Now that Display Names are taking over as the "primary" names for Things, we need to change the focus of Tag Sets. You should be able to safely give Display Names as Tags, and it should do the right thing.

Multi-word tags not linking right: See the "Common Tents" tag in the Lochleven Inventory Space. There are a number of Items pointing to it, but I can't find a URL that works.

Needs to be easier to add a new Tag: Currently, when I am adding a new Tag, there is no obvious way to say that I'm done. Enter doesn't do anything, and Tab goes to the next field.

Page Header doesn't work right with unreified Tags:

Plain Text values don't render as links: In theory, a Plain Text value is now exactly the same as a single Tag. But it doesn't have one of the most important and useful aspects of Tags -- it doesn't display as a link. (Also, if you go to the named Tag's page, it doesn't list this as a reference.)

Prompt for Tag / Link Sets overlap where you are typing: When you are editing a Tag or Link Set, and you begin to type a name, it helpfully prompts you with existing values to choose from. Unhelpfully, the prompt comes up over where you are typing, so you can't see.

Referencing a Property through a Tag doesn't work as expected: That is, if I say My Tag -> My Prop, that doesn't work even if My Tag is reified.

Reified Tags shouldn't be hard-instantiating Undefined Tag View: Specifically, when we reify a Tag from a Model, and then add a Default View for the Model, the Tag is now overriding it. That's wrong.

Single-valued Tag inputs don't save their values: If you define an ExactlyOne or Optional Tag, it looks like it works correctly, but it never actually saves.

Tag URLs are sometimes coming out wrong: See my Songbook. Click on any of the multi-word Composers at the bottom of the Space page -- the Referenced from is displaying as empty. This is because the URLs are messed up: they are showing as Name-styled URLs (with dashes for spaces), but should be Plain Text-styled URLs (with plusses for spaces). But click on one from a Song, and it works correctly.

Tags are showing with a Display Name of ".-1": Not sure what's going on, but it's got to be a regression due to the new Computed Name code?

Tags aren't displaying their titles correctly in the header: The header is consistently coming out as "-1". WTF?

Tags in ExactlyOne or Optional Tags are getting over-escaped: Showed up in the Cooks Guild Space, with Elinor Fettiplace's Receipt Book, which was coming up as "Fettiplace's".

Tags linked from QL behave differently from Tags linked from Properties: In particular, the Tag linked from QL (a) displays with dashes in its name, and (b) doesn't recognize if it is a Tag that has been defined elsewhere in a Property.

Tags pointing to Things don't go to the right URL: There is a deadly inconsistency between how Tags and Links are being URLified at the moment, and the result is that you can get inconsistent results, with a Tag pointing to what appears to be an undefined Tag page, but tweaking the URL reveals a real Thing.

When I create a backtag to a Thing with a Space in its name, the tag is slightly wrong: Noticed while working on the Period Games Space. When I create an External Page from, say, "Byzantine Chess", the backlink tag is to "Byzantine-Chess". This works as a link, but is not noticed in _tagRefs.

When I create a Tag or Link Property, I should be able to create the Model right there: Experience has demonstrated that one of the most annoying workflow bugs is that I have to first create the Model, then create the Tag/Link Property pointing to it. This needs to be unified.

When I reify a Tag and don't know the desired Model, I should be asked what Model to use: Currently we just create a Simple Thing in this case, and that's not necessarily right. We should ask in this situation.

When I reify a Tag with a Default View, that Default View is getting overridden: For example, when I reify a Feature in this Space, it doesn't come out looking like a Feature, because it is getting the Tag-style Default View.