Idea a Very Short Title field VST

#1

I had one of my creative ideas I usually keep to myself until I validate it a little more, but thought on this occasion I would open it up for discussion.

Background

As you know with system tiddlers then tend to get longer when their titles are nicely organised into plugins and other name spaces. Personally I also like my tiddlers having full and descriptive titles, rarely to I have a duplicate title for my to do items for example.

There are real advantages with long titles, and I can recommend them, however there are some cases where these long titles become less optimal, for example if you save a list of titles it can consume a lot of bytes.

Idea “VST lists”

Not unlike prior work to create a serial number for each tiddler, what if we allowed tiddlers to be given an optional, one off, and unique, Very Short Title VST, in a field, eg vst field, this vst would never change for the life of that tiddler, even if the regular title changes.

  • This can be automatically created, checked/generated for uniqueness and encoded to reduce its size.

When constructing a list of tiddlers, rather than store the full title, sort only the list of very short titles, thereby reducing the overheads a lot.

  • We would provide a set of supporting tools to make using “vst lists” easy
  • For example a title drag and drop reorder that only stores the order as a list of VST titles.

Many of us now rely on the Relink plugin but this method can stand apart from Relink. If the tiddlers title is change the VST just points to the original tiddler whatever its name now is.

This may prove important in the following wikis

  • Wikis that use long titles, such as meaning full text titles or sophisticated system tiddler hierarchies
    • This is happening in my Knowledge Repository built up from LLM Q&A’s.
  • Wikis that have many lists and indexes into a reasonably large set of tiddlers.

Your thoughts?

  • Can you see the reasoning and value?
  • Does it inspire related ideas?
  • Have you code patterns that could help?
  • Where could it help you?, in what kind of wikis.
New to tiddlywiki - need some help [with validating tags when user saves tiddler, then preventing (re)edits]
#2

I think memory is not a concern with modern device any more.

You are talking about UUIDs, which have some advantages, but also a lot of disadvantages.

  • They are not human readable
  • We need UIs to see the referenced real tiddler title
  • If a list-field contains “a c b” humans can not decide, if the real tiddler titles are sorted in any way.
  • Once we have them, users will want to use them for all the possibilities we can do with titles. So for tagging, in list-fields, links, transclusions and so on.

If a VST is human readable, unique and short it is a title. So why should it be in a field. IMO it could be the title

just some thoughts

#3

Thanks for considering my idea @pmario

This depends on what demand you put on memory. Lets say I have a hundred titles of 80 characters long, I need 80,000 characters. Now let us consider I have 10 lists of these titles in different orders, I need the same number of bytes, for each list ,if I use the titles or 80,000 x 10 + 80,000 (original) = 880,000 bytes, if however rather than store the titles in my list I store the VST, I only have 100 titles, so the VST titles are no more than 3 characters long, or 300 for a full list of VST’s, now lets have out 10 different lists and the total space is approximately 3,300 bytes compared to 880,000 bytes.

  • In the above estimate I am not counting the separators for both cases.

So now Imagin larger data sets, for example if one had tiddlers for 40,000 words or phrases suddenly the memory usage between the two approaches becomes substantial.

  • No I am not talking about UUIDs, I am just talking about a unique code. It can be as simple as 1 to N.
  • The fact we can easily have a 999,999 VST’s with no more than 6 bytes there may be no need to compress them, but we could eg Hexadecimal.
  • Even encodings such as Hexidecimal are human readable. But there is no need to read them. Just think of it as a sort field.

Because we want to see the long title, not the VST, the VST is just a means to an end.

  • Having tiddlers with a title based on an algorithm is unfriendly, and not easy to use.
  • Having a field containing a code based on an algorithm, is much more user friendly, because the users interact with it through an interface, not directly.
  • I don’t think so because they are not regular titles, they are not much more than a caption or index number, they are preset in (some) tiddlers, unchangeable, maybe even hidden.
  • There purpose is to allow VST proxy titles for list fields.

Without spelling out the details, I would like to allow my tiddlers to have a custom reordering of the view template elements. On my current GTD wiki I have 62 items with the $:/tags/ViewTemplate tags, so each tiddler would need more than 2.2Kb of a list field which I could reduce to less than 500bytes.

#4

One thing I did not say in the Top of this topic, is the VST “Very short title” can be stored in a data tiddler as a key to the full name, in this case we need to ensure relink can keep it up to date, if you rename the long titled tiddler.

  • This would allow VST’s for existing core or plugin tiddlers without editing them.
#5

Not sure if this really applies, but a bit ago I played with the idea of replacing the title field with the created field, and your idea reminded me of this.

It was in essence as mario put it, a uuid in function, leaving the title to work more as the caption field is used.

It was something I could see working, but converting everything over to work with it would be a pretty big task.

#6

I have had similar ideas in the past. The difference with this idea is to permit a short title or unique alias to be used for longer titles. ie I specifically want to use long titles, but at the same time, and have some methods to address them as very short titles.

  • I suspect someone with more skills than I could use the VST’s in a parallel namespace or create filter operators to support separate unique id titles, at the same time as the standard title?
