[TW5] How do I stop automatic link creation?

[Thameera Senanayaka]

Hi all,

Been using TW5 for about two months and I'm really happy with it.

One small question: When I type in some strings like two words combined with a hyphen (eg: Ctrl-A) TW5 thinks it's a link and shows as a hyperlink when viewing. 

Is there a way I can tell it to mark it as a link only when I explicitly mark using square brackets?

[Stephan Hradek]

If you want to mess with the code - which might lead to problems when upgrading - yes. Just change the code of

$:/core/modules/parsers/wikiparser/rules/wikilink.js appropriately.

Or put a ~ before those words.

[thame...@gmail.com]

Putting ~ worked. Thanks!

I'm hosting the wiki at tiddyspot. How would changing a core module's code affect it?

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/1VW2_tqRHbI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

--

http://twitter.com/thameera

http://thameera.com

[Stephan Hradek]

Am Samstag, 5. Juli 2014 15:57:56 UTC+2 schrieb Thameera Senanayaka:

I'm hosting the wiki at tiddyspot. How would changing a core module's code affect it?

I don't know what I should answer to that. Changing a core module would of course change your wiki. Why would it not?

[thame...@gmail.com]

I don't know what I should answer to that. 

Should've phrased it better. :) How would changing the code modules affect the updating, etc of the wiki? Is changing the core modules something normally done by the TW users? 

--

You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/1VW2_tqRHbI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[Stephan Hradek]

Am Samstag, 5. Juli 2014 20:16:40 UTC+2 schrieb Thameera Senanayaka:

I don't know what I should answer to that. 

Should've phrased it better. :) How would changing the code modules affect the updating, etc of the wiki? Is changing the core modules something normally done by the TW users? 

Still don't get it.

When you change a core module, and then choose to update to a newer version of TW, what do you think will happen to the core module you changed?

Either the update overwrites it -> You need to remember the change you made and need to redo your change
Or your change will be kept but then the new core module could have changed internally and so your change could break everything.

 

[thame...@gmail.com]

I see. Thanks for the answer!

--

You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/1VW2_tqRHbI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[Måns]

Hi Thameera

Putting ~ worked. Thanks!

You can disable automatic wikilinking from a tiddler by writing:

\define tw-wikilinks() no

at the top of the tiddler..

Cheers Måns Mårtensson

[thame...@gmail.com]

On Sun, Jul 6, 2014 at 3:21 PM, Måns <huma...@gmail.com> wrote:

You can disable automatic wikilinking from a tiddler by writing:

\define tw-wikilinks() no

Nice! That can be more convenient when there are a lot of false positives.

Thanks!

[Matabele]

Hi

In that case, since version 5.0.13, this macro could be included as a global macro or in a macro group using the <$importvariables> widget.

regards

[thame...@gmail.com]

On Sun, Jul 6, 2014 at 8:00 PM, Matabele <matabe...@gmail.com> wrote:

since version 5.0.13

I have 5.0.12-beta in this (hosted at tiddlyspot). Should find a way to upgrade. 

Thanks! It's much nicer if automatic linking can be turned like that forever.

[Michael]

I always wondered, why words containing hyphens (e.g. Ctrl-A) are considered as WikiLinks.

To create WikiLinks from words that are written in CamelCase makes absolute sense, since these words are arbitrarily written in that way, and CamelCase is an established way of 'marking up' specific words, e.g. variables, when programming. Words with hyphens, on the other hand, are rather abundant in certain languages, such as German.

Rather than having to disable WikiLinks altogether or case by case when writing in a language that contains many hyphenated words, wouldn't it make more sense to exclude them completely from the CamelCase rule?

Cheers,

Michael

[Jeremy Ruston]

On Sun, Jul 6, 2014 at 3:53 PM, Michael <michae...@infrafrontier.eu> wrote:

I always wondered, why words containing hyphens (e.g. Ctrl-A) are considered as WikiLinks.

There's been some discussion on this:

https://github.com/Jermolene/TiddlyWiki5/issues/337

As I commented on the ticket, I think that camelcase detection should be much more conservative, and shouldn't consider underscore and dashes to be letters.

I'll try to sort this ticket out for 5.0.14.

Best wishes

Jeremy

 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[Matabele]

Hi

It might be an idea if automatic linking occurred only if a tiddler of that name already exists (automatic linking suppressed in the event that a tiddler of that name does not exist.)

Perhaps this could be expressed in the form of a global macro:

\define tw-wikilinks() if filter="[field:title[mylink]]" then 'yes' else 'no'

Any ideas?

regards

[Jeremy Ruston]

Hi Matabele

It might be an idea if automatic linking occurred only if a tiddler of that name already exists (automatic linking suppressed in the event that a tiddler of that name does not exist.)

Perhaps this could be expressed in the form of a global macro:

\define tw-wikilinks() if filter="[field:title[mylink]]" then 'yes' else 'no'

Any ideas?

Automatic linking to missing tiddlers is a pretty useful core wiki feature. There would be a performance penalty for making it configurable. A wrinkle is that we actually do automatic link detection at parse time (rather than render time). Because we cache the results of parsing a tiddler the parsing process mustn't depend on the values of any other tiddlers. So there'd have to be some rejigging to get things working properly.

