Re: [twdev] Proposing more sane fault tolerance for "unclosed" tags & markup

2017-12-20 Thread Evan Balster
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 '',

Re: [twdev] Proposing more sane fault tolerance for "unclosed" tags & markup

2017-12-20 Thread @TiddlyTweeter
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

Re: [twdev] Proposing more sane fault tolerance for "unclosed" tags & markup

2017-12-20 Thread Jeremy Ruston
Hi Evan I agree that this is a troublesome problem, and Iā€™d also be interested in exploring fixes. I think that the approach you are suggesting is for the parser to check for the closure of parent components within a particular component; in your example, the second pair of double single

[twdev] Proposing more sane fault tolerance for "unclosed" tags & markup

2017-12-19 Thread Evan Balster
Hello, all ā€” I've been malcontent for some time with the way TiddlyWiki handles "un-closed" tags and markup. To give a simple example: plain ''bold //bold-italic'' italic// plain While the above is clearly wrong, TiddlyWiki's resolution is plain bold bold-italic italic plain which