[TW5] Prevent the state of the Contents (TOC) SideBar from being saved? [Resolved]

[Hegart Dmishiv]

Is there a way to prevent the current state of the Contents (TOC) SideBar from being saved? I'd like the Contents menu to begin in the "collapse all" state whenever my TW wiki is first loaded, or when the page is refreshed using the browser refresh button, (such as after I've just saved the wiki to disk).

I've had a look through the control panel, but can't find anything that relates to this.

[infurnoape]

http://t5a.tiddlyspot.com/#Autocollaps%20TOC

Happy Connecting. Sent from my Sprint Samsung Galaxy S® 5

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7a482bc8-f229-4acd-9d68-1372e186d379%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mat]

I believe $:/core/save/all can be edited so it doesn't save tiddlers prefixed(!) with $:/state/toc/.

The prefix $:/state/toc/ refers to the temporary tiddlers created when opening/closing an item in a toc.

I'm not 100% sure of the above. I know the  $:/core/save/all is involved when uploading to TiddlySpot but it might not be involved in general saving of TW, I don't know. 

You might also wish to check a $macrocall to toc example to manually specify selected state tiddler. Maybe it is enough to prefix this with $:/temp because I think tiddlers prefixed so are not saved. This should probably be your first test actually.

Play around not in your actual TW. And please report how it went.

BTW, I find many of your questions very valuable. In spite of being new to TW, you have a clear idea of what you want (probably from your MediaWiki background - that was you, right?) and this seems to make you pinpoint very reasonable basic issues that highlight weaknesses in the UI and things that "old timers" probably take for granted or have just accepted and (mistakenly) aren't thinking about anymore (myself included).

<:-)

[infurnoape]

Resource: Single-file save should exclude $:/temp/... tiddlers #1199 (Jeremy Ruston 12/5/14)
Replace: -[prefix[$:/state/popup/]]

with: -[prefix[$:/state/]] -[prefix[$:/temp/]]

in: $:/core/save/all

Happy Connecting. Sent from my Sprint Samsung Galaxy S® 5

-------- Original message --------
From: Mat <matia...@gmail.com>
Date: 09/16/2015 4:20 PM (GMT-07:00)
To: TiddlyWiki <tiddl...@googlegroups.com>

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7781a694-d6af-4fc9-b97c-942cce051a96%40googlegroups.com.

[Greg Davis]

additional examples at: https://groups.google.com/d/msg/tiddlywiki/9SCm237WDJw/UIZuA2fGeN8J

[Hegart Dmishiv]

Thanks Andrew, Mat and Greg for all the replies. I'm obviously not the first person to ask this question, and I did try to search the forums first before asking, but I couldn't find anything that addressed just the state of the TOC, as Mat alludes to above.

I made the change (that Andrew linked to) in my dev wiki first, to see what would happen. I got a message saying...

You are about to edit a ShadowTiddler. Any changes will override the default system making future upgrades non-trivial. Are you sure you want to edit "$:/core/save/all"?

So let me make sure I understand what this means. Whenever I edit a system tiddler (shadow tiddler?) I'm going to need to document what I've done, so that when a new version of TW is rolled out, I can go back through my list of personalisations and re-apply them to the latest version. Does that about sum it up? Sorry, but, WTF?! I shouldn't have to alter the whole underlying system just to make a simple interface change. I'm going to end up with a huge list of personalisations to my wiki, and have to manage it, curate it, and reapply each one with copy/paste whenever a new version of TW becomes available. It would be far simpler to just go ahead and personalise my own copy of TW 5.1.9 and never upgrade it again! I assume thats why I see so many older copies of TW floating around online still, because its easier to keep personalisations than to upgrade, is that about right? I may be over-reacting to this, I often do. I have no experience with upgrading TW yet, so please let me know that what I imagine from that edit warning is not as bad as it seems.

@Greg: The link to Tobi's tiddler about States and Temporary Tiddlers comes with this dire warning:

Caution: Defining the wrong save-filter may have you unknowingly lose data!

As I'm still very new to all this, and don't really know the structure of the underlying TW system well, I'm probably better off avoiding that one for now. But thanks anyway Greg.

