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 view this discussion on the web visit https://groups.google.com/d/msg/tiddlywiki/-/4qNTv_IWYSMJ. 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.
