Lets talk about changing default fields

#1

Just want to preface this by saying, this is more a hypothetical discussion.
Can it be done? In theory sure, but should they? Well… that’s a complicated question.

Ok- so what am I talking about?
Well my question is, can the default field names be changed in a tiddlywiki *without breaking things.

Now, doing so will likely break backwards compatibility, and make it nigh impossible to use with other tiddlywiki, but I feel like its something worth bringing up despite this.

The reason I’m interested in this is because I’ve always felt that the default field names are too broad.
Rather than tags, title, text, whynot have them be tiddler-title, tiddler-tags, tiddler-text, or something along those lines, to allow users to use the more broad field names if they so choose to.

And, implementing a cascade system for which field names are used would also be nice, for such fields like the caption field, for instance, but I can see how this could be more detrimental to documentation and user usage than beneficial. Maybe this being a hidden setting would work best if implemented.

Also, I think its worth suggesting that system fields, the default required fields could be prefixed with the $ symbol, to denote their difference from other fields that the users would use, and since they are hidden, they wouldn’t be noticed unless your a power user looking to modify something.

What do you guys think?
Id like to hear other ideas, other pros and cons, and other inout on it.
I’m currently playing around with this by using vscode and empty editions of tiddlywiki.

#2

It might be possible to replace some fields in tiddlywiki that are prohibited in some places with html escape characters

#3

Hm, does the dollar symbol classify as an escape character? I’m not too familiar with which characters are escape characters, I’ll look it up.

I guess I should rephrase my initial prompt from ‘is it possible’ to ‘should it be considered?’

#4

Maybe you can look at W3school, which has the concept I just talked about, html escape appears to be the base number of the character symbol to be translated plus a semicolon;

#5

I think for backwards compatibility and ease of understanding these default, system fields should remain as they are however there are ways to make new fields and replacement fields behave as you would expect to suit a given user.

  • I think if such alternate uses and field names were developed and shared within the community would go a long way to doing what you ask whist maintaining compatibility.

If I may please venture a view, as a long time super user of tiddlywiki I see no need for what you propose, but I have adapted tiddlywiki to address many of the “perceived gaps” that people have raised and seem to be behind your motivated to make this suggestion.

I think if we are given the opportunity to address what is motivating you to propose these changes you would find them unnecessary.

  • It is possible to have an use alternate tags fields, but also multiple tag fields.
  • The title field is essential in many filter operators and macros, although there are many cases where you can use other fields. I make use of alt-title and more for various purposes, just as the caption acts and an alternative title too. The title in the primary key in tiddlywiki when viewed as a database, this should not be touched.
  • The text field is the default field used through out tiddlywiki, but personally I avoid using it beyond a note field except in code and template tiddlers. I display content based on other fields, view templates, and cascades.
    • We can build other text area fields if needed.

So perhaps give some examples of why you think this change is needed and let us show you how to do it without touching the existing fields.

1 Like
#6

Agree with @TW_Tones.

In my opinion, focusing on system fields is unnecessary.

I’ll explain.
Tiddlers link with each other and can have tags. This setup alone provides a robust way to organise any knowledge. Yes! If you try to make do with tags alone, your tiddlers will be flooded with tags, and a system will have to be set in place to decode the meaning.
For example, if you are writing about books, putting a year in the tag field will be confusing because it will be difficult to tell if it’s a year of starting, finishing, publishing, or filming.
Fields are a solution to this problem because they provide context and can be used as entire namespaces of tags or labels.
TiddlyWiki provides you with the power to create an exorbitant number of fields and assign unlimited values for each field. I wouldn’t focus on changing the default fields when I can create my own and happily use that.
With this, I must say that fields can be very powerful and very confusing if not used with certain considerations. In the past years, I explored adding certain fields to my tiddlers, but I haven’t found a way to benefit information retrieval for my use case.
Fields work like supertags because you can search for tiddlers with that field name and then granulate for certain field values. You can use an array of values within a single field, which makes it even more potent in handling information. Like here How to get an array of values from a field?

Finally, for field names reserved by the system, I would create a new field using a synonym. Using “summary” instead of “description” as a custom field name won’t affect my TiddlyWiki. In fact all synonyms of that word will work just as well.

1 Like
#7

