System fields and tag captions

[TonyM]

Folks,

You would be aware that tags can be given the prefix $:/ to make them system tiddlers, or just use any title. The advantage of this is any tag can be give a "tag tiddler" containing more info and features about the tag, this provides a high degree of extensibility to tags, having also system tags (using the $:/ namespace) allows these to be somewhat hidden.

My recent autonomous fields idea can be extended to autonomous tags this way. They key design feature is to get an autonomous tag or field you need only install a single tiddler by the name of the field or tag.

I am keen to also develop the field and tiddlers by the name of the field, "field tiddler" containing more info and features about the field. However since $:/ is not valid in field names there is no way to make the fieldname directly into a field tiddler and also be a system tiddler.

I wonder if there is a way to designate a "field naming standard compliant" way to make fieldnames that are treated as system tiddler titles?

On reflection I wonder if we could make new name spaces that behave like system name space such as "_" or is such a name space more about what the default search can find?. If I excluded prefix[_] tiddlers from the search and other places would I be creating a new system namespace?

At the same time, it would be nice if tag pills for system tags have titles from a caption assigned to the tag, rather than these unwieldy system tags like $:/tags/macro just "macro" in a system colour? The full name can be shown in the tag pill still, to be able to use the caption title to add existing tags would also be nice.

• Could we allow additional names spaces to be created that take on a system namespace handling behaviour?

Any thoughts?

TW Tones

[Mat]

First, just to make sure I understand your goal:

You wish to make tags and fields more autonomous by using the fact that a tag (and potentially a field) can also be the title of a tiddler. Using this, you add meta data and settings into this tiddler that is used when the tag or field is used.

Now, you would like such tag-tiddlers and field-tiddlers to both potentially be system tiddlers using the $:/ prefix - but using it for field-tiddlers is a problem because of naming conventions for fields.

IMO, since the field isn't a tiddler to begin with, it should be possible to simply pretend that the field name is e.g $:/myfield. The field tiddler is really named such and it, obviously, refers to the field myfield. Using the new slugify operator, you get the field name automatically, e.g "[tag[field]slugify[]]" (i.e any tiddler tagged as "field" has its name slugified, which simply removes the $:/ prefix). And the converse should be doable as well.

 

<:-)

[TonyM]

Mat

You do understand what I was asking for well. Your solution is quite elegant. I will explore it further shortly.

However the path I took, led me to reflect on the singular system name space of $:/ and it's features. This has led me to ask how does this name space come about and could we create others with similar or different behaviours?

this is quite conceptual, please forgive me.

A related example I will be releasing in future is a package that enhances the standard search which currently ignores system tiddlers or parts there of their title. An example is control panel. Imagin if the $:/contolPanel tiddler has a field system-tiddler containing "control panel" which the standard search also searches then a plain English search will point the user to a system tiddler designed to be opened in its own right. The same could be done for macros and plugin tiddlers and shadow tiddlers that we want a user to find. This would be a cross namespace feature.

However I would like to know if I can build another namespace like _ which would hide _fieldname tiddlers unless I used the above system-caption or asked is[fieldname] like I can is[system].

While I have tried to give a specific example here my ideas are based on deeply considered opportunities that could provide some very powerful outcomes. One is an alternative to shadow tiddlers since the name is taken, the working title I have is ghost tiddler e.g. $:/ghost/tiddlername where every standard tiddler or select tiddlers can have a ghost tiddler which can contain metadata about the tiddlername.

Just as I would like any tiddler, that is also a fieldname to have a ghost tiddler that contains information that a field definition may require e.g. a tooltip for that fieldname, or a filter used to determine the values available to set that fieldname to and more.

I hope I make sense.

TW tones

[PMario]

Hi Tony,

IMO _ isn't the right prefix to use. We already use it for $:/_ as a user "de facto" prefix, which is sorted automatically at the beginning of the system namespace. ...

I know, it's not the same, but _ should be reserved for "special" user names.

---------------- Just brainstorming

I could live with $:/!!test be a "ghost" tiddler for the "test" field 

-mario

[PMario]

Hi,

For CodeMirror  we used: $:/config/codemirror/cursorBlinkRate type:integer text:530 to define the blinkrate

$:/config/ ... is a known configuration prefix

codemirror/ ... is a known namespace for a plugin

cursorBlinkRate ... is the value.

So translated to "ghost" fields it may be:

$:/ghost/pluginName/fieldName or $:/ghost/pluginName/!!fieldName... -> Would this be useable for your usecase?

