What's the standard way to not writing Title

After my wiki reach 26k tiddlers after importing Evernote, there are many image tiddlers with hash in title, so search will hit them every time.

If you have enough random titles, you can’t stop search feature hit them, because any word can be included in some hash.

So by prefix the title with λ:/, you not only mean

  1. title is auto generated
  2. don’t show them in official Recent tab
  3. Official View template don’t show it as title. If no caption find, just show nothing.

But also mean

  1. Don’t search this title

@linonetwo my first reaction to this is to just make use of the $:/ namespace, even further qualified to $:/evernote/tiddlername however if you want to use another namespace it is a matter of making changes in various places to achive the equivalent. For example;

  • Modify the standard search to exclude tiddler prefix[λ:/] from the search
  • Modify the recent tab to not show them either

However I would favor importing, or export the then import the tiddlers within a plugin then they will be shadows unless modified, and will not appear in search results, and it will be possibly for you to determine if they have being changed since import.

  • You may have to include [all[shadows_tiddlers]] to list such tiddlers going forward.

The way in which tiddlywiki treats the system namespace differently is deeply interwoven into tiddlywiki’s core and not easy to replicate but it is possible. For example you could create a new filter operator (now a custom one) that works like is[system] such as is[lamda]

  • However as far as I can see you don’t need anything more than the system namespace eg $:/λ/ would work.
  • Use a title cascade to treat tiddlers beginning with your namespace differently.
  • I recommend you build something that allows this to be toggled on and off because it could compromise tiddlywikis operation, at least for your own design effort.

Thanks, though λ:/ looks simpler, If I encounter too much trouble building this, I will try $:/λ/ instead.

That’s true, hiding things could make user coufuse, then user may need to toggle it off to debug.

And I actually want to modify code in GitHub - Jermolene/TiddlyWiki5: A self-contained JavaScript wiki for the browser, Node.js, AWS Lambda etc. , not in my own plugin or wiki, so there can be more plugin appear, that allow user not writing title.

I see, you already discuss it in Simplest way to make missing tiddlers display:none or visibility:invisible? - #34 by TW_Tones

I am still not sure what you mean titleless.

Do you mean use a generated title but dont display it?

  • if so I can do it for you but I think there is a better approach.

Yes you can follow those other instructions but I raised the developer thread with a review to extending the hackability to allow new namespaces. Hows your javascript? Perhaps you can help me?

[Edited]

If I return to your question at the top of the post, I have already used the custom naming of streams tiddlers to hide them by changing the configured naming standard from something like tiddlername/numericsubtiddler to $:/streams/numericsubtiddler.

  • This way all streams tiddlers are under the same prefix and hidden as system
    • the only way we know where the master tiddler is, is in the listfield in each tiddler.

I love streams but not set it up or used it recently.

I set $:/config/sq/streams/new-node-title in
settings > Steams settings > Template wikified for node title to

<<stream-root-title>>/<<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">>

Streams plugin is an example. Another example is Health tracker plugin (buff & debuff tracker) as a layout (mini fullscreen app), it will create new tiddler with random title, and ask user to input a caption. So two illness record can have same caption (you may get a illness 2 times)

This kind of tiddler with random generated title is “titleless tiddler”. I just hope there can be a standard way to represent it, for example, use a system namespace for them.

On Reflection this Topics title could be “Automatic Titles”, so you don’t need to name them. Streams is an example of automatic titles that are hidden, in some ways they are titleless, but not really. The fact is something like streams could have stored data in a data tiddler, and not even used titles, however it did use titles to make use of other features of using independent tiddlers.

There are other ways to handle the same or similar issues with titles, for example;

  • a button you use for new tiddlers may appear on project tiddlers and create new tiddlers with “projectname task N” where in is incremented. You don’t have to change the titles as they are somewhat meaningful, as they are.
  • An existing example of automatic titles in TiddlyWiki is the new journal button. It creates a new tiddler according to the pattern in “Title of new journal tiddlers”.

I am not worried about naming titles, especially ad hoc ones, but I have noticed some are reoccurring, and in some cases, I can reuse or update the existing tiddler, but in other cases I simply want to make the title unique.

  • For example “go shopping” is going to reoccur many times, it makes sense to reopen this and use it again, rather than creating a new tiddler.
  • But there are others that are reoccurring, where you want a unique title, for example let us say everyday you attended a “Change Management meeting”, one way to make this unique is to add a date to the title (like Jounals) eg: “Change Management meeting 13/05/2024”

I have been investigating an enhancement to provide a suite of tools on creating new tiddlers, or editing their titles which allow the user to select from a set of ways to make a title unique. For example;

  • Date and or date time stamps
  • Unique number available eg next free number like current new tiddler
    • Or a universally unique number
    • Or a domain, project unique number
    • Any other useful scheme or context information
  • One approach is to move the new tiddler button onto the New tiddler View template where we can also have access to context information. Eg, Adding task in a contect tiddler, may include the contacts name.
  • Another approach is to manually add a suffix that indicates something about the title that will change later like end with a ?, but soon after you find the answer and give it a new title.

IMO naming tiddlers is always context specific. So I’m pretty sure, there can be no “standard way” for naming tiddlers. Eg: For streams I personally do not use system tiddlers. For me they need to be visible. That’s why in streams, there is a configuration section, that allows users to define, how titles should be created.

1 Like

I hope there is only one approach, so developers can share same infra.

For example, the heading cascade that show the caption instead of title. If developers use different approach, how do you wirte the cascade filter?

I already done this in at least 2 plugins, each with its own cascade. If there is an standard, we can provide it in the core. And making concensus is what the core team should do, other things can be done by plugin authors.

Right!

As TW has evolved so have “contexts”.

I have a specific case on my mind that I’m not sure is for here of for another thread?

  • – I wrote three tiddllers named …
    ACT-1
    ACT-1-SCENE-2
    ACT-1-SCENE-2-BiLLINGS ENTRO

These are IN the Story River.

Q: IF I create a new Tiddler immediately after “ACT-1-SCENE-2-BiLLINGS ENTRO” can it detect what the immediately prior title was?

Maybe this is too complicated?

TT

1 Like

The “New Here” button can detect the tiddler title, where it was clicked on. Every toolbar button can do this.

So if you have a closer look at the code in : $:/core/ui/Buttons/new-here you can define the new tiddler title in a similar way as new-here uses the current title as a tag.

hope that makes sense
-m

1 Like

There is no heading cascade which shows the caption instead of the title at TW-com atm. See: $:/core/ui/ControlPanel/Cascades

IMO that’s a different topic than the thread title: What’s the standard way to not writing Title and as you started in the OT.

So how to show a tiddler title in the story river should be a new thread. IMO it should be possible with the current cascade mechanism.

You will probably need to create new view template elements.

If you want to change the current layout, you’ll probably have a better chance to write a proposal at GH.

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

Ancestors matter. And clans.

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”

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

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.

@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

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.

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