Springer, I totally agree, we need to prepare for any ungainly titles and fieldnames. I suppose my point is to not to abuse this and restate the value of keeping a limited set of naming rules when developing macros and plugins. Basically proposing the use of Okams razor. The rules are meant to be broken but giving one self some naming standards will always help. If I write a plugin or macro I would not make unnecessary use of the freedom, but I certainly will where it is of benefit. Of course for some with different languages they have good reason to make use of the new possibilities.
I suppose for me the hard part is sharing this knowledge and experience to advise people they may have being given sufficient rope to kill there wiki, and to remain circumspect. Regards Tones On Friday, 23 July 2021 at 00:50:25 UTC+10 springer wrote: > 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/00b9c0c8-9978-4e60-a2aa-d5f684365c4en%40googlegroups.com.
