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 quotes would be recognised as closing the first pair, despite the prevailing italic component. We could do that with a bit of refactoring but as you note there is a risk that we’d break the existing behaviour of nested components. 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. Best wishes Jeremy > On 19 Dec 2017, at 22:05, Evan Balster <balster.e...@gmail.com> wrote: > > 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 <strong>bold <em>bold-italic<strong> italic<em> > plain</em></strong></em></strong> > > which renders as > > plain bold bold-italic italic plain > > ...So that this localized markup error ends up affecting the entire remaining > content of the tiddler. This is a "quirk" we're all familiar with, and the > example given here is innocuous, but this issue also affects unclosed HTML > tags and widgets. > > Here's a slightly more onerous example: > > <<< > Evan Balster says ''Fault tolerance is awesome! > <<< > > He later died of exhaustion > > This results in > > Evan Balster says Fault tolerance is awesome! <<< He later died of exhaustion > > ...which clearly wasn't our intention, and also implies the rest of our > tiddler will be a mess. Compare your browser's behavior > <https://jsfiddle.net/hv4m0gLo/2/> with analogs to both of these examples. > > Aside from being spooky-unintuitive, the issues here can get quite severe > when editing complex widget code or upper sections of a long article, with > deletrious effects on browser performance. I've seen browser lockups when > editing widget trees with fragmentary HTML. For these reasons, I'm most > concerned with use-cases involving widgets nested in HTML structures like > tables (which unravel spectacularly while editing). > > > I would like to propose an alternative fault-tolerance behavior for unclosed > tags and markup, which may require some changes to parsing logic. > Specifically, unclosed tags should be "contained" to their parent in the > parse tree, and closed when the parent is closed. > > Under this approach: > The first example will render as one of these depending on implementation: > "plain bold bold-italic italic plain" (italic markers are parsed separately) > "plain bold bold-italic italic plain" (parse tree resolution constrains the > italic section to the bold section, its parent) > "plain bold bold-italic italic plain" (parse tree resolution resolves the > intersection) > The second example will terminate the bold section at the end of the block > quote. > An unclosed <$set> or <$list> widget in a <td> tag should be closed prior to > </td> (rather than destructuring the entire table). > Obviously this is a high-impact change. It could be it's too extreme to do > it for non-tag elements, but I'd like to see what the architecture nerds > think. > > > Here's a bit of code for a "sandbox" to tinker with this stuff firsthand: > > <$edit-text tiddler="ParseTest/Data"/> > > <<< > {{ParseTest/Data}} > <<< > > HTML: > > <$wikify name=html output=html text={{ParseTest/Data}}> > <pre><code><$text text=<<html>>/></code></pre> > </$wikify> > > Parse tree: > > <$wikify name=parsetree output=parsetree text={{ParseTest/Data}}> > <pre><code><$text text=<<parsetree>>/></code></pre> > </$wikify> > > > > -- > 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 > <mailto:tiddlywikidev+unsubscr...@googlegroups.com>. > To post to this group, send email to tiddlywikidev@googlegroups.com > <mailto:tiddlywikidev@googlegroups.com>. > Visit this group at https://groups.google.com/group/tiddlywikidev > <https://groups.google.com/group/tiddlywikidev>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywikidev/5c724111-0eda-402e-87bf-621e144932cb%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywikidev/5c724111-0eda-402e-87bf-621e144932cb%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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/DC6D919C-8578-41DA-A6DC-CF8A9316891D%40gmail.com. For more options, visit https://groups.google.com/d/optout.