And thanks @Mat for your wonderful feedback, which I have posted to the Google+ TiddlyWiki community. I'm glad that my questions and observations are useful. Sorry if I seem like a grumpy old man sometimes, but that's me in real life, haha. That macrocall to TOC is going to be very handy, BTW. I'm currently using unordered lists on my tiddlers for linking to "sub-types", which of course are also listed in my TOC in the SideBar. While I'm building my knowledgebase wiki, having the static links on the tiddler is handy because I create the new tiddlers for the sub-types by clicking on redlinks (oh how I wish TW would identify missing pages with a red link, rather than italics, but I must remember that TW != MW). But once I have my wiki in a more complete state, I'll probably go back and make those static lists dynamic using the macrocall you linked to above.

[Evolena]

Le jeudi 17 septembre 2015 05:00:45 UTC+2, Hegart Dmishiv a écrit :

I'm currently using unordered lists on my tiddlers for linking to "sub-types", which of course are also listed in my TOC in the SideBar. While I'm building my knowledgebase wiki, having the static links on the tiddler is handy because I create the new tiddlers for the sub-types by clicking on redlinks (oh how I wish TW would identify missing pages with a red link, rather than italics, but I must remember that TW != MW). But once I have my wiki in a more complete state, I'll probably go back and make those static lists dynamic using the macrocall you linked to above.

Have you checked the Missing tab (sub-tab in the More tab) in the Sidebar?

You can also modify the CSS for missing link (there doesn"t seem to have a specific color palette for that).
[Edit] in the vanilla/base, the CSS is this:

a.tc-tiddlylink-missing {
    font-style: italic;
}

So you can create a new (system if you don't want it to appear in normal search) tiddler with the tag $:/tags/Stylesheet, and put that inside it:

a.tc-tiddlylink-missing {
    color: #FF0000;
}

And your missing link will be italic and red.

[Mat]

On Thursday, September 17, 2015 at 5:00:45 AM UTC+2, Hegart Dmishiv wrote:

Thanks Andrew, Mat and Greg for all the replies. I'm obviously not the first person to ask this question, and I did try to search the forums first before asking, but I couldn't find anything that addressed just the state of the TOC, as Mat alludes to above.

I made the change (that Andrew linked to) in my dev wiki first, to see what would happen. I got a message saying...

You are about to edit a ShadowTiddler. Any changes will override the default system making future upgrades non-trivial. Are you sure you want to edit "$:/core/save/all"?

So let me make sure I understand what this means. Whenever I edit a system tiddler (shadow tiddler?) I'm going to need to document what I've done, so that when a new version of TW is rolled out, I can go back through my list of personalisations and re-apply them to the latest version.

It's not quite that problematic and there is a very clever feature to this that I think you'll appreciate: 

When you overwrite a shadow tid, the original is kept! So if you delete your modified version, the original pops into place immediately. Try to delete a shadow tiddler and you'll see you can't. 

Upgrades do not overwrite your modified tiddler. Instead it is the underlying original that is updated. So, if you in the future delete your modified version, you get the latest update of the original.

That said, if you modify a shadow tiddler of course anything relying on that one gets implicitly affected. Just like anything else, if you "improve" your car by exchanging one of it tires, then of course it implicitly affects a lot of other things. 

Still, TW is extremely configurable. One can argue that the specific OP you bring up should be "brought closer" to the end user by having the toc state fetch it's value from some intentionally user manipulated field, like is done with e.g "Settings" in the Controlpanel. 

@Greg: The link to Tobi's tiddler about States and Temporary Tiddlers comes with this dire warning:

Caution: Defining the wrong save-filter may have you unknowingly lose data!

As I'm still very new to all this, and don't really know the structure of the underlying TW system well, I'm probably better off avoiding that one for now. But thanks anyway Greg.

Well, don't do you experimenting using your original TW and take a lot of copies. The warning states the obvious; be careful if you tamper with the filter that states what to save when the user clicks save.

 

And thanks @Mat for your wonderful feedback, which I have posted to the Google+ TiddlyWiki community. I'm glad that my questions and observations are useful. Sorry if I seem like a grumpy old man sometimes, but that's me in real life, haha.

<:-)

[PMario]

On Thursday, September 17, 2015 at 5:00:45 AM UTC+2, Hegart Dmishiv wrote:

I made the change (that Andrew linked to) in my dev wiki first, to see what would happen. I got a message saying...

You are about to edit a ShadowTiddler. Any changes will override the default system making future upgrades non-trivial. Are you sure you want to edit "$:/core/save/all"?

So let me make sure I understand what this means. Whenever I edit a system tiddler (shadow tiddler?) I'm going to need to document what I've done, so that when a new version of TW is rolled out, I can go back through my list of personalisations and re-apply them to the latest version. Does that about sum it up?

No in the contrary. What the message says is: Your content always wins. So if you update the core. Your changes stay. ... It's only to make sure, that you know, if a future core adds new functionality to a shadow tiddler, your tiddler / TW may not have this feature, since "Your content wins". ...

This message was very important since the TW beta phase, since the core functionality, UI features, and so on changed with every release. ... We had a lot of problems users reporting, that the new functions don't work with their TW, because they did overwrite the core tiddlers.

As Mat wrote. If you delete an overwritten shadow tiddler, the core will take over again. ... and that's one of the killer features of TW. If you mess up something, returning back to a working state is easy.

 

Sorry, but, WTF?! I shouldn't have to alter the whole underlying system just to make a simple interface change. I'm going to end up with a huge list of personalisations to my wiki, and have to manage it, curate it, and reapply each one with copy/paste whenever a new version of TW becomes available. It would be far simpler to just go ahead and personalise my own copy of TW 5.1.9 and never upgrade it again! I assume thats why I see so many older copies of TW floating around online still, because its easier to keep personalisations than to upgrade, is that about right? I may be over-reacting to this, I often do. I have no experience with upgrading TW yet, so please let me know that what I imagine from that edit warning is not as bad as it seems.

Calm down! As I wrote above. Your content wins.

have fun!
mario

[Tobias Beer]

Hi Andrew,

As a sidenote, not wanting to discourage you from exploring plugins,
I would advise you to consider not publishing this as a plugin:

New field inline list @ t5a

Your desired end result which I find a good choice for the field popup
can be achieved simply by adding the necessary css to a custom stylesheet tiddler.

Imho, using a plugin for this type of modification

blows the concept of plugins out of proportion.

If you desire to further discuss this, perhaps open another thread.
I just answered here as we were in the context of your short and sweet reference to
Autocollapse TOC @ t5a

Best wishes,

— tb

[PMario]

On Thursday, September 17, 2015 at 5:00:45 AM UTC+2, Hegart Dmishiv wrote:

@Greg: The link to Tobi's tiddler about States and Temporary Tiddlers comes with this dire warning:

Caution: Defining the wrong save-filter may have you unknowingly lose data!

As I'm still very new to all this, and don't really know the structure of the underlying TW system well, I'm probably better off avoiding that one for now. But thanks anyway Greg.

That's the downside of warnings :) They may prevent experimentation. 

With TW a user can change the UI and functionality in a way, that is not possible and allowed in other software. ... Our users can do what ever they want. And very often they do :) ... Sometimes they mess up some stuff. But fixing it, is as easy as delete the changed shadow tiddler, so the default (core) tiddler can take over again. ...

