But when you modify the text later, this won’t work.
For example, calendar entries, you may add details, or drag to change the time duration later (in tw-calendar plugin). And “quick memo”, that you only write down text, you may modify the text later.
I just hope every plugin using same rule, and core Recent tabs too, without need to customize it. So this should be a rule in the core.
To be honest I am not clear why you wanted these non titles. My suggestion would work for some use cases but clearly not yours.
Perhaps you mean automatic titles that have a caption or text displayed as if it were the title if the automatic titles is still in use.
I do not think this nessasarily should be in the core unless very well designed and usable in many ways, in part because its easy to introduce this only when needed with custom new tiddler buttons and a title cascade.
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
But also mean
@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;
prefix[λ:/] from the searchHowever 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.
[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]
$:/λ/ would work.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?
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.
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;
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.
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;
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.
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?
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
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
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?
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 true way of detecting the previous title added is the created date.
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?
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.