WikiWords in code
Henrik Jernevad
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.
DaveG
there is a similar problem with [[ test ]] used by Korn shells for
testing in if ... then.
Missing tiddlers popup with horrible names.
Problem: I like being able to link from that place sometimes.
How about {{{{ to }}}} means no auto linking?
Or perhaps \\\ to \\\
dave
Florian Cauvin
added in the Missing Tab. That's sad that the MissingTab becomes
unusable when you install plugins.
Eric Shulman
> Or perhaps \\\ to \\\
http://www.tiddlytools.com/#UnformattedTextPlugin
adds wiki-syntax to prevent wikify() processing of content by enclosing
it inside a pair of matching "superquotes" (THREE double-quotes in a
row)
Example:
"""These are unformatted: WikiLink, //italics//, <<macro>>, and so are
these...
----
*not a bullet
**not another bullet
"""
enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
Udo Borkowski
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
Jeremy Ruston
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
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Udo Borkowski
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/f2809b198fc46221/f11eaac51075d22d). 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
Martin Budden
Using plugins can cause your Missing tiddlers tag to fill up spurious
undefined tiddlers. This is because the Javascript used in plug-ins
often uses CamelCase for variable and functionnames etc. This is
clearly undesirable.
Solution: don't autolink wikiwords in tiddlers marked "systemConfig".
Simple and efficient to implement. Downside is that plug-in writers
need to use the [[ ]] format for their links. I think this is a
reasonable trade-off.
(Note also that it's not obligatory to put plug-ins in code blocks, so
there will be plug-ins that are not sorted by the formatter approach.
It is, of course, obligatory to tag plug-ins as "systemConfig".)
Martin
Eric Shulman
> Simple and efficient to implement. Downside is that plug-in writers
> need to use the [[ ]] format for their links. I think this is a
> reasonable trade-off.
Tiddlers tagged with 'systemConfig' are already excluded from being
included in the list of missing links (as are tiddlers tagged with
'excludeMissing')... this let's you still use use WikiWord autolinking
in plugins while avoiding listing the variable names, etc. as missing
links.
This is straight out of the TW core code:
-------------------------------------
// Return array of names of tiddlers that are referred to but not
defined
TiddlyWiki.prototype.getMissingLinks = function(sortField)
{
var results = [];
this.forEachTiddler(function (title,tiddler) {
if(tiddler.tags.find("systemConfig") == null &&
tiddler.tags.find("excludeMissing") == null)
for(var n=0; n<tiddler.links.length;n++)
{
var link = tiddler.links[n];
if(this.fetchTiddler(link) == null && !this.isShadowTiddler(link))
results.pushUnique(link);
}
});
results.sort();
return results;
}
-e
Chris Lawley
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 :-)
Jeremy Ruston
data tiddlers with 'excludeMissing' which causes them to be completely
skipped during processing of missing tiddlers.
Cheers
Jeremy
Udo Borkowski
Eric Shulman
> I think the answer for the AttachFilePlugin would be for it to tag
> data tiddlers with 'excludeMissing' which causes them to be completely
> skipped during processing of missing tiddlers.
The plugin does this already!
...from the http://www.TiddlyTools.com/#AttachFilePlugin version
history:
-----------------------
2005.12.27 [3.0.0] Update for TW2.0. Automatically add 'excludeMissing'
tag to attachments
-----------------------
-e
Martin Budden
code mentioned by Henrik were plugins, but I guess I was incorrect in
this assumption.
Martin
Martin Budden
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
Udo Borkowski
>
>The trouble is that you can have formats within formats.
>
Good point.
But in some cases the approach should work out fine, especially in the
"comment" and the "code block" case. So even this is not the perfect
solution for all cases I tend to stick to that approach since it avoids
a lot of links. For me a "per tiddler" solution seems to be to coarse.
(I am currently thinking of a "JavaScript" tutorial with a lot a sample
code (in code blocks) between the explanatory text. It would not be nice
if all WikiWords in the sample code would become links).
But maybe we could even find a solution for the counter example you
gave. I am thinking of two global functions suspendLinkify and
resumeLinkify that are used to control the "linkification". But this
needs some more thoughts....
Udo
----------
Udo Borkowski
http://www.abego-software.de