I concur with HansBKK that you should adopt a standard wiki markup for TW 5. I differ from in that I think you should adopt WikiCreole see:
http://www.wikicreole.org/wiki/Creole1.0 and http://www.wikicreole.org/wiki/CreoleAdditions The main reason for this recommendation is the WikiCreole markup is *very* similar to TW markup. The main differences being the handling of bold, headings and links. WikiCreole even recommends using double angle brackets for plugins. Since TW 5 is going to break compatibility, then I think it should also take the opportunity to move to a standard wiki format. I know text compatibility and code compatibility are different things, but nevertheless I believe this is the correct way forward. Note TW 5 could support standard TW wikiformat using a plugin, and also could provide a converter so that people can easily move their text from TW format to WikiCreole format. Since the formats are so similar, conversion would be fairly straightforward. Martin On 15 December 2011 09:22, Jeremy Ruston <[email protected]> wrote: >> I've been doing a lot of research and playing around in the "tools >> that transform markup" space recently, and would **implore** you to >> consider choosing one of the more mainstream cross-platform syntaxes >> rather than re-implementing a proprietary TWmarkup, even if it may be >> "based on" one of them. > > The primary constraint I am embracing is to retain compatibility as > far as possible with existing TiddlyWIki markup. I think that that > rules out the wholesale adoption of a standard format - for instance, > TiddlyWiki gets [[pretty|links]] the wrong way round from most wikis. > > To get around the limitations imposed by that constraint, we have the > idea of pluggable parsers and renderers, so that it is possible to > adopt other formats, and intermingle them and so on. If you can find a > JavaScript parser for it, then hopefully you'll be able to use it. > >> Markdown is a popular choice, lots of active development in the >> Pandocs project - their "extensions" may be a bit proprietary, but >> since the focus of the whole project is interoperability, it's for a >> good cause. > > Adopting MarkDown in its entirety is a bit troublesome from my > perspective; it's not very formally defined, and the only > implementations that I've seen are even hairier balls of regexps than > the old TiddlyWIki wikifier. It also lacks what I'd have thought of as > basic features, like tables, arguing that users should write HTML tags > for them. > >> Other candidates are txt2tags and reST/Sphinx, with the former having >> the edge in a huge number of output formats currently supported. Both >> of these are implemented in Python, while Pandocs is Haskell, if that >> means anything. > > I need JavaScript code, obviously. There may be bits and pieces worth > taking from those projects, but a brief glance shows that they take in > concerns that don't entirely match TiddlyWiki, so I don't see a way to > wholesale adopt those syntaxes. > >> IMO the key is to **not** pick and choose bits and pieces, but to take >> on an entire **syntax spec as a whole**. > > I only see that as feasible if there was a spec out there that was (a) > compatible with TiddlyWiki and (b) did everything that TiddlyWiki > needs and (c) didn't include lots of features that aren't relevant for > TiddlyWiki and (d) had usable JavaScript code. > >> This would enable plugging TW into a standardized toolchain so that it >> can be either a "publishing and distribution target", along with say >> EPUB, AsciiDoc and HTMLhelp, or perhaps even the location where the >> "master source" text is edited, to then be able to output and >> transform to such formats. NB I consider TW's forte to be the former >> rather than the latter, but something like Pandocs would give the >> flexibility to go in either direction. > > As I say, the ability to have pluggable parsers and renderers should > give you the capabilities you want. For you, the native TiddlyWiki > format might just be what gets used for the application plumbing, with > all your content being in other formats. > >> But please **please** don't just throw another proprietary wikiMarkup >> syntax set into the mix, this is an historic opportunity to contribute >> to the idea of "open data" in the larger ecosystem rather than >> continuing to view tiddlers as an isolated silo needing custom coding >> to extract inline markup semantics. > > I'm not planning to throw another proprietary wiki markup into the > mix. I'm planning to improve TiddlyWiki's existing markup so that it > isn't broken with respect to paragraphs, and to introduce some > alternative syntaxes for some simple formatting. > >> Thanks in advance for at least considering these ideas. . . > > As I say, I think the kinds of things you're interested in are enabled > by the parsing/rendering architecture. I would very much appreciate > feedback on the improvements to the wikitext. > > Best wishes > > Jeremy > >> /rant >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TiddlyWiki" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/tiddlywiki?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/tiddlywiki?hl=en. > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
