First I would like to reserve the name Ghost tiddler for this specific application, or if not adopted my own use later.
Background
Folks an often used mechanisium by plugin and solution designers and even in the core, is to use an external tiddler to store information such as the visibility toggle for editor toolbar buttons.
That is we have a tiddler, usualy a system tiddler which as part of its title is a target tiddlername. When listing or displaying the tiddler we can construct the title and test if it exists and/or has a value.
This is essential if we do not want to edit a shadow tiddler
Limitations with above
Solutions that establish such a mechanisum can not easily see if others are doing something similar.
This creates a proliferation of tiddlers to store very simple information, often a binary yes/no, true or false. Athough usualy hidden behind a system tiddler.
This often results in long tiddlernames which themselves consume more bytes.
Because we have no idea of the tiddler naming conventions, different plugins and solutions use, we dont know about each other and it makes it hard to cache such lookups.
A possible solution RFC
The idea would be to provision a ânamespaceâ such as â$:/ghostâ (I may have used shadow had it not already being used) and when needed a user or solution could test for or create a ghost tiddler even by just providing a fieldname in the ghost tiddler (ie there is no template or prerequisit, or action tiddler needed to create a ghost tiddler, Just use it by setting a field to its value (which you can test for before you do so).
âMy Tiddlerâ
â$:/ghost/My Tiddlerâ
In common solutions like I discuss here RFC: Conditional UI elements Tabs/buttons and more we may use a generic fieldname eg; condition, in bespoke solutions the designer âmay name the field according to their brand or plugin nameâ such as a fieldname $:/plugin/PSaT/myplugin/conditions so it is both unique and indicates what plugin or solution introduce the field.
The matching tiddler for the fieldname $:/plugin/PSaT/myplugin/conditions can explain its use.
Reasoning for a ghost tiddler
provide a standard location for external info relating to a named tiddler
The ability to review one tiddler to see the different settings that apply to it
We can have a tiddler info tab itterate the fields and create a UI to adjust these fields. So all solutions can create a settings tiddler that appears in a shared info tab.
This would be an opportunity to document the the changed date of a core tiddler, annotate core tiddlers, back up the tags field title before changes and much more.
As not all will be shadow tiddlers themself, they could all be listed, transfered, deleted.
The text of the Ghost tiddler could be used for freeform notes on the named tiddler or to act as a data tiddler with a standard record type to log activity on the target tiddler or collect other useful information relating only to that tiddler. Eg edit date history and total bytes at edit.
Another use is for the ghost tiddler to contain a child-filter that identifies the children such as for $:/ControlPanel there would be a $:/ghost/$:/ControlPanel tiddler containing
child-filter="[tag[$:/tags/ControlPanel]]"
This would allow the settings to be listed as a heirachy with each tab that contains other tabs also setting their child-filter (or tab/menu filter)
Advanced ideas
Perhaps the adioption of another namespace such as &:/which is also a system tiddler as discussed here Expanding the is system namespace then we can save more bytes with ghost tiddlers found at â&:/tiddlernameâ or even âđ»:/tiddlernameâ
I have long wanted a clean way to have a synopsis tiddler of some of my most important tiddlers but this would be free form text and image - ie standard tiddler content.
I donât know whether this ghost system would help me or not. If I was able to deploy your proposed system then the ghost tiddler would contain a hand curated (edited) synopsis, often this would focus on the highlighted text in an existing (much longer tiddler). Along the lines of revision cards but not quite!
I am familiar with existing plugins aimed at revision cards but they would not suit my workflow or style of working. My way of working would be to be able to throw a global switch to say âshow me the short version if it existsâ otherwise show me the regular tiddler - everything else would work as it does at present - any existing way of filling the story river with tiddlers would know when to substitute the synopsis tiddler if it exists otherwise show the regular.
Would your proposed system help me along that journey, I do write fairly simple plugins these days?
I guess what I am interested in here is functionality and convention to detect and recognise a tiddler perhaps only by title that is associated with another tiddler with which it has a paired relationship. I would then wish to make the substitution in any list of tiddlers destined for the storyriver.
I could of course add a field in each tiddler that had a paired synopsis tiddler but that is less elegant than an automatic detection of a âghostâ that may or may not exist based purely on tiddler title which may or may not be what you are thinking about here?
Example
âMy Tiddlerâ - main tiddler
âMy Tiddler::â - synopsis tiddler detected based on a simple concat on the tiddler title.
Obviously any change in title would need to be reflected in the ghost version if the tiddler title was the mechanism for recognising this relationship between two tiddlers otherwise any change to tiddler title would destroy the paired relationship.
I would generally not wish to see both the full and synopsis versions of a particular tiddler except when I was editing the synopsis and wishing to refer back to the main tiddler.
I suspect I am on a different path here but thought it worth a mention.
Some comments from my perspective of not a developer, but a user who likes to tweak and experiment with the inner workings of TW just a little bit, hope itâs worth something in the discussion.
1. I like the idea of storing all additional information about a tiddler in a structured manner and easy to find (e.g. currently the âvisibilityâ and âfoldâ are split in different places).
2. Petty detail. The name âghostâ is good, but maybe we can find something more clear to new users, and not so similar to âshadowâ to avoid confusion. Maybe something like âaboutâ or âmetaâ.
3. As far as I understand, one reason against storing all information in a single tiddler would be to allow for easy modification of it with plugins (including core updates). But we could still create a structured system with separate tiddlers, e.g.:
$:/ghost/MyTiddler/visible
$:/ghost/MyTiddler/folded
$:/ghost/MyTiddler/keywords
4. I think it would be helpful to extend the functionality of any field-related operators, so that they are also able to access the âghostâ fields, e.g. has:ghost[folded] (easy to introduce syntax-wise for has, but I guess not so for other operators like search).
I think what youâre looking for is not necessarily the same as the ghost mechanism from OP (which is rather meant for settings/config mostly hidden from normal user interaction).
What you want can be achieved with simple namespacing like MyTiddler and MyTiddler/Synopsis and using Relink plugin with Relink Titles subplugin. Changing the title of the main tiddler to MyNote will change it across all its âchildrenâ to MyNote/Synopsis and so on.
Thanks - that is useful to know. Yes I knew I was probably stretching the scope of the OP but the ability to pair and substitute is an interesting topic so I thought it worth throwing in even though I suspect it is borderline âon topicâ. Thanks for the heads up.
Thanks for your feedback, it is great to see related ideas.
I think if you look around you will find some tiddler note, or abstract solutions. In this example you give, I suspect there may be more value in either;
An additional text area field in subject tiddler.
I can show you how to do this.
An additional tiddler for your synopsis tiddler, in part because you may want to do more with your synopsis tiddler like tag it, or use a special template for it. #1
I think we need to decide precisely one use/function for each field in the ghost tiddler, and the text field would not be available for the synopsis. I favor a data tiddler for a more functionality.
We could add a text area field and editor for it, in the ghost
Although it seems to me a good case for a separate tiddler #1 as above
Of course let us say we had a âstandard tiddler note text areaâ in the ghost tiddler by default perhaps you, and other solutions could just use that, for synopsis/review/comments etcâŠ
#1
Even in the case of separate tiddlers perhaps the ghost tiddler mechanism can be used to generate the name eg; âđ»:/tiddlername/synopsisâ eg using <<ghost tiddler:"synopsis">> like a qualify macro, where otherwise we use <<ghost fieldname>> for a tiddler/fieldname in the standard ghost tiddler.
This would save you making the mechanisium yourself.
The mechanism could provide ways to show it on the subject tiddler in the viewTemplate etcâŠ
Good Idea, but I like that it was close to a shadow without being it. But meta tiddler would be acceptable to me.
Sure but see my reply to @jonnie45 in some ways I want to stop the proliferation of tiddlers, but yes with a structured names we could make export tools that know how to include a tiddlers meta tiddlers.
I am already thinking about this but Custom functions and operators are most likely sufficient., Just as we use [all[current] and [<currentTiddler>get[fieldname]] we can also use [<ghost/meta>get[fieldname]]
Yes I meant to mention this above.
Relink is almost always used by myself and solves a number of issue if installed including maintaining the ghost tiddlers title when the subject tiddler changes (need to check)
Relink can even be set rename fields that exist with a tiddler title if they are renamed.
And one more thought. Moving things like fold state or visibility to their new place would probably break a lot of custom UIs and plugins and require them to be updated.
I donât know if such a thing is considered backwards incompatibility. Things will break if not updated, but weâre not really removing any functionality, just moving some data to other place.
Also note here Section Editor Plugin: First Stable Release the clear possibility to use state fields in a ghost/meta tiddler rather than separate tiddlers.
!!state/name including with a custom qualify if desired.
This will be considered a backwards compatibility problem.
So new stuff could be based on it, but it will be very unlikely, that the existing mechanisms for visibility and foldability will be changed in the core UI
Just to be clear, I think youâre suggesting a system where we use a particular system-like name-space ($:/casper/mark/mysetting) that acts like a single tiddler, but all members of the namespace get stored in one tiddler.
That would be interesting. Then, if with the press of the button we could convert them to shadow tiddlers, we would have a new way to make plugins. Currently you have to depend on 3rd party tools or use node to build plugins.
I meant to add, @pmarioâs concerns (now that Iâve read them) are mine, too. Thereâs more to consider âback stageâ than I realized at first glance.
@pmario We could do as we do with pop-ups and just test for the existance of a field as well.
The config name space is perfect for wiki globals and yes its being used for tiddler specific settings. I suppose my idea is going forward use a meta name space for tiddler specific only. Reducing the number of future tiddlers.
it would be possible to use a cascade from meta to config tiddlers for legacy I can detail later.
I dont follow this but I am interested.
To be clear in my approach anytiddler may have a matching $:/meta/anytiddler containing information about âanytiddlerâ and it only., the same with $:/systemtiddler $:/meta/$:/systemtiddler.
a shared tiddler where settings and states are stored as fields not seperate tiddlers.
provide some simple tools to generate the meta tiddler title and fields.
an interesting idea that has arisen this to let any designer to create additional tiddlers under the tiddlers meta eg
$:/meta/anytiddler/synopsis
thus a tiddler info tab can show all related meta tiddlers however they were added.
I have started exploring the supporting functions and procedures to get access to the meta tiddler, and a named field. I see value in looking at a cascade, eg: cascade.meta where one can ask for say âconditionâ and it takes the following steps;
Get the field condition on the current tiddler ELSE
Get the field condition on the meta tiddler ELSE
Get the value of condition set in $:/config/meta/condition tiddler if available ELSE
Default if parameter used ELSE << added
Return nothing
Am I insane adding this to the meta approach?
Insane because or the additional complexity, sane because it is a code pattern I often want to use.
You could still ask to get only the fieldname from the meta tiddler <<get.meta condition>>
Find the meta tiddler title only using <<get.meta>>
I have also started preparing a set of equivalent methods for accessing a meta subtiddler, by default â$:/meta/tiddlername/subtiddlerâ or your chosen âmeta subtiddlerâ title, perhaps to use for external notes and other information requiring a whole tiddler. Basically this is the way for designers to leverage the same mechanism but for their own subtiddler eg; ânoteâ, synopsis, historyâŠ