Best wishes

Jeremy

[Matabele]

Hi

On Tuesday, July 8, 2014 9:38:22 AM UTC+2, Jeremy Ruston wrote:

Hi Matabele

Automatic linking to missing tiddlers is a pretty useful core wiki feature.

Why so? If I wish to create a 'missing link' for automatic tiddler creation, I can easily surround the 'missing link' with double brackets in a deliberate manner -- this only applies to CamelCase 'missing links' in any case. 

 

There would be a performance penalty for making it configurable.

Perhaps automatic linking to missing tiddlers should be suppressed by default.

 

A wrinkle is that we actually do automatic link detection at parse time (rather than render time). Because we cache the results of parsing a tiddler the parsing process mustn't depend on the values of any other tiddlers. So there'd have to be some rejigging to get things working properly.

Might be worthwhile -- I am accustomed to the idea of automatic linking (as in Tomboy) -- indeed, it would be useful if automatic linking were extended from CamelCase strings to any string matching an existing tiddler title. 

In summary:

1.  I am of the opinion that the suppression of automatic linking of CamelCase forms in piecemeal fashion is more troublesome than having to deliberately mark 'missing links'

2.  Automatic linking of strings matching existing tiddler titles is useful and should perhaps be extended to non CamelCase strings

regards

[Jeremy Ruston]

Hi Matabele

I've seen the approach of matching any existing tiddler title as a link (regardless of double square brackets), and I can see the attraction in simple cases. But as I say, the problem for TW5 is that at the time of parsing a tiddler we don't know which tiddlers will exist at the time(s) that it is rendered.

Best wishes

Jeremy

[Matabele]

Hi

On Tuesday, July 8, 2014 11:00:34 AM UTC+2, Jeremy Ruston wrote:

Hi Matabele

I've seen the approach of matching any existing tiddler title as a link (regardless of double square brackets), and I can see the attraction in simple cases.

I have no idea how Tomboy manages to parse text for all links to existing notes, but find this kind of linking to be a 'magic' feature of Tomboy, lacking in most other wiki software. 

 

But as I say, the problem for TW5 is that at the time of parsing a tiddler we don't know which tiddlers will exist at the time(s) that it is rendered.

When are tiddlers parsed? If this is a matter of refreshing the browser, I don't see this as much of a problem. The only outstanding links will be for those tiddlers created after the tiddler in question.

The difficulty will be that the text field would have to parsed for strings matching all existing titles rather than only for CamelCase forms. Suppressing automatic linking of CamelCase forms for non-existent tiddlers would be simpler as this involves parsing only for CamelCase forms, then checking for valid links.

regards

[Stephen Kimmel]

As long as you are modifying the handling of camelcase, could you give us an easy option to disable it completely? As someone who works in room A304H with my friend McMullin about matters concerning the chemistry of H2S and H2O for such companies as ExxonMobil, I can safely say that I've had to over-ride the camelcase hundreds of times for every time I've had a use for it. I have modified the tiddler that drives the interpretation of camelcase but an option would be a much better answer.

Stephen

[Jeremy Ruston]

Hi Matabele

I have no idea how Tomboy manages to parse text for all links to existing notes, but find this kind of linking to be a 'magic' feature of Tomboy, lacking in most other wiki software. 

 

But as I say, the problem for TW5 is that at the time of parsing a tiddler we don't know which tiddlers will exist at the time(s) that it is rendered.

When are tiddlers parsed? If this is a matter of refreshing the browser,

Parsing is the first stage of the rendering pipeline that converts wikitext into HTML:

http://tiddlywiki.com/#TiddlyWiki%20Architecture

  

I don't see this as much of a problem. The only outstanding links will be for those tiddlers created after the tiddler in question.

TiddlyWiki wikitext is really an implementation of a "tiddler algebra" that allows user interfaces to be dynamically rendered from state data stored in tiddlers. Just like real math, the algebra has to behave consistently and reliably in order for users to be able to learn how it works.

The difficulty will be that the text field would have to parsed for strings matching all existing titles rather than only for CamelCase forms.

Yes, and the issue is that we want the link to reflect the status of the target tiddler at render time, not parse time.

 

Suppressing automatic linking of CamelCase forms for non-existent tiddlers would be simpler as this involves parsing only for CamelCase forms, then checking for valid links.

Automatic linking of CamelCase links to non-existent tiddlers is a core part of the wiki way. The idea is to be able to write links to tiddlers before you go back and fill in the references. The missing tiddlers tab ends up being a "todo list" that is dynamically built from the tiddlers that have been referenced but not filled in.

Best wishes

Jeremy.

 

regards

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.

Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[Matabele]

Hi Jeremy

Please excuse my labouring the point, but I am trying to find the best way to address the issue raised by Stephen Kimmel in the previous post without interfering with the essential features of TW.

Automatic linking of CamelCase links to non-existent tiddlers is a core part of the wiki way. The idea is to be able to write links to tiddlers before you go back and fill in the references. The missing tiddlers tab ends up being a "todo list" that is dynamically built from the tiddlers that have been referenced but not filled in.

