On Wed, Dec 1, 2010 at 11:27 AM, Jeremy Ruston <[email protected]> wrote: >> Repairing this behavior is essentially a two-line modification to the >> handler function: > <snip> > > That makes sense, and is a useful modification. As you say, a similar > modification would need to be made to most of the formatters.
After messing about more, the macro example isn't so great. For instance, if any point later in the document contains the string '>>' then it's all over: a "macro" is discovered and usually you get that red <<error in macro>> message covering most of the tiddler. I don't think there is any good way around this- I tried adding [^(<<)] to the lookaheadregex to at least avoid matching a broken macro markup with a completed macro later in the tiddler, but this doesn't work for 2 reasons: 1) it doesn't magically cover a case where someone uses '>>' later in the tiddler for some non-macro reason... I'm sure someone could find an emoticon using that string! 2) the lookahead regex is looking for the "meat" of the macro definition, containing just about anything, and even a tiddler's title can legally contain the string <<. So unfortunately, my fix only works in a case where someone definitely didn't intend to use a macro, and doesn't use a properly defined macro later in the same tiddler. Not really a full solution. About the only thing it solves is silently consuming a lone string of '<<' from the document. Other cases result in big red macro errors. > >> Currently the config.formatters are loose to trigger a match and more >> strict in applying the markup. > > That's right. I may say that not many people have got as far as you in > plumbing the depths of this code. I paid a lot of attention to > piggybacking on the (relatively) good performance of regular > expressions. Great performance- regex's are an often underestimated language that has been ported into almost every other language. This plugin has led me to learn about the complexities of grouping (), backreferences, and boolean behavior. I'm going to be ridiculously handy with 'sed' after this. > >> This would have the effect of making unmatched markup more obvious in >> the output (as the match characters are displayed). >> It also allows users to use characters that coincidentally look like >> markup but don't strictly follow it (using only one-half of an >> enclosed markup). >> I'm a bit fuzzy on it's application in some forms of markup. For >> example: if you don't close a bold tag '', then all text after those >> two characters are one big bold block. Is this intentionally lax with >> closing the tags? > > That seemed like the correct behaviour; at least the visual effect was > obvious, helping debug such mistakes. Ahh. I can definitely see the utility in making a visual cue for bad markup. Having a lone pair of unmatched markup characters in the text is also visually apparent- but also very small by comparison! Perhaps it is a side effect of the txt2tags markup that I am used to: much of the simpler markup cannot span lines (bolds, italics, urls). Anything that can span multiple lines is defined as a block- and those are open-ended just like most of tiddly markup. An opened "code" block in txt2tags need not be closed- it just extends to the end of the document. So I guess I've talked myself into these conclusions: 1) most of tiddly's markup is meant to span lines and errors are visually obvious, this is by design. 2) I will seek out the few examples of silently destructive markup (input characters disappear but no error/obvious markup explosion appears in the output tiddler). I will maybe come back with a full proposal if I find such examples. > > Best wishes > > Jeremy > >> >> Comments are encouraged. > >> -- >> David Young >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TiddlyWikiDev" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/tiddlywikidev?hl=en. >> >> > > > > -- > Jeremy Ruston > mailto:[email protected] > http://www.tiddlywiki.com > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWikiDev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/tiddlywikidev?hl=en. > > -- David Young -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