Everything is fine -> as long as you make some backups, prior to your experiments :)

----------- some more background info.

With TW we basically have 3 types of tiddlers.

 - standard tiddlers .. user content
 - system tiddlers .. start with $: .. hidden in standard lists
 - shadow tiddlers. .. defined by the core and plugins. ... you can overwrite them, but if you delete your changed tiddler, the will be magically restored.

If you
 - open eg: http://tiddlywiki.com/#HelloThere and
 - view the tiddler (i) info panel. It can be reached from the tiddler toolbar see the more dropdown.
 - select the Advanced tab
 - it shows:

Shadow Status

The tiddler HelloThere is not a shadow tiddler

 - open http://tiddlywiki.com/#%24%3A%2FAcknowledgements

 - (i) info: Advanced   shows

Shadow Status

The tiddler $:/Acknowledgements is a shadow tiddler

It is defined in the plugin $:/core

 - if you edit the tiddler it shows the "overwrite" warning

 - save

 - (i) info: Advanced   shows

Shadow Status

The tiddler $:/Acknowledgements is a shadow tiddler

It is defined in the plugin $:/core

It is overridden by an ordinary tiddler         <- this info is new.

So you know, if you delete or rename this tiddler, the default core/shadow tiddler will take over again.

have fun!
mario

[Hegart Dmishiv]

Thanks for the replies everyone.

On Thursday, September 17, 2015 at 8:12:07 PM UTC+12, PMario wrote:

That's the downside of warnings :) They may prevent experimentation. 

Oh, I'm all in favor of hacking up my stuff, don't worry about that. I maintain a completely separate instance of TW specifically for experimentation before I make a change to my main "production" wiki, and both "dev" and "live" are backed up regularly. I was just expressing my doubts about my own competence with TW so far, because I haven't experimented enough with it as yet to be confident that I understand the implications of what I'm doing yet. Gimme time to get to know TW a little more before I attempt something that is labeled as "could break something serious", haha.