Links to 'missing tiddlers' are easily bracketed with double boxes for this purpose, which has the added advantage that non CamelCase titles may be used in this way. Linking to 'missing tiddlers' is certainly a core part of the wiki way, but automatic linking of CamelCase forms to 'missing tiddlers' appears to have a downside that outweighs the advantages.

Having to place brackets around CamelCase titles in the few instances when these tiddlers are non-existent at the time appears to be a small price to pay for avoiding the problems of automatic linking of all CamelCase forms.

The only downside of suppressing automatic linking of CamelCase to 'missing tiddlers' appears to be that a few CamelCase strings will not function as links until the browser is refreshed? This might present a theoretical travesty but in practice I don't think many users would find this much of a problem.

regards

[Jeremy Ruston]

Hi Matabele

Please excuse my labouring the point, but I am trying to find the best way to address the issue raised by Stephen Kimmel in the previous post without interfering with the essential features of TW.

No worries, this is complex stuff, and good to get a chance to discuss it. 

Automatic linking of CamelCase links to non-existent tiddlers is a core part of the wiki way. The idea is to be able to write links to tiddlers before you go back and fill in the references. The missing tiddlers tab ends up being a "todo list" that is dynamically built from the tiddlers that have been referenced but not filled in.

Links to 'missing tiddlers' are easily bracketed with double boxes for this purpose, which has the added advantage that non CamelCase titles may be used in this way. Linking to 'missing tiddlers' is certainly a core part of the wiki way, but automatic linking of CamelCase forms to 'missing tiddlers' appears to have a downside that outweighs the advantages.

Having to place brackets around CamelCase titles in the few instances when these tiddlers are non-existent at the time appears to be a small price to pay for avoiding the problems of automatic linking of all CamelCase forms.

The trouble is that that is not how CamelCase links normally work, and makes the mechanism and rules governing it more complicated.

As I've said before I think the resolution to the problems raised here are to disable camelcase links (which is already possible), and to be stricter about which strings qualify as camelcase words. The basic problem as I see it is that the camelcase rules are too broad, leading to unexpected links appearing.

 

The only downside of suppressing automatic linking of CamelCase to 'missing tiddlers' appears to be that a few CamelCase strings will not function as links until the browser is refreshed? This might present a theoretical travesty but in practice I don't think many users would find this much of a problem.

I think you're conflating two subtly different issues:

* Suppressing automatic linking of CamelCase links to missing tiddlers can be done by modifying the link widget without problems (it already has conditional logic to disable a link based on the tw-wikilinks variable setting; see http://tiddlywiki.com/#LinkWidget)

* The ability to recognising any existing tiddler title as a link, regardless of whether it uses camel case or quotes. This is the thing that's not possible with the current rendering pipeline - it is not a theoretical matter: it is about how TiddlyWiki works

Best wishes

Jeremy

 

regards

[Matabele]

Hi Jeremy

On Wednesday, July 9, 2014 3:27:39 PM UTC+2, Jeremy Ruston wrote:

* Suppressing automatic linking of CamelCase links to missing tiddlers can be done by modifying the link widget without problems (it already has conditional logic to disable a link based on the tw-wikilinks variable setting; see http://tiddlywiki.com/#LinkWidget

This is the approach I am suggesting. The downside I referred to appears to be that CamelCase strings without enclosing square brackets created before the linked tiddler is created will not function as links until the browser is refreshed and the wikitext is re-parsed (or am I still missing something?) 

regards

[Jeremy Ruston]

* Suppressing automatic linking of CamelCase links to missing tiddlers can be done by modifying the link widget without problems (it already has conditional logic to disable a link based on the tw-wikilinks variable setting; see http://tiddlywiki.com/#LinkWidget

This is the approach I am suggesting.

 

The downside I referred to appears to be that CamelCase strings without enclosing square brackets created before the linked tiddler is created will not function as links until the browser is refreshed and the wikitext is re-parsed (or am I still missing something?) 

That's not correct. The issue about parsing vs. rendering relates to the freelinking idea of automatically linking any existing tiddler title. The bit about links not functioning until the browser is refreshed is not something that I said, I don't know where that came from.

Best wishes

Jeremy

 

regards

[Matabele]

Hi

On Wednesday, July 9, 2014 3:40:50 PM UTC+2, Jeremy Ruston wrote:

That's not correct. The issue about parsing vs. rendering relates to the freelinking idea of automatically linking any existing tiddler title. The bit about links not functioning until the browser is refreshed is not something that I said, I don't know where that came from.

In that case -- what's the downside of this approach?

regards

[Jeremy Ruston]

Hi Matabele

 

That's not correct. The issue about parsing vs. rendering relates to the freelinking idea of automatically linking any existing tiddler title. The bit about links not functioning until the browser is refreshed is not something that I said, I don't know where that came from.

In that case -- what's the downside of this approach?

The downside of this approach is that it doesn't work within TiddlyWiki's rendering pipeline: at parse time we don't know which tiddlers will exist by the time the parsed content is rendered.

Best wishes

Jeremy

regards