#7

Addendum: so in essence creating a reference page you can call to to quickly locate tiddlers, maybe like what we do with the colours macro?
Ie
Tid1=index
“SuperLongTiddlerTitle”:“longTiddler”
Tid2=SuperLongTiddlerTitle

<<index longTiddler>> = [[SuperLongTiddlerTitle]] or {{SuperLongTiddlerTitle}} ?

Also reminds me of how you can use a field like aliases and then filtered transclusion to quickly link to them even with two aliases with enlist (I think thats the right one, I may be a tad half asleep :sweat_smile:)

Edit: oop, thank you- didnt notice that wasn’t showing haha

#8

In ONE WAY this just seems to replicate what is done already.

I DO like the idea A Tiddler, wherever She is, can be found.

SO, another way, may be to ASSIGN, on creation of a Tiddler, AN UNIQUE link to it? Field crypto string needed to probe her fields?

#9

Please be aware that this idea might not be future-proof as, computers becoming more powerful, the millisecond precision of created will allow many tiddlers to be created at exactly the same time inside wikitext loops.

If I were to consider @TW_Tones idea, I would use an UUID like @pmario suggested.

Also, many TW processes would need adaptation for the VST to remain an ID in every case, like tiddler cloning for example.

My 2 cents, for what it’s worth…

Fred

#11

Remember a UUID has the word universal in it. I belive this may be useful but overkill in this situation. Even my own idea for a TSN or tiddler serial number discussed previously, is over kill as the very short titles I propose, could have a dedicated field and relate only to a specific list of titles for which you have more than one manualy sorted view.

  • even my TSN solution avoided UUIDs by assigning it only to a subset of tiddlers that needed it, and replacing it on clones. It disallowed non unique TSNs.

The main idea here is you can use very short titles as and alternative way of addressing longer titles. Use it for grouping, sorting and storing a proxy list for longer tiddler titles lists.

  • if the designer wants it on every tiddler or to be universal then that is for them to work out :nerd_face:
#12

Erm. What does it mean in practice?

Just asking.

#13

“Every tiddler” would mean you have a unique number or alternative identifier for every tiddler within the wiki.

  • This would give you two unique identifiers for each tiddler, one that you can change, “the title”, one you do not, the tiddler serial number.

UUID would mean a unique number or alternative for every tiddler within the wiki and across all wikis. Unique in the universe :nerd_face:

  • This would allow you to share the UUID and know it only refers to one unique tiddler in the TiddlyVerse
  • Wikis would need a universal ID + the tiddler would need a unique within the wiki ID, the combination give you a UUID.
1 Like
#14

What sort of format do you have in mind?

Is it going to be more of a serial number, a number and letter combination, maybe something like the handles used in discord, or something else?

I’m curious how these tiddlers would be handled between different wiki :thinking: I’d like to hear the setup of a tiddler.

#15

That is a different question to the one in the thread, I only want a VST to be used as a proxy for the full title, for particular lists and in particular cases. I will try and give a working example soon.

  • However to keep it simple I will make it unique through out the wiki.

I think we can start with a simple number incremented by one. This generates a deterministic list of unique short names.

  • If you have a lot of short names, you can reduce this numbers size by encoding it as hex (base 16) or larger base numbers eg 0-9,a-z,A-Z is base 62 (10+26+26)

Tony

#16

I think list-fields are only important for $:/???/ui/ tiddlers, which can have a lot of redundant info.

TW system tiddlers follow some rules.

  • They start with $:/
  • They have a common “primary” prefix $:/<primary>/ eg: $:/config/ or $:/core/
  • The have 1 or more “sub” prefixes: $:/<primary>/<sub>/<sub>/ eg: $:/config/ViewToolbarButtons/Visibility/
  • They have a “detail” suffix: $:/<primary>/<sub>/<sub>/<detail> eg: $:/config/ViewToolbarButtons/Visibility/$:/core/ui/Buttons/opermaview
  • <sub> prefixes can have CamelCase formatting
  • <detail>s can have hypens left-arrow eg: $:/core/images/left-arrow
  • <detail>s can have hyphens and dots eg: $:/core/modules/browser-messaging.js
  • <detail>s can have CamelCase formatting

So we could configure a “shortener” algorithm, that gives us predictable and human readable, but shorter titles.

The longest title is at tw-com is:

$:/config/plugins/menubar/MenuItems/Visibility/$:/plugins/tiddlywiki/menubar/items/pagecontrols

It could be shortened using some rules:

  1. replace $:/ with $$/ as an indicator for a shortened title
  2. reduce <primary>/ to first-character followed by slash eg: conifig/ → c/ or core/ → c/
  3. reduce every <sub> with their UPPERCASE chars, if there are some eg: plugins/menubar/MenuItem/Visibility → p/m/MI/V
    3.1 if there is no UPPERCASE char in <sub> use the first lowercase as in 2. eg: plugins/ → p/
  4. <detail> will be not reduced
    4.1 except if they are combined as in the example below, where Visibility will be reduced
$$/c/p/m/MI/V/$$/p/t/m/i/pagecontrols

