The problem is created by TWiki's rule that WikiWords have to be prefixed by a whitespace. Peter T regards this a feature - it is the same reason as causes BoldTWikiWordsAreNotHyperlinked.

Peter - would you be willing to allow > as a leading character?

-- MartinCleaver - 09 Nov 2003

This looks to be a good idea, but doesn't anything break e.g. use of <nop>? If this would break, then we might have a performance issue to look-back (is that the right term) to avoid this being treated as a Wiki word.

-- JohnTalintyre - 09 Nov 2003

Yes, it does break <nop>, but I guess that's what we get from mixing unorthagonal types (i.e. it is not a problem with %NOP%).

If you value purity of topics and speed, I recommend:

1. Discourage the use of <nop> in favour of %NOP% (and replacing <verbatim> with %VERBATIMSTART/STOP%)
2. Convert such tokens on topic reedit (using a plugin that can be thrown away)
3. Add a plugin that hooks into the preview cycle and gives a warning to discourage further use of <nop>

If you prefer to not do this:

1. Further sensitise the regex for WikiWords, or
2. Refine the hack plugin that I wrote (this would require a complementary hook that gets hold of the topic text to remove additional spacing before the topic is edited again).

-- MartinCleaver - 09 Nov 2003

I vote against this change for two reasons:

1. It breaks existing content. It is documented and users know that automatic linking of WikiWords is only done if preceeded by white space or parenthesis. These few examples are used more then rarely, a change in spec would break the content:

- <nop>WikiWord            (user escapes WikiWord)
- <u>WikiWord</u>          (user wants to underline and escape a WikiWord)
- <img src=... />WikiWord  (user wants to add image and escape a WikiWord)
- etc.

2. Multiple rendering problem. The TWiki renderer is called more then once under certain circumstances, e.g. by includes, by nested Plugins etc. If you allow > before a WikiWord we would get invalid rendering:

- Source:        WikiWords
- 1st rendering: <a href="/cgi-bin/view/Codev/WikiWord">WikiWords</a>
- 2nd rendering: <a href="/cgi-bin/view/Codev/WikiWord"><a href="/cgi-bin/view/Codev/WikiWord">WikiWords</a></a>
- 2nd rendering: etc.

The second problem could be fixed in the code with an intelligent (and slow) algorithm.

It seems to me that the real solution for the HtmlAreaEditor is to do a post processing of the HTML data.

-- PeterThoeny - 09 Nov 2003

I disagree that the side effect of disabling a WikiWord by putting it inside any sort of markup is desirable from a users point of view. I reluctantly agree that it simplifies parsing but assert this policy adds a non-intuitive and non-desirable rule that complicates the users world, hence the confusion in BoldTWikiWordsAreNotHyperlinked. If they wanted bold but not linked they could say *<nop>WikiWord*. The current implementation prevents them to not be able to have both bold and linked. Regardless of what we do for HtmlTopicEditing, I would like to see us rid of this restriction.

Mutliple Rendering: this strikes me as a legitimate problem. TWiki's parser is so complicated that I would not dare to mess with it. (In the long run I hope to see all TML processing out of the core, at that point we might be able to see whether multiple rendering is really necessary).

Because of the MultipleRenderingMechanism (is this documented anywhere?), I accept that the best way is for HtmlTopicPlugin to pre and post process such that the HTML is manipulated before and after it is dealt with by its Browser particular HtmlEditors.

-- MartinCleaver - 09 Nov 2003