> Here the idea:

> every formatter may have the optional property "linkifier" that refers
> to a function like this:

>     function(links) {
>         ...
>     }

> This function should add all links to the array "links" that are
> contained in the text controlled by the formatter. It is up to the
> formatter to determine what is a link and what not. When no
> "linkifier" is defined for a formatter the old approach as implemented
> in Tiddler.prototype.changed is used.

> According to this a formatter like the comment formatter could be
> changed to this:

>     {
>         name: "commentByBlock",
>         match: "/%",
>     *    linkifier: function(links) {},*
>         lookahead: "/%((?:.|\\n)*?)%/",
>         ...

> I.e. this formatter will add no links.

> I assume that very few formatters will require this special linkifier
> function, for most ones the standard approach is sufficient, i.e. the
> formatter don't need to be changed. (Macros are handled very similar,
> i.e. the Macro formatter just propagates the linkifier call to the
> macro, or calls the old linkifier code.)

> Beside this formatter specific change the Tiddler.prototype.changed
> must be changed to use a modified version of the Wikifier. My initial
> idea was just to pass the links array to the Wikifier:

>     function Wikifier(source,formatter,highlightRegExp,tiddler,links)

> If links is defined the wikifier adds the links, otherwise it behaves
> as before (i.e. normal wikification). I haven't analysed the solution
> completely but I assume that only the Wikifier.prototype.subWikify
> needs to be changed.

> Jeremy's idea of introducing "modes" is an extension of this idea with
> the extra "links" parameter. So maybe we can just add a "mode" and a
> "data" parameter to Wikifier to cover this more general case. Or just
> one single new "options" parameter that will contain all future
> options for the Wikifier (e.g. "options.mode" and "options.links" etc.)

> Just a note regarding the {{{ }}} case: This is a little special. It
> may not be obvious if the text inside the braces should be considered
> as links or not. For the pure "{{{ ... }}}" links should probably
> ignored, but for the general "customClasses" case the {{...{ ... }}}
> may be just used to put a certain style on a "normal" text that
> contains links. Any idea?

> In case this change is going to happen I'd like to remind of the
> "replace the link array by a hashmap" idea
> (http://groups.google.com/group/TiddlyWikiDev/browse_frm/thread/f2809b...).
> I suggest to do that change at the same  time (or before) to make sure
> we don't need to change the API for the linkifier function from an
> "links array" to an "links object" later. A later change may lead to
> difficulties if some plugin writer has already written his own
> "linkifier" function for some external formatter/macro.

> Udo

> Jeremy Ruston wrote:

>>The idea that runs through my head with this is to introduce the idea
>>of wikifier "modes". There could be four:

>>normal - wikify text into an HTML DOM element as usual
>>html - wikify text into an HTML string (for use in RSS feeds and
>>statically rendered tiddlers)
>>plain - wikify text into a plain string (for use in site titles and subtitles)
>>link - wikify text but throw away the result apart from a list of the
>>links in the text

>>(You can imagine simplying it further, for instance by combining link+normal)

>>The trouble, of course, is that such a change would dribble down to
>>require every formatter and every macro to be changed, I think.

>>Cheers

>>Jeremy

>>On 15/06/06, Udo Borkowski <Udo.Borkow...@gmx.de> wrote:

>>>No solution but just some background information:

>>>In the current implementation the Tiddler text is checked for WikiWords
>>>and "pretty links" after every change (pressing "done" in the tiddler
>>>menu), without looking for any context (e.g. if a word is in a code
>>>block, or a comment etc). This makes it very fast to determine the
>>>links, but also somehow inexact. A more precise solution would required
>>>a more detailed analysis, taking care of the various formatters and
>>>marcos and whether text they contain is wikified or not. This is even
>>>complicated by the fact that new formatters may be added by plugins: it
>>>would be fine if text controlled by these formatter would create the
>>>correct "links".

>>>This issue was already discussed some time ago but no nice solution was
>>>yet found/implemented. I guess Jeremy will welcome any nice
>>>suggestion/implementation.

>>>Udo

>>>----------
>>>Udo Borkowski
>>>http://www.abego-software.de

>>>Henrik Jernevad wrote:

>>>>Is it possible to make TW *not* recognize a WikiWord in a {{{ code }}}
>>>>block? Adding ~ before the word obviously gets shown in the code
>>>>instead.

>>>>While a WikiWord in a code block doesn't get a link, it does get listed
>>>>in the Missing tab. This is a pain when you list a lot of source code
>>>>and don't want your Missing tab to be filled up with e.g. names in
>>>>CamelCase.

>The trouble is that you can have formats within formats.

>The trouble is that you can have formats within formats. Consider some
>''bold'' text, under the proposal, the bold formatter would call the
>"linkifier". However the bold text could be inside a code block, or a
>comment block, and so shouldn't call the linkifier. Currently
>formatters only know their own context, and not the context of the
>block of text they are in (changing this would be difficult and would
>slow things down considerably). And formatters can nest to any level.

>I think the only reasonably approach is to apply the rule at a tiddler
>level as currently (ie tiddlers tagged systemConfig or excludeMissing).

>Martin

> The idea that runs through my head with this is to introduce the idea
> of wikifier "modes". There could be four:

> On 16 Jun 2006, Jeremy Ruston wrote:

> > The idea that runs through my head with this is to introduce the idea
> > of wikifier "modes". There could be four:

> Does that cope with plugins like AttachFilePlugin which, if use to
> embed a binary file creates, oooh, lots of missing entries.

> I suppose some concept of having a system tiddler that has a list of
> invalid missing tiddlers is out of the question?

> It'd need to be able to amended by the user to add/remove entries.

> It'd need to be automatically updated so that you'd not spend ages
> fixing up erroneous AttachedFile entries.

> It _does_not_ sort out getting the system to handle things, but
> might allow a simple way to pick up 'special' situations that are
> hard to code for or are created by the user.

> chris :-)