As far as I understand, I (as an ordinary user) would never have a reason to want to create a shadow tiddler, except if I’m building a plugin-like solution (one where I’d need to establish a default suggestion while expecting some other end-user might prefer something else, even while needing my basic default to remain as a fallback if their variation is lost, or creates a mess and needs to be nixed). I don’t see where it would occur to anyone to create a shadow tiddler for their own non-developer purposes (though of course having backups of prior versions of this and that is always a good thing).
By contrast, I certainly want to be able to configure how fields work in my own wikis, and this interest emerges organically in working with TW as an end-user.
Since I can currently do so with ordinary TW5 skills (meaning, no javascript), I don’t think of a basic plugin in this area as enabling a new thing.
(Perhaps this is where your concerns, and your skills, are beyond mine! I’ve been thinking of offering a simple plugin, and it’s not going to involve any new javascript, and it would not bake in any expectations about fieldname prefixes (except perhaps in the fields-about-fields — see below). The goal would just be to make access to the deeper power of fields more convenient, and to to include some signpost-like documentation and useful templates.)
I think in another neighborhood of our conversation you were recommendation a prefix for the “fields about fields” — such as field-description
or field_is_longtext
(or whatever). That strikes me as a great convention with no downside, and the remaining challenge is just whether we can avoid relying on the English word “field” in that prefix — while still making the convention keyboard-accessible, and intuitive enough (hence my thought about leveraging §
).
But if you mean that you imagine all (non-core) fields should have a prefix…
… That would be a non-starter for me. In my ordinary work, I’m absolutely committed to fieldnames like “score” and “word-limit” and “DoB” and “user_id” — partly because I’m importing and exporting JSON data with other database systems with their own fieldname conventions, and partly because Shiraz tables work most conveniently with compact fieldnames. …
On the other hand, I do think distributed TiddlyWiki solutions should be careful to avoid barging into plausibly in-use fieldnames within the “customer” wikis that might adopt those plugins…, so purpose-specific (bibtex-
) or developer-specific (PSaT
?) prefixes are great in that respect. Maybe that’s all you meant?
[EDIT: I realize after a few moments… perhaps you meant not that the fieldnames themselves would have prefixes, but just that the tiddler (where info about the field lives) would have a prefix, so that the fieldname is a substring of that tiddler’s name. IMO, this creates some confusion, because if there can be a regular-old tiddler called bibtex-LCCN
, it seems odd to expect that tiddler to be “divorced” from the meaning of that string as a fieldname… But I do see room for flexibility here!]
Great to be having these important conversations about where the opportunities and risks are!