see http://develop.twiki.org/~develop/cgi-bin/view/TWiki/SpreadSheetPlugin#FuncIF

contains this text:

• • Related: $AND(), $EXACT(), $LISTIF(), $NOT(), $OR()

the source looks correct to me, but it doesn't render correctly (the first = is present, and the text isn't monospaced)

WN

I suspect it's because the individual sections are square-bracketed links.

CC

Here is a test case showing the bug:

• line with double bold containing == equal equal text
• next line with bold1, bold2

written as:

   * 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, bold2.

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.

PTh

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 />

SVN 8054

CC

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:

([\s\(])=([^\s]+?|[^\s].*?[^\s])=([\s\,\.\;\:\!\?\)])

If you take this for Dakar on a line by line scan you get the desired behavior.

-- PTh

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 web).

-- PTh

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:

1. a documented, unambiguous (what is "punctuation"?) spec of the emphasis "rules" or
2. 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:

1. Should be code = equal code text. Should be equal
2. double equal containing == here, with another equals
3. next line with bold1, bold2
4. Should see equal equal = and then equal equal = with no emph
5. line with double undies containing _ undies text with and _added undies
6. next line with undies, undies
7. 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.

CC