-mario

[PMario]

On Sunday, June 28, 2020 at 9:28:36 PM UTC+2, PMario wrote:

So translated to "ghost" fields it may be:

$:/ghost/pluginName/fieldName or $:/ghost/pluginName/!!fieldName... -> Would this be useable for your usecase?

Is the "ghost tiddler" always responsible for fields? Or is it used in a different way ... sometimes?

-m

[TonyM]

Mario,

[Edited for minor typos]

I was thinking of a default ghost tiddler for defacto functions, however to develop the facility for many or other purposes.

Or is it used in a different way[?]

 

Any which way. is my answer

But I do note;

• The standard use of $:/ and the examples you provided, it get this!
• the current use of "_" although is $:/_ a separate creature?
• What other characters make sense here?, they need to be usable as tags and fieldnames.
• Mats suggestion of using slugify may be helpful here, even and alternative to slugify a namespace operator and macro
• Imagine I give the title caption and it lets me list or select _caption a field, caption a tiddler or $:/caption a system tiddler or other namespace for managing caption(s)?

Extended namespaces and the ghost tiddler concept.

• A "Ghost tiddler" could be used to provide a matching field to, "fields found in the original tiddler" eg: description in the ghost tiddler could describe the description field in the original tiddler and be used as the tooltip (not a perfect example because we use description everywhere)
• An example would be a ghost tiddler for $:/tags/ViewTemplate which would document how the tag works and related tiddlers, 
• I would also like to tag a ghost tiddler but not the original shadow tiddler so I can add an organisational tag system without editing shadows them-self.
• It may be possible to use non-unique ghost tiddlers that we provide for tiddlers with a specific field value.
• Ghost tiddler may also allow multiple ghosts for one tiddler that for example may allow for three dimensional tiddlers, and example would be multi-layer images (with transparent backgrounds or SVG's, which one can set the order front and back etc...

One point I would like to make, is it is critical when making plugins to follow some strict disambiguation with naming standards, however if I am building a bespoke wiki I may choose to forgo compatibility and transfer-ability for simpler usage. The most obvious example is having tiddlers with the name of tags and fields that are not system tiddlers. These may not work across wiki, but they certainly make the current wiki a more intuitive solution to non tiddlywiki users, just users of a app/site built on tiddlywiki. Global applicability should not I believe prohibit local innovation.

In an example I built for a user, I even have tiddlers for the values of fields. For example an object-type field with the value "task", has a "task" tiddler which lists the tasks. and the task tiddler has an object-type of "object" so the tiddler "object" lists all objects. Here is where I may push tiddler code into a ghost tiddler for fields. So the object "task" has a field called status, for which there is a status tiddler, that has a ghost status tiddler, with a description of the "status" field. Or filters for listing each status eg: closed and archived status.

The thing is if we can reliably detect the existence of one or more ghost tiddlers, (The lookup operator is our friend) we can build solutions that have the minimum of code but allow an intuitive interaction with the code.

I have an idea for a book called "occam's electric shaver' which is a digital equivalent of "occam's razor". Basically one builds up a sophisticated solution then decomposes it into a simpler one, reiterate until the final result is the most powerful solution, with the simplest of models to use and understand the end result. A single system namespace of $:/ gets in the way of this reiterative abstraction by forcing a need for a non-intuitive for-knowledge of $:/ and its behaviour.

I believe there are a small set of standard "ghost" tiddlers if they became a de jure standard could maintain more inter-wiki possibilities while introducing substantial code patterns.

I want to construct new namespaces but then choose when to apply cross namespace behaviour.

Do I sound like a raving lunatic?

Regards

Tony

[TonyM]

Mario,

I like this idea that we can have a tiddler $:/ghost/pluginName/!!fieldName

I could imagine a special namespace of !! (rather than $:/ such as !!fieldname

Thanks for entertaining my ideas. If they are to go anywhere it needs support of people such as yourself, with the skills to implement.

To me Gentags is a powerful example of what you can do.

Regards

Tony

[TonyM]

Yet another Post script

I am also interested in a concepts as follows

• "virtual fields" effectively they are fields that do not contain a value but a template and/or actions to execute on use of the field.
• Similarly action tags, whose dropdown provides access to actions to apply to tiddlers so tagged. The task tag would allow you to change the status of a task tiddler.
  
• And action fields that are field based versions of the tag-pill.

Tiddlywiki, imagination unlimited.

Regards

Tony