Given Jeremy's statement "I'd be interested in trying to make TiddlyWiki5's format compatible with WikiCreole, but only if it can be done without substantially impacting existing texts."
I've started a new discussion on this topic. I think it is certainly possible to make TW more compatible with WikiCreole. Martin On 17 December 2011 21:07, rakugo <jdlrob...@gmail.com> wrote: > I too would like to see adoption of a standard format. > > I'd assume that like existing TiddlyWiki one could swap in/out > syntaxes (but probably even more easily) so I could imagine supporting > a plugin to help with this transition. > > I would assume it would be easy to convert from one format to another, > since TiddlyWiki markup can be converted to html then from that into > WikiCreole. I could imagine a transition tool that takes an old > TiddlyWiki and converts it into a new TiddlyWiki. > > On Dec 17, 5:21 am, HansBKK <hans...@gmail.com> wrote: >> On Friday, December 16, 2011 9:55:25 PM UTC+7, Jeremy Ruston wrote: >> >> > WikiCreole is interesting. I hadn't seen the amendments section. I'd be >> > interested in trying to make TiddlyWiki5's format compatible with >> > WikiCreole, but only if it can be done without substantially impacting >> > existing texts. >> >> IMO **Any** standardized syntax would be better than keeping TW's unique. >> That way at least there's a way to get plugged into a toolchain down the >> road without having to write a specific converter template/parser for TW. >> >> Converting to or from the "standardX" markup used by TW is then more than >> likely to be supported by converter/parser engines like Pandocs and >> docutils as they continue to evolve, or at least if a new >> "tangler/template" whatever needs to be written for it that's useful to the >> whole ecosystem, not just the one community, and therefore more likely to >> be supported and maintained over time. >> >> The primary area where backwards compatibility is a concern is the> >> handling of paragraphs. TiddlyWiki's use of <br> tags is just plain wrong, >> > and I think it's worth taking a minor compatibility hit in order to gain >> > the advantage of producing semantically proper HTML, which is generally >> > much more useful. >> >> > The reason that I'm so keen on backwards compatibility is that there is a >> > lot of text out there in TiddlyWiki format; much of it on >> > people's hard drives. I like the idea of enhancing the value of that >> > existing investment by making it super easy for existing users to take >> > advantage of the new features of the new software. >> >> That goal is of course essential, but I would think it wouldn't be that >> hard (easy for me to say not having a clue about programming) for the TW >> code at the point where a tiddler is first being created to parse the data, >> recognize it's TW4syntax (by the paragraph mark?) and do a one-time >> conversion to the TW5syntax. >> >> If you're fixing the paragraph syntax you'll have to do something like that >> to accomplish the above goal anyway. >> >> On Thursday, December 15, 2011 4:22:51 PM UTC+7, Jeremy Ruston 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. >> >> Sorry for the use of the word "proprietary", very rude in the FOSS world I >> know - how about "unique" syntax? >> >> > 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. >> >> I think this would only work from a user's POV if the option of using the >> other syntax were available right out of the gate, just flip a switch in >> the config and bang it works with "standardX" markup. Just making the >> architecture theoretically available for future plug-in authors is better >> than not having that but. . . >> >> >> Adopting MarkDown in its entirety is a bit troublesome from my >> >> perspective; it's not very formally defined >> >> I don't like it myself, but sometimes defacto standards offering a lot of >> cross-program interoperability are better than perfect implementations that >> remain on the shelf like museum displays. >> >> > 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. >> >> I don't understand this - the specification for a syntax is one thing, a >> given bit of code that uses that syntax to do convert/render from the >> plaintext to whatever can/should be in whatever language is used by the >> tool. >> >> The whole point I'm getting at is to be able to keep our data in a >> canonical format as plain text, for transfer to whatever "container", files >> in folders on whatever storage medium, database, CMS, wiki, and easily get >> it out there as EPUB, static HTML, DocBook whatever. Obviously there isn't >> currently such a beast with parsers/converters/renderers etc implemented in >> every mainstream language, or everyone would be using it. I'm just doing my >> bit to advocate that one of the cool tools I use help move in that >> desirable direction. >> >> If TiddlyWiki can help facilitate that goal it's that much more valuable as >> one of those platform choices, whether used as a source-file editor or >> target publishing format for output from other parts of the toolchain. >> >> > IMO the key is to **not** pick and choose bits and pieces, but to take on >> > an entire **syntax spec as a whole**. >> >> 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. >> >> Note I'm *only* talking about markup within the tiddler **content** area - >> what goes into the data-entry box in the normal core UI, what gets exported >> out to plain-text today using Eric's tools I cited earlier. So headers, >> paragraphs, bold/italic/underline/strikethrough/monospace, lists and >> tables, images, codeblocks and quoteblocks, HR separator, comments, URLs >> and email links. >> >> What TW needs internally is a black box AFAIC, although having a simple >> intra-file link, even if only to tiddlerTitle would be a bonus. >> >> Sorry to keep ranting on, I'll try to have this be 'nuff said. . . > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To post to this group, send email to tiddlywiki@googlegroups.com. > To unsubscribe from this group, send email to > tiddlywiki+unsubscr...@googlegroups.com. > 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 tiddlywiki@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
