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.

Reply via email to