Mario,
Thanks for sharing your expertise on this. I have a need for a subtly
different approach, because I am thinking of fields I may use in solutions
I deliver. Solutions intended for common use. For example a journal-date
field with a time stamp so there is no need to parse the "pretty
>
> I avoid polluting the tag name space by using fields whereever possible
> rather than tags, including alternative tag fields. I retain my tagging
> options for ad hoc relationships.
>
About how the system *ought *to work, you may want to look up this request:
@pmario:
Thank you very much for posting this information. It's an excellent and
timely summary of material that I should be thinking about as I become a
bit more active. in this community. ( _HwWvW )
Cheers,
Hans
On Friday, May 15, 2020 at 8:39:45 AM UTC-4, PMario wrote:
>
> On Friday, May
On Friday, May 15, 2020 at 2:18:21 PM UTC+2, PMario wrote:
If you try to establish *many *plugin-related fields. I personally would go
> with a postfix. show-info.psat ... So I can use show-info.wl ... OR we
> both agree on the behaviour of how show-info should work ;)
>
As i wrote this, I had
On Friday, May 15, 2020 at 5:17:29 AM UTC+2, TonyM wrote:
...
> *Note: *A Common answer in tiddlywiki is don't bother, use as many as you
> want and if you get into trouble change it, does that apply here?
>
Yes. :))
For your private wikis you can do what ever you want.
5 matches
Mail list logo
