Hey, Tobias — I fear we will just delay the parsing error ...to the next closing tag > which now operates as a new opening tag. > > So, with... > > ''foo //bar'' baz// mumble and then some //more italics// but is it really? > > ...what happens if we forcefully close the italics at the second '', we > are then facing an opening italics marker that will screw up the subsequent > output right after *baz*. > How do you suggest we ensure that *more italics* is indeed displayed in > *italics*, in the end? >
So yes, this is one problem with the scheme — in trying to prevent one formatting "leak" we create another. However, based on my inspection TiddlyWiki already parses every formatting run separately, which implies there might be a more graceful solution. If I understand correctly, TiddlyWiki will identify the first two pairs of bold-quotes and the first two pairs of italic-slashes prior to generating a parse tree. The trouble is in how it resolves them. I propose that parse resolution could either accommodate the overlap or could close the italic section at the end of the bold section (leaving the text intact). Either behavior would require more intricate logic in that resolution. Jeremy, correct me if my appraisal of the parsing mechanism is incorrect here. This is based on a shallow inspection of parse rules. So, here's the thing: Rather than try and be smart or "graceful" about it, > we should *stop all parsing completely* and throw an error, > that the wikitext contains invalid formatting at the very first spot it > occurs. To be a little blunt, this is contrary to web programming conventions. When a browser encounters something like this, it muddles through. Highlighting any syntax errors rather than attempting to emulate the "intended" behavior could be a productive compromise. Halting the parser would be useful as an option, especially when making widget structures. An alternative that I have seen in other markup implementations is to treat > line break as closing all open inline formatting elements. That would also > have significant impact on backwards compatibility, but might be easier to > implement. I'm not keen to break backwards compatibility. As a compromise, paragraphs (which are containers) could close formatting. It occurs to me that the most productive parse rule to experiment with, at a baseline, would be HTML tags and widgets. On Wednesday, 20 December 2017 11:21:23 UTC-6, @TiddlyTweeter wrote: > > Ciao Evan, Jeremy & Tobias > > Jeremy Ruston wrote: >> >> An alternative that I have seen in other markup implementations is to >> treat line break as closing all open inline formatting elements. >> > > Right. That behaviour is what I have see too. I suspect that's because the > simpler versions parse only a line at a time and just substitute HTML for > inline markup shorthand using regex that matches pairs sequentially. > > That would also have significant impact on backwards compatibility, but >> might be easier to implement. >> > > Right. How much and often it would break back compatibility I'm unsure of. > > IMO all the lightweight markups got a bit out of control (see: CommonMark > & Babelmark 2 [A Markdown comparator]). They are easy. But parsers tended > to make it too easy to get away with fouling the footpath with malformed > markup by, typically, second guessing closing tags when only opening tags > had been created. > > I think Tobias' point is worth attention ... > >> Rather than try and be smart or "graceful" about it, >> we should *stop all parsing completely* and throw an error ... > > > Why? Because if you try to automate on all anomalies you end up with an > over complex smorgasbord to maintain. > > I think one issue behind the problem is NOT just about poor final render > in edge cases. Its also about tolerance (or not) of user behaviours on > their original marking-up that code ends up over-supporting. > > Best wishes > Josiah > -- 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 tiddlywikidev+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywikidev@googlegroups.com. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/9253b7fd-c888-4be4-9a8c-ee5a73d49cbd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
