I mean, we can sure implement jsdoc, but I believe it will significantly slow down the process and make things more complicated for the TiddlyWiki project... and only maybe easier for everyone else.
On the other hand, if you want to become familiar with TiddlyWiki's code, maybe grab some basics about how simple it is first, e.g. the *tid* format, and then perhaps forget jsdoc ...when given a chance to, after all. To me, the focus is not so much to provide a jsdoc compliant TiddlyWiki doc process... but rather for us to get that API documented and have easy means to give it some smarts... WITHIN that API TiddlyWiki ...not whichever output some YUIDOC or jsdoc node implementation generates. So, the barrier for jsdoc to bea good candidate for this project to me truly is this: Who is willing to write the parser for it? ...and willing to listen to all the complaints about "Why do I need to put all those ridiculous asterisks? They just clutter my TiddlyWiki / Markdown format." Why do I need @ param when it's all clear "_foo" is a param? Sure, using jsdoc it would possibly be easier for someone else to output the TiddlyWiki documentation in a different way. But then I feel like I want to ask: Why? TiddlyWiki is a near perfect environment to document / expose its own API. 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
