The easiest way is to prefix the title with $:/ putting it away from the standard search unless you use is[system] I have however come up with other ways such as using Unicode for the title, or creating new system namespaces.
$:/streams/numeric title
But some title-less tiddler are just userside tiddler, they are generated by quick-add plugins, so they have random hash title, but they are really normal user tiddlers. And [all[tiddlers]] should include them.
And I will create more quick-add plugins in the future, because I find they are handy for mobile use.
IMO _prefer_field: caption would do. So users can change it to _prefer_field: something
We only need to define the “fallback mechanism” eg:
_prefer_field is set to caption but_prefer_field is set to myField butSo the problem I have with _prefer_?? is, that I do expect a sensible fallback.
IMO the OP wants to _demand_field or _apply_field where we do not allow a fallback. Other verbs may be: 248 Synonyms & Antonyms for FORCE | Thesaurus.com
So if:
_demand_field is set to captionThat’s the way I would understand it.
I don’t quite follow what you mean here, sorry.
I will use this, hope community will follow.
From next month, command palette will not search for title, if the tiddler has the field _prefer_field.
Calendar will not show title, if so.
I will find a chance to PR it into the core, add this field to some tiddler, to consolidate the interoperability.
Go ahead and put your argument, but with all due respect I think it in unnecessary, and complicated and I would not myself like such changes.
It is not about my wiki, it is about the plugin developer’s consensus and plugin community’s interoperability.
Tiddlywik is not only a note book, it is an application develop framework, that works simillar to a local version of https://solidproject.org/
Another way to handle interoperability is to provide configuration settings in each plugin. For example allow the installer of a pluggin to configure the tag and field names used by the plugin.
This would allow one plugin to be varied to accommodate another.
We could provide some code patterns even automation to help plugin and solution designers do this quickly and easily.
I think 1 more config, there will be 1% more new user lost. New user don’t like config things. A good product should work out of box like Notion. This is why Notion comes late, but have a much larger user group.
Here’s my thoughts on this.
title field (it should still appear as a popup, or ?)System Tiddlers are defined as those that match the following prefix $:/. This encapsulates a few concepts that we can re-use. There is a “drive/volume” portion $: and a PathSeperator /. We should re-use these concepts.Streams tiddler, they come out as Streams/20240609224322659, Streams/20240609224322659/20240609224406918, etc, etc.Synthetic Dream Machine Role Playing Game System could be held at SDM:/characters/<<GUID>>, and the character name could be held in caption or subtitle, or petname, or ??, etc.Hi @joshuafontany you are late! People above was discouraging the use of prefix in title, but rather use a field _prefer_field for this.
I think if you want to reference the tiddler generator that generate the random-title-tiddler, you can add field source: Synthetic Dream Machine.
But adding this kind of a cascaded-title-view-template to the core is a good way to let us “have a standard ontology”, I will do this when this RFC is really sattle down.
Hmm. Completely machine-generated UUIDs, etc, as Titles means that we lose the “human readable” portion of the title field. I honestly think that many tiddlers should actually NOT be expected to be rendered directly in the story river, but rather transcluded into another “main” Story River Tiddler. BUT, we do use title as one of the main fields for search result lists, etc. We wouldn’t want to completely fill those lists with “hard to parse alpha-numeric strings”.
I second this statement. I also think tiddler titles should be human readable, because TWs main UI is created for humans.
If we need a machine readable ID it can be a field.
I think the _prefer_field field is be an option I can live with. If it is there and ignored, we are good. If it is used in story-river templates – it’s good too, if there is a fallback to the title
I don’t agree, your config can work out of the box and the ability to reconfigure it is so you can deal with edge cases or integrate with other plugins.
Keep in mind I am talking about providing a de facto standard for config settings designed to operate across solutions and pluggins rather than embedding it in the core.
I am relying here on a sophisticated understanding of the common factors and an evolutionary design approach to assist interoperability. I think this is within reach and would provide what you are looking for without reducing future choice but expanding it.
The title is the unique key to the data that is a tiddler. Either they are human readable or hidden from view and accessed via smart tiddlers that know how to handle the auto-generated titles.
What if it were _use_caption: fieldname for still more flexibility?
Extending your idea @Scott_Sauyet the caption as a rule is transcluded, meaning it is wikified. Thus the content, can in effect be a redirect {{!!fieldname}}, a macro or function.
@jeremyruston Rather than a field=yes to display caption we can introduce a more general solution such as "display-title’ which is evaluated if it exists and replaces the title. It can have a value, wiki text, function etc… including to say use the caption field.
I have a preference to set such things programmatically, not by an on tiddler setting. For example testing a field such as object-type which then determines if an alternate title is displayed. In some cases the “type” field is sufficient.
This is just “Layout” feature. Many of my plugins already use new layout to display tiddlers with random title. For example:
And when you open it on the standard layout’s story, it will show caption due to a view template cascade.
@TW_Tones While my command palette can ignore title field when search tiddlers with _prefer_field field, but to add this to default search, It should be a standard in the core wikitext in empyt edition.
TidGi already do so, it preconfig many things, and with 70+ preinstalled plugins, and it give Chinese Tiddlywiki communtiy 1000% grouth during 2 years. Before it, many people think Tiddlywiki is very hard to use, with many things to learn, and is even worse than Obsidian in difficulty to configue things. But this is the topic for How to stimulate User Growth of TW?
Yu need only modify the fields in $:/core/ui/DefaultSearchResultList to include an additional field in the search [!is[system]search:title<userInput>sort[title]limit[250]] nbecomes [!is[system]search: title<userInput>sort[title]limit[250]]
Have you considered using the existing mechanism Customising search results along with a title cascade? Both can be added without touching the core.
My personal view is your proposed change is too much while affording little. I believe we can do without it and use existing mechanisms when needed, or if a change is to be made make a much more versatile change,