So if we search for [all[shadows]] +[suffix[/pagecontrols]] we do get 3 results

  • $:/config/plugins/menubar/MenuItems/Visibility/$:/plugins/tiddlywiki/menubar/items/pagecontrols
  • $:/core/ui/PageTemplate/pagecontrols
  • $:/plugins/tiddlywiki/menubar/items/pagecontrols

grafik
grafik1204Ă—431 17.7 KB

Which could be mapped to:

$$/c/p/m/MI/V/$$/p/t/m/i/pagecontrols : <long-name>
$$/c/u/PT/pagecontrols : <long-name>
$$/p/t/m/i/pagecontrols : <long-name>

I’m not sure if that will create duplicates, but I’ll have a closer look, once I do have a “search-replace” regexp that can create the short names.

I know that’s not as short as 3 characters, but IMO definitely more human readable. And the rules should be simple enough, that we can use them without the need of a lot of new UI tooling.

[all[shadows]] +[prefix[$:/core/ui/ViewTemplate]]

grafik
grafik1098Ă—716 34.6 KB

This may give us a data-tiddler with:

$$/c/u/VT : $:/core/ui/ViewTemplate
$$/c/u/VT/body : $:/core/ui/ViewTemplate/body
$$/c/u/VT/b/blank : $:/core/ui/ViewTemplate/body/blank
$$/c/u/VT/b/code : $:/core/ui/ViewTemplate/body/code
$$/c/u/VT/b/default : $:/core/ui/ViewTemplate/body/default
$$/c/u/VT/b/import : $:/core/ui/ViewTemplate/body/import
...

If we would limit the shortener to all tiddlers prefixed $:/core/ui/ we can make it even shorter

$$/VT : $:/core/ui/ViewTemplate
$$/VT/body : $:/core/ui/ViewTemplate/body
$$/VT/b/blank : $:/core/ui/ViewTemplate/body/blank
$$/VT/b/code : $:/core/ui/ViewTemplate/body/code
$$/VT/b/default : $:/core/ui/ViewTemplate/body/default
$$/VT/b/import : $:/core/ui/ViewTemplate/body/import
...

just some thoughts. I’m sure I’m missing some usecases, but IMO it may be a start to create shorter titles and still have them somewhat human readable.

-m

1 Like
#17

I think we do not even need a data-tiddler. We “only” need to define some replacement rules in a config tiddler with a list-field $$expand which contains a list of fieldnames, that should be used to expand the tiddler body text.

title: something
$$expand: $$ VT b
$$ : $:/core/ui
VT: ViewTemplate
b: body

$$/VT
$$/VT/body
$$/VT/b/blank
$$/VT/b/code
$$/VT/b/default
$$/VT/b/import

Using a config tiddler like this one, we would have much more freedom, since everything is dynamic but deterministic.

  • It will search for b/ and replace it with body/
  • It will search for VT/ and replace it with ViewTemplate/
  • It will search for $$/ at the start of the line and replace it with $:/core/ui/
    • /$$/ in the middle of the string will need some special handling. Don’t know yet

-m

1 Like
#18

Very interesting approach @pmario and comming from quite a different approach. This is certianly a code pattern that could deterministicaly create short titles.

Can I assume then you think there is some value in such titles? Which was a big aspect of the OT.

Your idea makes me wonder what if rather than choose up front specific keywords to tokenise parts of a title eg viewTemplate to VT we build a dictionary of words found in titles and automatical assign a shorter form. Then follow your idea. It would still be a wiki local deterministic process, but apply to all system tiddlers.

  • could be leveraged in cryptography :nerd_face: but thats another story.

I think it importiant for those tiddlers but also others.

One reason I took the numeric route was because I wanted VSTs for arbitrarily long plain language tiddler titles. Examples being to do item tiddlers titles or questions asked of chat gpt as titles, with the text containing the answer.

lists

Despite being a core feature of tiddlywiki I do feel we underutalise lists in tiddlywiki, also known as sets. It seems to me that especialy when using plain language titles, the idea of VSTs would help. For example long titles make ugly tags.

  • having VSTs supports looking at the same data by its membership and position in one to many different sets.
#19

I agree painfully with this little tidbit.

I’ve played around with text shortening with the tag template, however unsuccessful I was, and figured sharing my initial idea might spark others to try it.

The general idea was that if the title of a tiddler was longer than a set number of characters, in this case I had chosen 12 characters, a word-break would take place, and replace everything after the break with …, and the hover over tag to trigger the title (css element) to appear, showing the full length of the tag, as well as showing the full tag title when the tag was clicked and listing everything it was tagging.

I believe I dropped the idea when I found it to be //very// confusing to look at system tags, but for non-system tags, maybe it could work?

Just food for thought at this point :man_shrugging:

The more I use my wikis, the more and more usecases I find for lists and TOCs, so I agree with that, as well.

2 Likes
#20

This is very clever, and I think I may try it out myself! I don’t think it’d be too tricky to start from the beginning for standard tags and from the end for system tags, and then you’d have the best of both worlds… :thinking:

#21

You can do that with the CSS text-overflow property: