another sightly different way would be to automatically prepend the plugin 
name to the widget name to form an alternative name using an api function eg


inplace of 


where the 'defineExport' would set the addition 

and have a pragma to 'focus' the name 'mywidget' to a particular plugin, 
within a tiddler.

On Saturday, October 15, 2016 at 7:44:43 AM UTC+1, BJ wrote:
> we could have some kind of namespace switching, eg  for widgets, we have 
> when defining widgets
> exports.['mywidget']exports.set = SetWidget;
> which sets up the name 'mywidget' . If we have the convention to 
> additionally provide another qualified name like this:
> exports['bj.mywidget'] exports.set = SetWidget;
> so another clashing definition of 'mywidget' could be
> exports['anon.mywidget'] exports.set = SetWidget;
> then we could have a pragma to 'tell' the parser (the html rule in this 
> case) to override the 'mywidget' with a choosen prefix.
> Obviously prefixes should be publish somewhere.
> BJ
> On Thursday, October 13, 2016 at 12:17:44 PM UTC+1, Jeremy Ruston wrote:
>> > However, I have yet to see a plugin follow this guideline. Is this 
>> still enforced/encouraged?
>> I think I wrote that right back in the beginning of TiddlyWiki5, when it 
>> was under development in 2011/12. Trying to learn from the experience of TW 
>> Classic, I was consciously trying to implement features that would help the 
>> community coalesce.
>> As it's turned out, I don't think using the author prefix in the 
>> widget/macro name is a good approach, because of the inevitable wordiness 
>> it brings.
>> Tobias' idea of a central registry is not bad; if you're interested in 
>> setting it up, then I suggest that structuring the registry as tiddlers in 
>> the wiki, but open to suggestions.
>> Best wishes
>> Jeremy
>> On Thursday, October 13, 2016 at 9:24:18 AM UTC+1, Julian Kniephoff wrote:
>>> Hi Tobias
>>> that's good to hear in the sense that I now don't have to feel bad for 
>>> ignoring that guideline myself.
>>> The GitHub-Repository idea sounds very interesting, even independently 
>>> of namespacing issues. But in the long run, some kind of namespace system 
>>> could be very useful. After all, I might really really want to pick a 
>>> certain name for my widget, for example, even if I find out that it is 
>>> already taken. ;)
>>> Just a stray idea: Since TiddlyWiki borrows XML syntax (for widgets) 
>>> already, anyway, something similar to the XML namespace system could maybe 
>>> work?
>>> I imagine a plugin author would specify a namespace URI (maybe the 
>>> sourceURL that is already in the file?) and then to use the 
>>> stuff from the frobnicate plugin, you would specify a namespace 
>>> attribute like
>>> <$frobnicate twns="";>
>>> Every named entity referred to in here is looked up in my plugin first
>>> </$frobnicate>
>>> Or, if you want to explicitly disambiguate things or be more explicit in 
>>> general, you could give it a prefix:
>>> <$jk:frobnicate twns:jk="";>
>>> Every named entity referred to in here with a "jk:" prefix is looked up 
>>> in my plugin first
>>> </$jk:frobnicate>
>>> As said, just an idea. Such a system would probably require much work 
>>> very deep within the core of TiddlyWiki. :/
>>> Best wishes,
>>> Julian
>>> P.S.: Sorry for the empty post earlier, I accidentally hit the wrong 
>>> button ...
>>> On Thursday, October 13, 2016 at 6:25:51 AM UTC+2, Tobias Beer wrote:
>>>> Hi Julian,
>>>> It's the first time I hear of this convention and I'm almost certain no 
>>>> one has been adhering to it.
>>>> At least I haven't been, since I wasn't even aware it existed.
>>>> It would definitely avoid collisions, especially among plugin authors.
>>>> If you look at my plugins, you'll find that many have a good chance for 
>>>> future incompatibilities owed to their generic names...
>>>> Eventually, rather than the above convention, I think we should have 
>>>> some public listing where authors can register some basic info about their 
>>>> plugins, especially things that may clash, like:
>>>>    - parsers
>>>>    - widgets
>>>>    - filters
>>>>    - fields
>>>>    - css classes
>>>> I find that to be a more sensible approach which would also make 
>>>> plugins a little more discoverable. Then a dev could verify if their 
>>>> desired name was already used by something else.
>>>> This could be a simple github repo where authors are free to make a PR 
>>>> for their plugin listing.
>>>> Best wishes,
>>>> Tobias.

You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Reply via email to