Also, as much as I'm spending time learning the finer points of TW, I'm also working slavishly to enter raw content into my "live" version of TW, the plain content that doesn't involve any coding, just text, formatting, categories and links. I'm balancing my time between that and experimentation, beginning to explore the possibilities and limitations of TW.

[PMario]

On Thursday, September 17, 2015 at 10:26:20 AM UTC+2, Hegart Dmishiv wrote:

Thanks for the replies everyone.

On Thursday, September 17, 2015 at 8:12:07 PM UTC+12, PMario wrote:

That's the downside of warnings :) They may prevent experimentation. 

Oh, I'm all in favor of hacking up my stuff, don't worry about that. I maintain a completely separate instance of TW specifically for experimentation before I make a change to my main "production" wiki, and both "dev" and "live" are backed up regularly. I was just expressing my doubts about my own competence with TW so far, because I haven't experimented enough with it as yet to be confident that I understand the implications of what I'm doing yet. Gimme time to get to know TW a little more before I attempt something that is labeled as "could break something serious", haha.

IMO that's the right way :)
 

Also, as much as I'm spending time learning the finer points of TW, I'm also working slavishly to enter raw content into my "live" version of TW, the plain content that doesn't involve any coding, just text, formatting, categories and links. I'm balancing my time between that and experimentation, beginning to explore the possibilities and limitations of TW.

Yea,

The "hackability" of TiddlyWiki seduces many users to go deeper and deeper into customisation, instead of "just using" it :) ... You have to have content first, to see how categorisation makes sense. So refactoring the structure is very common with TW since the "big big" picture may be hidden at the beginning.

So keep on asking questions and try to document, what you've learned. As I wrote in an other thread. Newbie feedback is valuable but the "newbie" status goes away very fast ;)

-mario

[Greg Davis]

Glad you are getting answers from those with more knowledge, I just passed on what I had found in my own searches. I'm still hesitant to go hacking at the underlying core but most of what I wanted didn't require that so far. As for your concerns about being stuck on one version it is simpler to move changes to a new TiddlyWiki than you may have imagined. TiddlyWiki can store tiddlers in JSON files and import them.

It just requires tagging all the tiddlers that you change or add for your customization with a unique tag. Then use Advanced Search on Filter to select the tiddlers with that tag. You can then save that group of tiddlers as a JSON. That JSON can be imported to a new TiddlyWiki applying your customization. One of those tiddlers could be one where you documented your changes.

This also be applied to content that you might want to transfer. As long as it has unique tags for a group of content.

See: https://groups.google.com/d/msg/tiddlywiki/R5sSkEOCilQ/n6zZdSmmM98J

For more on JSON search here for that,
see also my brief example: https://dl.dropboxusercontent.com/sh/h8q01y5kygoyhch/AAB88H2CEZP_IAdzc1AJBYN8a/5-1-7_left-menu_custom.htm#Build%20json%20for%20multiple%20tiddlers

Good Luck,
Greg

[Hegart Dmishiv]

Tag the shadow tiddlers that I modify, as I go, huh? Brilliant. And simple. Thanks @Greg, I'll start doing that from now on. I have coloured all my system-related tags red, so they stand out from everything else. I now have one called modified-shadow and have tagged the $:/core/save/all tiddler with it. That's the only one I've changed so far.

Getting great advice like this, early on in my use of TiddlyWiki, is awesome. It means I don't have to go back and apply such changes to a whole heap of things I'd've already done.

[Evolena]

This information is already available on every tiddlywiki: go to the controlPanel, Info/Basics tab, there is a "Number of overridden shadow tiddlers" with an icon that leads to an advanced search filter.
Or there is a premade "Overridden shadow tiddlers" filter available in the Advance search by filter.

However, these filters also include all temp, state and config tiddlers, which may be noisy.

[Matabele]

Hi

Q&D solution: this button will delete the TOC state tiddlers:

<$button>
<$action-deletetiddler $filter="[search:title[$:/state/toc/]]"/>
Delete TOC State
</$button>

so will this:

<$button>
<$action-deletetiddler $filter="[prefix[$:/state/toc/]]"/>
Delete TOC State
</$button>

Action this immediately prior to saving -- or else you might prefer to construct a custom 'Save-Wiki' button, which includes this code:

<$button message="tm-save-wiki" param={{$:/config/SaveWikiButton/Template}} tooltip={{$:/language/Buttons/SaveWiki/Hint}} aria-label={{$:/language/Buttons/SaveWiki/Caption}} class=<<tv-config-toolbar-class>>>
<$action-deletetiddler $filter="[prefix[$:/state/toc/]]"/>
<span class="tc-dirty-indicator">
<$list filter="[<tv-config-toolbar-icons>prefix[yes]]">
{{$:/core/images/save-button}}
</$list>
<$list filter="[<tv-config-toolbar-text>prefix[yes]]">
<span class="tc-btn-text"><$text text={{$:/language/Buttons/SaveWiki/Caption}}/></span>
</$list>
</span>
</$button>

If you want to see whats going on, include this code at the top of your test tiddler:

<$list filter="[search:title[$:/state/toc/]]"/>

regards

[Hegart Dmishiv]

Yes, I figured that would be the case when I posted my first mini status report on Google+ and I saw that I had already overridden 7 shadow tiddlers even before I'd done the first one, as was suggested to me above by @Andrew. I guessed that those first 7 must have been related somehow to the generation of  the TOC. However, that can't be right though. Looking at that stat on my current live build right now, it shows 6 shadow tiddlers overridden, and that includes the one I know I did manually. So looks more like you're right @Evolena, it's just random state and config stuff happening in the background.

On Friday, September 18, 2015 at 5:45:03 AM UTC+12, Matabele wrote:

Action this immediately prior to saving -- or else you might prefer to construct a custom 'Save-Wiki' button, which includes this code:

<$button message="tm-save-wiki" param={{$:/config/SaveWikiButton/Template}} tooltip={{$:/language/Buttons/SaveWiki/Hint}} aria-label={{$:/language/Buttons/SaveWiki/Caption}} class=<<tv-config-toolbar-class>>>

<$action-deletetiddler $filter="[prefix[$:/state/toc/]]"/>

<span class="tc-dirty-indicator">

<$list filter="[<tv-config-toolbar-icons>prefix[yes]]">

{{$:/core/images/save-button}}

</$list>

<$list filter="[<tv-config-toolbar-text>prefix[yes]]">

<span class="tc-btn-text"><$text text={{$:/language/Buttons/SaveWiki/Caption}}/></span>

</$list>

</span>

</$button>

Wow, that looks awesome @Matabele, but I wouldn't even know where to stick it yet to make it work. It does seem to be a better, more specific solution than the one I'm using at the moment, suggested by @Andrew, which, as @Mat pointed out, prevents anything from $:/temp/ and $:/state/ from being saved, which could have unintended consequences. I'd like to try using your suggestion, but where do I put it to make it work?

[Tobias Beer]

Hi Hegart,

 

It does seem to be a better, more specific solution than the one I'm using at the moment, suggested by @Andrew, which, as @Mat pointed out, prevents anything from $:/temp/ and $:/state/ from being saved, which could have unintended consequences. I'd like to try using your suggestion, but where do I put it to make it work?

Just to be clear, my warning...

Caution: Defining the wrong save-filter may have you unknowingly lose data!

...was put there because at first I was using the filter prefix[$:/temp], and at the time I had a bunch of $:/templates/my-special-template tiddlers, so along any temp tiddlers they were also not saved and consequently gone, hence the warning of being well aware and precise of how to construct the save filter.

What I was not suggesting was that it should be unsafe in any way to remove any tiddlers prefixed $:/temp/ or $:/state/, which it should not, unless someone is using these namespaces for the wrong purposes ...so, I am doing that by default on tb5.

Best wishes,

— tb

[Matabele]

Hi Hegart

For this example, I shall assume you wish to create a custom 'Save Wiki' button (which deletes the TOC state tiddlers and saves the Wiki):

1. Open a New Tiddler

2. rename this tiddler to something like: $:/_Buttons/SaveWiki

2. Paste this code into the tiddler:

<$button message="tm-save-wiki" param={{$:/config/SaveWikiButton/Template}} tooltip={{$:/language/Buttons/SaveWiki/Hint}} aria-label={{$:/language/Buttons/SaveWiki/Caption}} class=<<tv-config-toolbar-class>>>
<$action-deletetiddler $filter="[prefix[$:/state/toc/]]"/>
<span class="tc-dirty-indicator">
<$list filter="[<tv-config-toolbar-icons>prefix[yes]]">
{{$:/core/images/save-button}}
</$list>
<$list filter="[<tv-config-toolbar-text>prefix[yes]]">
<span class="tc-btn-text"><$text text={{$:/language/Buttons/SaveWiki/Caption}}/></span>
</$list>
</span>
</$button>

