Make navigation also open what is in the *thread* field

[twMat]

Here is an optional proposal to issue #3934 (i.e Request for Compound tiddlers). The following one is much more direct and has less implications - and I believe it should be very simple to implement.

Purpose: To simplify the creation and the editing of multi-tid texts, i.e where the order of the tids is critical.

Proposal: Remake the navigate mechanism to also open (navigate to) anything listed in the thread field of the tiddler. This field contains a filter.

I.e clicking a link opens the tiddler and, if the filter is non-empty, opens all tiddlers in the filter sequentially below the main tiddler. Viewport ends up on main tiddler.

The opened tiddlers bear no other linkage to the ; closing a tiddler only closes that one. Clicking the original title link again, repeats the process.

Results

• Linear documents are trivial to create.
• Internal order is trivial to manipulate
• Mostly avoids the need for "tiddler-internal links" e.g for local ToC's.

Implied programmatic needs

• New fold thread button.
• Some indication that a tiddler has a thread field. (One idea is a subtle icon next to the title link. Simple to achieve with the css :after pseudo element)

Possible follow ups, not in this proposal

• Style adjacent subtiddlers so to appear visually joined.
• Editions for Authoring and Outlining (finally!)

[pmario]

As per definition

Tiddlers are the fundamental units of information in TiddlyWiki. Tiddlers work best when they are as small as possible so that they can be reused by weaving them together in different ways.

Tiddlers should be usable in "different ways". So 1 tiddler can be part of several "threads" (stories), which imo invalidates the proposal. 1 "thread" field won't be enough and it can't be part of a tiddler.

We could use a mechanism, similar to the "$:/DefaultTiddlers", which already allows us to configure "startup" filters.

We would need to give it a different type. eg: text/tiddlywiki.vnd;type:story which would be similar to the $:/StoryList ... functionality, but it would contain some more fields, like: viewtemplate, edittemplate, history-list, and story-view

This type:story configuration tiddler gives us enough flexibility to create as many stories views as we want. ... So a compound tiddler is nothing more than a different story. ... If it is a different story, we would automagically have all the functions that the existing TW UI gives us today, without much coding.

The only thing we would need to create is some new View- and may be EditTemplates.

[pmario]

I've shown the possibilities here: https://youtu.be/iaevaODdKyA?t=442 to time mark 10:30

From the OP

... and I believe it should be very simple to implement.

If it's implemented in a hacky way, it may look simple. The problem is, it creates a plethora of conceptual incompatibilities, that will hurt in the long run. ...

IMO we need a generic way to deal with multiple stories. And a "compound tiddler" for me is a simple form of a linear story.

[twMat]

Tiddlers should be usable in "different ways". So 1 tiddler can be part of several "threads" (stories), which imo invalidates the proposal.

@pmario you're right, presenting the tiddlers separately is problematic and I can't believe I missed this aspect. Thanks for pointing it out.. I'm closing the OP.

I also like your thoughts on the matter. One question I have is that your ToC proposal, at least as you've previous described it, seem to concern a ToC widget rather than something built into the viewtemplates? As suggested in my OP here, I really like the simplicity for the user to merely state a filter in a field rather than forcing them to know about a particular widget and it's syntax. It is also easy to manipulate such a fields content remotely. What you mention here about the Default Tiddlers are more along those lines but I'm hoping it would be an even more standard tiddler field in the normal tiddler edit template so that we stick with the normal UI.

I have not paid much thought to tiddler types previously but is my guess right that they merely state what view/edittemplates that should be used?

A specific detail; I think it is nice if a compound tiddler can itself contain content that is shown above the other stuff.

[Jermolene]

Hi @twMat I think this is actually a vote for something we've discussed but I don't think is ticketed. The general problem here is that a lot of the fundamental behaviour of TiddlyWiki is locked up in "magic" widgets -- navigation, interpretation of the location hash at startup, actions on dropping a file. Now that action widgets are so much more powerful than in 2013 there is an opportunity to rewrite that logic as "action macros" that can be overwritten. I'll create a ticket to expand on the idea.

[Jermolene]

The new ticket is https://github.com/Jermolene/TiddlyWiki5/issues/3967