I'd like to make the case for having an option to turn off automatic
link generation of WikiWords. Reasons include:
1) I think TiddlyWiki can be used as a document distribution mechanism.
So rather than send someone an MS Word file, or a .pdf, you can send
them a TiddlyWiki .html file, and be confident that they can read it.
However, you don't want this document filled with lots of differently
formatted missing links. There are a surprising number of these in
ordinary English text, and an even larger number in jargon text.
Turning off the auto link generation would enable you to send a
document that, to the receiver, looked like an ordinary document with
links. (That is it better enables TiddlyWiki as a Guerilla document
distribution system.)
2) Other Wikis offer this option.
3) We've been using Wikis at work for about 3 years. Our department was
the first to have one and we turned off auto linking fairly early on.
Other departments have followed our lead and adopted Wikis. Over half
elect to turn off auto linking.
4) Even if you want to have auto linking on, turning it off momentarily
lets you list your missing [[...]] links, which is useful.
5) (From a personal perpective) There were two things I needed to be
able to use TiddlyWiki effectively: the ability to turn off
auto-linking (which was the first change I implemented) and week
numbers (which was the second change I implemented).
I've got an implementation, but I've refrained from posting it because
I might change it slightly to deal with the "Minor error updating
links[] in Tiddler.prototype.changed function" defect I posted.
What's your view?
Martin
has been around for quite a while...
enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
Agreed... it's a very small change, and I'd be happy to retire this
little plugin (and save a little space on TiddlyTools). On the other
hand, LOTS of things are 'small changes' that would be 'nice to have'
in the core...
It's entirely up to Jeremy to make the call on this one...
-e
I can completely understand why wikilinking isn't desirable in all
circumstances, and I think Eric's plugin serves them well. I'm not
inclined to put it in the core because:
- As Clint says, it would have a knockon effect in having to rewrite
the shadow tiddelr text to use [[manual links]]. Given that
wikilinking is one of the distinctive characteristics of a wiki, I
think that TW itself should use it; shadow tiddlers that have
apparently redundant [[SquareBrackets]] will surely confuse people
- It's yet another user interface option; I believe that each time we
add another checkbox we confuse 10 people for every 1 person that we
help - there's a significant support traffic from people who've simply
flipped a setting and forgotten about it. I recognise that people have
a multiplicity of needs from tools like TiddlyWiki, and I believe that
plugins is the best mechanism for accommodating everyone's needs while
keeping the core focussed.
Anyway, this is clearly still largely a matter of personal opinion so
shoot me down if you think I'm wildly off-base here.
Cheers
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
On the issue of "yet another user interface option", I hadn't fully
thought this through and now I have I agree with you. I propose the
following compromise: the (minor) changes to the "wikiLink" formatter
and the Tiddler.prototype.changed function go into the core, since
these are actually quite difficult to get right, and a plug-in writer
would also have to duplicate much of the existing code. This would then
enable a simplified plug-in that either just set the flag, or just
added an item to the AdvancedOptions tiddler.
On the question of whether this should go in the core, I'll re-iterate
my motivation: I believe that we can extend the usage space of
TiddlyWikis. A TiddlyWiki is a great portable document distribution
format, since it can be read on any machine that has a browser.
However, to be widely acceptable, these distributed documents should
not be cluttered with missing links. As I've implied in other postings
I think the bar to acceptance in the core should be high, and certainly
anything accepted should not have side-effects, or break content or
macro compatibility.
The current change follows. Note that this is not what I would propose
to submit, since if I did this, I would combine it with ticket35 (the
minor updating links[] error). I'd probably also reverse the sense of
the flag, that is make it config.options.chkDontAutoLinkWikiWords
I hope I convince you Jeremy. I await your response, since it will
affect how I address ticket 35.
Here's the current code (note that it deals with shadow tiddlers, this
was built in from the start)
config.options = {
...
chkAutoLinkWikiWords: true //MB**
}
...
{
name: "wikiLink",
match: config.textPrimitives.wikiLink,
badPrefix: config.textPrimitives.anyLetter,
handler: function(w)
{
var preRegExp = new RegExp(config.textPrimitives.anyLetter,"mg");
var preMatch = null;
if(w.matchStart > 0)
{
preRegExp.lastIndex = w.matchStart-1;
preMatch = preRegExp.exec(w.source);
}
if(preMatch && preMatch.index == w.matchStart-1)
w.outputText(w.output,w.matchStart,w.nextMatch);
else if(w.matchText.substr(0,1) == config.textPrimitives.unWikiLink)
w.outputText(w.output,w.matchStart + 1,w.nextMatch);
else
{//MB**
if
(config.options.chkAutoLinkWikiWords||store.isShadowTiddler(w.matchText))
{
var link = createTiddlyLink(w.output,w.matchText,false);
w.outputText(link,w.matchStart,w.nextMatch);
}
else
{// otherwise don't treat WikiWords as links
w.outputText(w.output,w.matchStart,w.nextMatch);
}
}
}
},
...
// Updates the secondary information (like links[] array) after a
change to a tiddler
Tiddler.prototype.changed = function()
{
this.links = [];
var nextPos = 0;
var theLink;
var aliasedPrettyLink =
"\\[\\[([^\\[\\]\\|]+)\\|([^\\[\\]\\|]+)\\]\\]";
var prettyLink = "\\[\\[([^\\]]+)\\]\\]";
var wikiNameRegExp = new RegExp("(" + config.textPrimitives.wikiLink +
")|(?:" + aliasedPrettyLink + ")|(?:" + prettyLink + ")","mg");
do {
var formatMatch = wikiNameRegExp.exec(this.text);
if(formatMatch)
{//MB**
if(formatMatch[1])
{// it's a wikiLink
if(store.isShadowTiddler(formatMatch[1])// always add
shadowTiddlers
|| (config.options.chkAutoLinkWikiWords &&
formatMatch[1].substr(0,1) != config.textPrimitives.unWikiLink &&
formatMatch[1] != this.title))
{
this.links.pushUnique(formatMatch[1]);
}
}
else if(formatMatch[2] && (store.tiddlerExists(formatMatch[3]) ||
store.isShadowTiddler(formatMatch[3])))
this.links.pushUnique(formatMatch[3]);
else if(formatMatch[4] && formatMatch[4] != this.title)
this.links.pushUnique(formatMatch[4]);
}
} while(formatMatch);
return;
}
you don't actually need to duplicate the code from the "wikiLink"
formatter definition...
Instead, just 'hijack' the formatter's handler to bypass the standard
behavior when the option flag is set.
The plugin code then just adds the *extra* functionality, without
replicating the code from core handler...
Here's how it is done in
http://www.tiddlytools.com/#DisableWikiLinksPlugin...
-----------------------
if (config.options.chkDisableWikiLinks==undefined)
config.options.chkDisableWikiLinks=false;
for (var i=0; i<config.formatters.length &&
config.formatters[i].name!="wikiLink"; i++);
config.formatters[i].coreHandler=config.formatters[i].handler;
config.formatters[i].handler=function(w) {
if (!config.options.chkDisableWikiLinks) return this.coreHandler(w);
// supress any leading "~" (if present)
var
skip=(w.matchText.substr(0,1)==config.textPrimitives.unWikiLink)?1:0;
w.outputText(w.output,w.matchStart+skip,w.nextMatch);
}
-----------------------