Tones and Mario, For public-facing projects, being able to name tiddlers with natural language expressions (including spaces) has been essential, and it seems much of the expanded power of fields in 5.2.0 will come from scanning for matches between field names and tiddler titles.
(Emojis and such may seem trivial, but certain specialized unicode characters like Σ, plus expressions in two-byte languages like 字, are surely going to be leveraged by a significant user base as well.) So, as much as it may seem logical to stick to CamelCase titles and a-z_special.string fieldnames for certain users, it seems the flexible-field-names horse is going to be galloping out of the barn as soon as the new version is available. Might we figure out some way to test the compatibility of existing plugins (such as Shiraz) more systematically than by trial and error? -Springer On Thursday, July 22, 2021 at 12:24:46 AM UTC-4 TW Tones wrote: > Mario, > > I am glad someone concurs. For me with my de facto standards and the new > freedom, if a field name looks like a tiddler title it possibly is. > > Do you think many ancient and / or unsupported plugins will break?,. if > they use fields even extensively the issue will only be if they are used > against new fieldname standards. And until now at least we tended to honour > any values if not fieldnames. > > I will be honest though few if any system tiddlers I create have spaces or > quotes of any kind. even tags are usually single text strings, and I do > think I will stick to this, as it simplifies code. but yes, use it when the > exception makes sense. > > I have not yet considered what we may achieve by having field names that > can be wikified into something else, but again I personally intend to > proceed with caution. Perhaps the documentation can give some advice to > this effect, for example currently the fieldname restrictions help us when > generating csv files and if field names (and values) contain spaces, or > commas and quotes this may no longer be true. The documentation should > continue to list the previous limited naming standards as well. > > I must say I also have de facto naming standards for titles even although > they are quite flexible, in fact most that I code follow a simple and > limited range. I like to leave the flexibility for when its needed. The one > exception is when a title is also textual content like a sentence or > paragraph. > > Regards > Tones > On Thursday, 22 July 2021 at 13:56:18 UTC+10 PMario wrote: > >> On Thursday, July 22, 2021 at 3:24:54 AM UTC+2 TW Tones wrote: >> >> >>> However am I the only one who still intends to keep field names to a >>> defacto naming standard such as i-am-afield no caps or spaces? so It is >>> easy for me to tell field names apart from text and titles! >>> >> >> No -- you are not. >> >> >>> Of course I look forward to naming fields using tiddler titles (and the >>> value a relationship type etc..). and to contain special prefixes or >>> suffixes such as "-link" or (link) but as a rule I would like a little >>> structure and naming rules. >>> >> >> You wrote, you want to have tiddler titles as field names. So your >> field-rules have to be the same or a superset of your title rules. I would >> be surprised, if "no caps or spaces" is one of them. >> >> >>> This always helps retain a degree of simplicity when managing lots of >>> complexity. >>> >> >> Oh it will be funny, to deal with all the support requests here in the >> group, because some ancient and / or unsupported plugins will break. ... >> I'm not even sure, what my own plugins will do with "spaces" in field >> names. ... I will have to check that. >> >> have fun! >> mario >> > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/0dc65571-6786-41d3-a47d-f77ee5146b04n%40googlegroups.com.
