It is a nuisance to remove these from my plugins. I don’t know how others do it, but I do it manually. Very annoying.
I wish there was scrubber, some post-processing plugin to run stuff (including other plugins) though to remove these fields - which means it would scrub json files too.
What else do you propose?
Use tab character instead of multiple space characters! This has greatly improved the legibility of my code. Especially in stylesheets, many use two (or more) space characters but this is really bad, IMO.
Apropo stylesheets, or actually wikitext code in general, while I can see the argument for one fixed way to format a style definition, in practice I’d say the most important thing is legibility. Sometimes it works well with a full definiton on a single line. Sometimes, I break the line for the final } to get a visual separation before the next definition. For <$let>, sometimes the suffixing > works well to keep on the same row, sometimes it needs to be on a new row to visibly encapsulate the defined variables. Etc.
Back to saving space; with procedures/macros/etc we have good tools to keep things DRY. Even long shadow tiddler titles can be put up in a procedure def and then just referred to with a pretty <<reference>>.
And with modern CSS you can use the & and :is selectors for shorter code.
I think the official plugins and system tiddlers have not above fields. You can test some yourself.
I myself like to keep some of these fields for normal tiddlers (my notes: created/modified). When I am the only author of my wiki, it has no meaning to have creator/modifier fields.
Id like to include here as a helpful tidbit I learned from doing this same process but, make sure to also remove your username from the info tab and to turn off timestamps itll make things easier on you haha…
I do this whole process with my template wiki, that way its cleaner and not filled with fields that might not be wantwd by my future self.
And as far as the tab character, I recommend binding it not to the tab key, as that is what i used to do at the cost of navigation abilities, and to instead bind it to ctrl + space
Hm. I know from my own uses exporting groups of tiddlers is my way of keeping sensitive data from being moved through the network.
I.E. using a preconfigured tiddlywiki with specific styles, keybinds, and settings enabled means I don’t have to tinker or settle for the deault configuration, but if I have a tiddler with sensitive data on it, I can just export that tiddler (in my case after encrypting it.) so that it doesn’t save to where I host the tiddlywiki, it is stored on the local device.
Also, I would say the most practical reason is organization. archiving old tiddlers that are not used anymore, or are deprecated in some way. or just to lessen the size of the wiki for a more streamlined amount of tiddlers to work with.
Yes, it is to “make it small” and a consequence from a smaller file is that it loads faster. But if it is just a few removed fields, then it will not make any difference. One more aspect is that it is easier to read the code the more pruned it is.
I mainly use TiddlyWiki on a managed corporate Windows machine. Almost all the storage is sent to OneDrive in some arcane way. I cannot say for certain what happens or how it works, but I have fared better when I’ve used smaller files.
This helps - and I usually have either one or two Tiddlies up.
I run both through the command line - in full screen - and just switch between them - on my Mac
Also, I keep them in DropBox (personal) and enabled the GitLab (auto-save) option in the preferences
Right now - they are quite large - as I am unsure if I need data from a few years back - but occasionally do reference old data.
I am now in the process of "tag"ing my tiddlers (a third tiddly - testing) - but for some odd reason - they are slowing down the initial load of my third (test) tiddly - ,… - so I am researching the “correct” or “best” way to tag - since I assume (since I am still new to this way of working) it’s me.
In either case - Thanks for the info - it’s something to mull over - as if I do use “many” tiddlies - my next “search” will be on how to pass lookup requests between them - and displayed within a tiddly - but that’s down the road - as I’ve plenty to do,…
I think you underestimate the value of such fields. This can be used to differentiate between authors including yourself at set up and later when in use. eg empty/design/build/Mohammad so you can see when you change something you added during the build.
@TwN00b I do feel unless you need to reduce a wiki to an absolute minimum, or you have an extremely large wiki this kind of optimisation is unnecessary and takes more value than it returns, at most a megabyte or two.
Personally I would actively do anything to avoid this kind of optimisation as you are very likely going to loose information.
I think you underestimate the value of such fields. This can be used to differentiate between authors including yourself at set up and later when in use. eg empty/design/build/Mohammad so you can see when you change something you added during the build.
Very true!
In packages, plugins, etc. one can remove such fields! The use case depends to your requirements.
I is true that installing plugins with creator and modifier fields set to different usernames can add a lot or creators and modifiers you don’t care about.
However it is possible to first exclude from a list or search, plugin tiddlers, to which you do not want to see the value of creator or modifier.
Except it is not enforceable I thought plugin authors could set creator to there brand name and modifier to a release version or something. But I have not worked my through this idea completely. We could perhaps introduce other fields for this.
For example a default mode that sets creator/modifier, a developer mode that sets author/editor.
itll make things easier on you haha…
