What's the standard way to not writing Title

#37

It should be easy enough to determine the ancestor tiddlers (ACT-1 and ACT-1-SCENE-2), although that would be easier still if you used a different character for the level separator than the in-name one, somthing like ACT-1/SCENE-2/BiLLINGS ENTRO. But it’s hard to determine the immediately prior tiddler. How could we know whether ACT-1-SCENE-2-ARTHUR EXIT or ACT-1-SCENE-2-COLEMAN ENTRO comes before or after ACT-1-SCENE-2-BiLLINGS ENTRO?

1 Like
#38

Ancestors matter. And clans.

#39

I am not sure what you are thinking here, I don’t touch or need to touch this cascade although I could choose to extend that, in my view this should always remain a choice for the user/designer of the wiki.

  • The features I mention can be implemented through an extra item in the existing cascade mechanism or using a view template.

The true way of detecting the previous title added is the created date.

  • If you done enforce your own naming standard that is appropriately sortable, then leverage created or use another filed to assist. As I have with journal-date and other methods.
  • I don’t think this should be a matter for GitHub, these are all available within the current hackability.
  • I already have a range of tools to choose how to display the title I have already shared, from the simple alt-title to masquerade.
  • If @linonetwo explains what he wants I will most likely give it to him “out of the box”
#40

I think there should be a standard cascade on the core, to show caption instead of title, when a tiddler is created with the standard way to not writing Title.

And maybe also provide a new param on action-createtiddler, to create such kind of no-title tiddler. Because this is a commonly used case in new layouts (no traditional Card tiddlers there).

And I want to collict opinion about what no-titie tiddler looks like, is it has a prefix like λ:/? Or have a field like _is_skinny?

1 Like
#41

Hi @linonetwo it’s an interesting idea to have a standard way to mark that a tiddler should have its caption displayed in preference to its title.

I think I would favour a field _prefer_caption looking for the value yes.

We also need to figure out how far this needs to go: there are many places where the core renders titles without using the view template title cascade.

#42

@jeremyruston From my point of view “caption” is the wrong field to show. As captions used at the moment they are short. Titles are not.

In the TOC-rewrite which is described at: TOC-macros Rewritten (+ a lot of new fuctionality) - Part 2 I did allow the TOC macros to select a captionField which should be used instead of caption.

If captionField does not exist or is empty, it falls back to “caption” and to “title” if needed

In my own wikis I do use a field named: subtitle that can be shown as a title in a ViewTemplate.

My uni-link plugin allows link shortcuts that show caption, subtitle or any other field-name alongside case insensitive aliases to be shown in pretty-links.

So showing caption as the only alternative title in a core view template is not generic enough. It’s specific to linonetwo’s usecase.

4 Likes
#43

Another usecase friends, is decide the field to search.

If it is a title-less-tiddler, then search programs like command palette (I’m building a new one!) shouldn’t search in the title field, otherwise it is only work against a meanless hash, and return lots of false positive results.

As a product designer, I don’t want plugin user to fill a config like “prefix to ignore” or “if it has this field then ignore title”, so I will need a standard for this.

#44
  • If it is title-less-tiddler:
    • only show sub-title
  • else
    • show title and sub-title sideby side

So a field or prefix to know it is title-less is still worthy.

But for people who like subtitle or alias, I agree _prefer_caption might not be a good field name. How about _hash_title.

#45

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.

  • With Streams I get the title to be behind a prefix eg $:/streams/numeric title
  • I can to this my modifying my alt-title solution very easily.
#46

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.

#47

IMO _prefer_field: caption would do. So users can change it to _prefer_field: something

We only need to define the “fallback mechanism” eg:

  1. If _prefer_field is set to caption but
    1.1 caption does not exist → use tittle instead … Which would contradict the OP
    1.2 caption exists but is empty → use title
  2. if _prefer_field is set to myField but
    2.1 myField does not exist → go on with 1.1 and 1.2 if needed
    2.2 myField exists but is empty → go on with 1.1 and 1.2 if needed

So 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:

  1. _demand_field is set to caption
    3.1 caption does not exist or is empty, we show nothing.

That’s the way I would understand it.

1 Like
#48

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.

1 Like
#49

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.

  • I can solve your problems raised with the current core, and you can introduce your change to your wikis and not touch the core.
#50

It is not about my wiki, it is about the plugin developer’s consensus and plugin community’s interoperability.

See Suggestion for all Plugin developers about field name: Let’s use Ontology to maintain 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/

Idea - Turn TiddlyWiki into modern HyperCard?
#51

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.

#52

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.

#53

Here’s my thoughts on this.

  • Autogenerated titles should have a standard ontology (way to name things)
  • A standard method of displaying emphasizing an alternate field in the “title-area of the tiddler-card”, while deemphasizing the literal 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 plugin uses this , i.e. if you start a stream of notes from the Streams tiddler, they come out as Streams/20240609224322659, Streams/20240609224322659/20240609224406918, etc, etc.
  • If you need to declare a “Namespace”, then use the “Drive/Volume” pattern.
    • Example: All charactersheet data for Characters in the 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.
#54

A post was split to a new topic: How to automatically name ChatGPT and Gemini conversations

#55

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.

#56

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”.

2 Likes