contains this text:
the source looks correct to me, but it doesn't render correctly (the first = is present, and the text isn't monospaced)
I suspect it's because the individual sections are square-bracketed links.
Here is a test case showing the bug:
- line with
double bold containing == equal equal text
- next line with
* line with ==double bold containing == equal equal== text
* next line with =bold1=, =bold2=
Bug happens also on same line:
double bold containing
= equal equal
text, and on same line text with =bold1,
One of the double equal signs is removed, and subsequent fixed text does not render as fixed text.
The = equal sign should only take action if adjacent to non-white space, that is, == equal equal should be rendered as is and should not affect subsequent rendering.
See also Item1279
In fact the definition of the formatting syntax is quite unclear, but seems to suggest that only words within the "braces" will be formatted. Documentation accompanying previous releases has leveraged this "relaxed" definition to give undocumented render effects such as those you describe.
The problem here is the line-by-line context used by Cairo. If I write
A == B and C == D
it will break Cairo. Dakar uses the same rendering rules as Cairo, but it applies them in the context of the whole document, rather than line by line (applying to the whole document is a lot more efficient).
I tuned the REs a bit more to handle the case above, though the case in Item1279
is a result of another bugfix, viz. treating < as a wikiword delimiter. It can be "fixed", but only at the cost of re-introducing a number of other error cases. It can be worked around by simply removing the <br />
I am concerned that the workaround to account for "<" does not account for all border cases. In fact, Item1279
is not fixed yet.
You are right that the documentation is not very explicit. The way Cairo works is that emphasizing (fixed font, italic and bold text) works only line by line on word boundaries (including punctuation). That is, word is not taken as a WikiWord, but as word separated by whitespace + punctuation.
Here is the Cairo regex for the = rendering:
If you take this for Dakar on a line by line scan you get the desired behavior.
Indeed, the latest fix introduces new bugs. The Sandbox
starts now with this:
The following settings are web preferences__ of the Sandbox web. These preferences overwrite the site-level preferences in TWikiPreferences, and can be overwritten by __user preferences
(your personal topic, eg: TWikiGuest
in the Main
The Dakar REs are identical to the Cairo rules, except in respect of < and line by line processing. I removed line-by-line processing for a measurable improvement in rendering speed (anything done in the per-line rendering loop is expensive).
SVN 8062 I took < out again, even though it may re-introduce a known problem, and tuned the REs further to account for the case above, which is quite valid. However I am not going to do any more on this until there is either:
- a documented, unambiguous (what is "punctuation"?) spec of the emphasis "rules" or
- a valid set of testcases (strongly preferred) that exrcise the full range of expected behaviours.
Testcases are the only sensible way to close this discussion properly, and are essential for further developments anyway. Here are a few to get you started:
- Should be
code = equal code text. Should be
- double equal
containing == here, with
- next line with
- Should see equal equal
= and then equal equal = with no emph
- line with double undies containing _ undies text with and _added undies
- next line with undies, undies
- Corner case here double_ should still be emph_
Should not be emph.
Some overlapping tags
like this - which generates illegal XHTML that also breaks XML such as RSS feeds.