Probably not. While I think having the more specific tiddly-* names (or $-* ones) would be a nice improvement, it’s pretty clear that that ship has sailed. Think of all the plugins that people use which haven’t been changed in years but still work fine; they’d suddenly be broken. Think of an automated update that changes "title" to "tiddly-title", which now frees up title for your new separate usage. Great, until you run another update and it changes your new custom title again to tiddly-title. I just don’t think there’s any way to do this unless there’s a huge backward-incompatible version. Even then, it would be scary.

3 Likes
#8

Oh no worries there, I’m familiar with what they are, I’ve used them sparingly, just not sure how many of them their are (which after looking it up, appears to be for every standard character, which is pretty neat.).
I usually use the escape characters for whitespace, like   for en spaces.

Yep, and it’s quite handy. Though, I think of fields less as super tags, and more as tiddlers are sets of fields, and tags is one of those fields, with a specialized use-case.

But I agree, relying solely on tags can be pretty rough, though I’ve seen people manage pretty well with just tags so, I won’t rule it out as impossible.

This has been on my list of things to try out for awhile now. I started working towards it by making a cascade filter for fields suffixed with “-textarea” using regex but never did have it appear like the actual text section of a tiddler, content-type and toolbar etc.

Speaking of, that was one of the other fields I felt could benefit from being renamed. Since it’s just the type field, but type can mean a ton of things, when in documentation its referred to as the content-type if my memory serves me right.

Well, needed I don’t know about, considered is what I would choose- because I agree with your assessment, changing it is a major thing to do, and breaks a lot of established things.

But as far as examples go, here’s what I would suggest in place of the default field names, in a what-if sort of scenario where they could be changed.

| Current Name 	| Proposed Name 		| Reasoning |
-----------------------------------------------------
| title 		| $title 				| previously suggested $tiddler-title, but decided $title is clear enough destinction, so title can be used by users for title of book or profession title, etc. |
| tags 			| $tags 				| Not as neccesary. but included to follow the same format. |
| type 			| $content-type 		| More descriptive of what it is the type of. |
| created 		| $created 				| Not as neccesary. but included to follow the same format. |
| creator 		| $creator 				| Not as neccesary. but included to follow the same format. |
| modified 		| $modified 			| Not as neccesary. but included to follow the same format. |
| modifier 		| $modifier 			| Not as neccesary. but included to follow the same format. |

These fields specifically as they are required of every tiddler, not neccesarily for all system fields, so for instance bags I’m not sure whether or not they would be prefixed with $ but then again, I’m still learning about the whole bags system so- whose to say.

Ya know what, I retract that statement, it would be smarter to use the same format for all system assigned / core required fields.

Yea, I agree- like changing the name itself away from TiddlyWiki, these things are already set in stone, so to speak. But discussion about such things doesn’t hurt incase in the future they’re looked back upon for inspiration towards new software or a new major version of TW, like a TW 6 :man_shrugging:

Right, I find myself feeling completely lost when even the default tabs are swapped about in others TW, so changing the field names would probably be just as jarring, but I can’t help but want to tinker with them haha.

Maybe I’ll just do this to my own wiki and make it abundantly clear to anyone reading it that my fields are a bit different.

#9

If you do this experiment, I would love to hear how third-party plugin fare if you change the names of title, text, tags, created/modified, revision, etc.

#10

Oh, I imagine plugin use will require heavy customization for each one, so I’ll make sure to share my regrets lol

#11

Its an interesting exercise exploring such ideas @Justin_H however I expect when these choices of field name where made very early in tiddlywikis history many of today’s concerns were a long way in the future.

I do see here and there examples of where such fields would have being better prefixed as a system field, the one that annoys me the most is type not only because its plain language but it really is a “content type”, or mime type. It adds insult to injury by being inflexible and complext to use, for other purposes.

  • years ago I chose “object-type” as a replacement field for what I would have used “type” for.

I am happy with modified and created fields as they are maintained by the system and almost always relavant to tiddler management.

There are other cases where overly generic names have being used for quite specific purposes which I would like to use for my solutions however tiddlywiki has succeeded to limit such issues so well that what remains is easy to see.

Finally these defaults have being there for a long time and as a result a lot of acceptable workarounds have being developed that perhaps we should explore first before any core changes.

1 Like