What's the standard way to not writing Title

We can add a cascade for it, for a plugin to modify it. Or we can adapt it in the core.

This is acceptable I think, and somehow better than a random title! It clearly shows this tiddler is deliberately lacking the title.

1 Like

I’m curious to see your final solution for this. Please share. :slight_smile:

This whole issue of naming tiddlers is quite an interesting one, for many it seems a problem, for others not a problem, and others an art and we can’t seem to document it as a rational set of instructions, for all possible use cases.

  • Feel I have no outstanding issues with tiddler titles, across many example use cases and perhaps one day I will write and compile a guide.
  • I have shared alt-title, a tool to get one tiddler to masquerade as another in these forums.

hmmm, We usually show the “caption” or the “description” field if titles have a special meaning. …

Captions and descriptions imo would fit, but the text of a tiddler usually has several lines. So I personally don’t want to show them in the recent tab or any other list instead of shorter titles.

So from my point of view this is a very specific usecase and should be a plugin.

If it is problematic for plugins to modify list-item-templates, I would suggest, that we improve that mechanism in the core. So every usecase can benefit from that improvement.

In TW the only thing which is needed to make a tiddler a thing is the “title”. So there will never be a tiddler without a title. So I think this tag would be confusing.

1 Like

IMO this thread is related to Need Help: List Item Template - Generate Reports and Making the list item template more hackable

Some quickly-written-down tiddler note may not have title/caption/description , only a short text.

For overflowed text, they can be hidden using CSS I think. I hope this can be in the core, if we have conclusion about the Official way to decided if tiddler should just show its text in the list.

I normally will write down a title. But I’m exploring a new usecase for mobile interface that requires fast write-down, and no time for a title!

User may filter the no-title-tiddler in the future, and readd the title, or organize these tiddlers.

Will we have trouble on this, if it is very long? Or contains formatting like !! xxx ?

Fishing Plugin use long title as question of flash card, I will ask @oflg about this.

What about risk for overwrites? Maybe a unique generated title is safer to use but hide it and show the content in its place?

hmmm, That makes sense, but I would not use CSS to shorten the text. A regexp, that gets the first eg: 30 or 40 characters of a tiddler may work too and keep the DOM slim.

I personally would want to have it configurable. The Recent tab uses the “timeline-macro” which only shows the title of a tiddler.

It also is a really old macro. Everything is hardcoded and it uses a really “ugly” subfilter parameter. …

So it would make sense to give it some love.

  • I have not come across a case when even a paragraph was too long.
  • The key limitation is no line breaks.
  • Yes punctuation can be restricted but you can write code that is tolerant, using """ as the outer delimiter but other plugins and solutions may not work well.
    • One approach is to have a process to move the title to the text and edit or generate a title later. After the note taking, a good time to review anyway.

If you have an edit-text field where you type a title into a temp location you can test this for existing tiddler titles and only show a save button if the title does not exist.

Once we have conclusion on a standard, we can modify the core To use caption or parts of the text Instead.

I Come up with a standard today that we can use λ or ∮ as prefix. (like the $)

Yes, i’m basically talking about generated title. We just need some metadata to know “it is generated” later.

And the code to get this metadata should be available in the core, So when we widely used this technique in the plugins. The Recent tab can still recognizing it.
And ensure we won’t use similar but different techniques in our different plugins.

@linonetwo I think the matter of generated titles is a much bigger picture than the one you describe and I am not sure this needs any core changes, or standards.

However perhaps a De facto standard would be enough.

  • For example a tiddler with a created date exactly the same as the modified date, or a blank modified date would be a good indicator.
    • Timestamps are off, or $timestamp=no in action create tiddler.
  • You may even be able to store information after a date stamp value that the date formats ignore. eg created set to 1006065047721 generated or modified set to 1006065047721 new - the moment you modify it this is replaced.
  • Date tools still seem to interpret them correctly.

Now if you have a batch generation process you can ensure your new tiddler obey the de facto rule. Otherwise I recommend using the standard practices like a basetitle with increments; eg Project name Task, Project name Task 1, Project name Task 2

The “Recent tiddlers” sidebar list output is generated by the <<timeline>> macro (see $:/core/macros/timeline).
This macro already has some infrastructure for customizing the output. Take note of the first few lines of the macro definition:

<!-- Override one or both of the following two macros with a global or local macro of the same name 
if you need to change how titles are displayed on a timeline -->

\define timeline-title() <$view field="title"/>
\define timeline-link() <$link to={{!!title}}><<timeline-title>></$link>

Thus, you can create a tiddler (e.g., MyTimeline), tagged with $:/tags/Macro, containing something like this:

\define timeline-link()
<$link/>
<pre style="margin:0 1em;font-size:80%;line-height:1em;color:initial;white-space:normal;">
<$let excerpt={{{ [{!!text}split[]limit[100]join[]] }}}><<excerpt>></$let>
</pre>
\end

The result is that the “Recent” sidebar list will show each title, followed by a 100-character excerpt of that tiddler’s content.

A similar (but slightly more involved) approach can be used to customize the search results output.

  • Start by cloning the $:/core/ui/DefaultSearchResultList tiddler.
  • Give it a new title (e.g., MySearchResults)
  • Change the caption field to something like Excerpts
  • Completely replace the text field contents with:
\define searchResultsExcerpt()
<pre style="margin:0 1em;font-size:80%;line-height:1em;color:initial;white-space:normal;">
<$let excerpt={{{ [{!!text}split[]limit[100]join[]] }}}><<excerpt>></$let>
</pre>
\end
{{$:/core/ui/DefaultSearchResultList}}
  • Then, edit the shadow tiddler $:/core/ui/ListItemTemplate
  • Change the text field contents from:
<div class="tc-menu-list-item"><$link /></div>

to

<div class="tc-menu-list-item"><$link /><<searchResultsExcerpt>></div>

You will now have an additional tab displayed in the sidebar search results. The second tab (called “Excerpts”) will show the same lists as the $:/core/ui/DefaultSearchResultList, but with the addition of a 100-character excerpt of each tiddler’s contents.

enjoy,
-e

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.

  • I already have title tools that replace the real title with caption or alt-title.
  • Have you tried setting the caption field to {{!!text}} such that if current tiddler is valid, lists that use the caption field should do as you ask.
  • have you tried changing the streams filter that generates titles?. I tend to use system titles so they do not appear in recent lists.

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.