4. Save the tiddler

5. This tiddler may be transcluded wherever you wish to place the button -- like so:

{{$:/_Buttons/SaveWiki}}

You may wish to replace the existing 'Save Wiki' button with your custom version. In this case we need to tag your new '$:/_Buttons/SaveWiki' tiddler with the $:/tags/PageControls system tag -- then delete this tag from the old '$:/core/ui/Buttons/save-wiki' tiddler (to avoid having two buttons.)

1. To create a toggle for your new button -- place this code into a New Tiddler, name it what you wish, and save:

<$checkbox tiddler="$:/_Buttons/SaveWiki" tag="$:/tags/PageControls">Toggle Save Wiki Button</$checkbox>

2. To toggle the old button -- open the 'Tools' sidebar tab and use the 'Save Changes' checkbox.

regards

[Hegart Dmishiv]

Hi @Tobi,

On Friday, September 18, 2015 at 9:06:53 AM UTC+12, Tobias Beer wrote:

What I was not suggesting was that it should be unsafe in any way to remove any tiddlers prefixed $:/temp/ or $:/state/, which it should not, unless someone is using these namespaces for the wrong purposes ...so, I am doing that by default on tb5.

Ah, okay, thanks for explaining that. I really am new to all this. I haven't even got the foggiest idea of what normally would go into $:/temp/ or $:/state/ yet. I assume it's like the /tmp folder of my Linux OS, the contents of which are pretty safe to delete unless they are very recent, and they get purged automatically anyway on logging out of the session. Does $:/temp/ get purged automatically at any stage in TW?

Ooh, $:/templates sounds like a nasty trap. Something I saw somewhere (I can't even recall who suggested it now) mentioned naming personal templates as $:/_Templates/template-name and that will put them all at the top of the list of system tiddlers. I see you're now using $:/.tb/templates/template-name which also appears to achieve the same thing, but in a more hierarchical format. Knowing tricks like that, again, is really helpful to me as a new user. I assume I will be also creating $:/_Macros/ and $:/_Styles etc similar to your system folders, once I get more proficient with TW. (EDIT: As I was typing this, @Matabele posted in the thread, mentioning  $:/_Buttons/, so that will be another one to consider.)

I might just have a go with both yours and Matabele's suggestions in my dev implementation of TW, one at a time, just to learn more about how they work. It looks like your States And Temporary Tiddlers tiddler answers my question above about where to put Matabele's solution. It'll be going into a new personal template like yours does, right? So I'll try each, one at a time. No doubt they both achieve the same result, just going about it different ways. A great learning experience for me, thanks both of you.

BTW, if anyone's wondering, I've decided to standardise some of my own language as it refers to TW, for instance, I use "personal" and "personalise" normally, rather than "custom" or "customise", which I reserve for hacks that actually make changes to the underlying system. If it just involves a shadow tiddler, or a user setting, then I am personalising my version of TW. If it is something that I might suggest as a commit back to the community code or documentation, then it's a customisation. I'm not suggesting that this language gets widely adopted, I'm just explaining that this is what I'm doing.

[Evolena]

It still may lead to a lose of data. I've experimented it once. A syntax error that causes the filter to match nothing, and you end with a nearly empty file... So backup every time you change the save-filter!

[Tobias Beer]

Hi again, Andrew,

 

I would advise you to consider not publishing this as a plugin:

New field inline list @ t5a

I guess I'm not too sure of the nature of plugins, after all.
I mean, can a small ui customization be a plugin? Sure it can.
Do people want a plugin for that or just drag over a stylesheet tiddler? Their choice.

So, what I actually wanted to say was:
You can achieve your desired effect purely with css,

so there's no need to add any new component templates or overwrite existing ones.

I imagine you have left the core one untouched so as to show the difference,

but in the end, if one wanted the change, one wouldn't want the core component as it was.

Best wishes,

— tb

[Hegart Dmishiv]

Hi @Tobias,

You've posted twice now in this discussion thread about New field inline list @ t5a and I still don't know what you're on about, sorry. Does it pertain at all to my question about not saving the state of the TOC, or is it entirely OT? Sorry, with my current lack of understanding of TW, you could be explaining something relevant that is going completely over my head, so I thought I'd ask.

Hegart.

[Tobias Beer]

Hi Hegart,

Those two were off topic with regards to your OP.
Sorry for any confusion... will mentioned next time.

Best wishes,

— tb