Links Problem

[Stephen Kimmel]

I'm having a problem with TiddlyWilki rendering links inconsistently.

I've uploaded an example which using this bit of code, doesn't appear to be rendering links in columns 2 and 3 consistently.

<table>
<tr><th>Title</th><th>A href={!!sites}</th><th>Link</th></tr>
<$list filter=[tag[series]]>
<tr>
<td><$link to={{!!title}}><$view field="title"/></$link> </td>
<td><a href={{!!sites}} rel="noopener noreferrer" style="color:red" target="_blank">{{!!title}} </a></td>
<td> {{!!sites}}</td>
</tr>
</$list>
</table>

The third column appear to give actual links for everything. In Firefox, several of them are rendered in the colour typical of internal links while others are rendered in red. In 
Chrome, none of are rendered in red. 

The second column is particularly irritating since two of the entries are rendered and coloured as internal links while all the others are rendered as links to external web-sites.

I assume this is because of something I've done incorrectly, but for the life of me I can't figure out what I've done or why Tiddlywiki renders some of them correctly but not other.

Can someone tell me what is happening?

[Stephen Kimmel]

Sorry. Forgot the link: http://link-demo.tiddlyspot.com/

[Mat]

Stephen,

It is the CamelCasing spooking around. I've had this problem too. These alternatives seem to work. Not sure if any is better.:

<a href={{!!sites}} rel="noopener noreferrer"  style="color:red" target="_blank"><$view field="title" format="text">{{!!title}}</$view></a>

<a href={{!!sites}} rel="noopener noreferrer"  style="color:red" target="_blank"><$text text={{!!title}}></$view></a>

As for color diffs between chrome and FF, I'm guessing you can style them explicitly and globally to have them show correctly.

* a { color:foooooo }

..something like that. Didn't test it.

<:-)

[Mat]

Ref

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

<:-)

[Stephen Kimmel]

Thanks Mat.

Sometimes all you have to do is ask the question and the answer comes to you. About the time you were posting your response, I came up with the Camelcase answer myself... though the improperly colored like I get with the {{!!sites}} still baffles me.

I love TiddlyWiki and use it almost constantly but there is one thing I absolutely hate and that is CamelCase. I work with enough things that are automatically CamelCase... like about 90% of Scottish names and chemicals and now Japanese anime... that I spend far more time cancelling out the CamelCase than it saves me.

On Tuesday, May 2, 2017 at 4:58:47 PM UTC-5, Mat wrote:

Ref

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

<:-)

[Eric Shulman]

On Tuesday, May 2, 2017 at 6:33:27 PM UTC-7, Stephen Kimmel wrote:

I love TiddlyWiki and use it almost constantly but there is one thing I absolutely hate and that is CamelCase. I work with enough things that are automatically CamelCase... like about 90% of Scottish names and chemicals and now Japanese anime... that I spend far more time cancelling out the CamelCase than it saves me.

You can completely disable camel case linking for the entire document from the $:/ControlPanel "settings" tab:

http://tiddlywiki.com/#%24%3A%2FControlPanel

enjoy,

-e

[Stephen Kimmel]

True, though in the past at least that meant I had to either tolerate a bunch of ugly tildes or I had to hunt them down and delete them manually. Its a minor price to pay for TiddlyWiki but that doesn't stop it from irritating me. I'm equally positive there are users who can't imagine TiddlyWiki without CamelCase. Different strokes for different folks.

[PMario]

On Wednesday, May 3, 2017 at 4:53:02 AM UTC+2, Stephen Kimmel wrote:

True, though in the past at least that meant I had to either tolerate a bunch of ugly tildes or I had to hunt them down and delete them manually. Its a minor price to pay for TiddlyWiki but that doesn't stop it from irritating me. I'm equally positive there are users who can't imagine TiddlyWiki without CamelCase. Different strokes for different folks.

You are right, that's a problem. ... At the moment, disabling CamelCase linking completely disables the "tilde-parser" so all ~ signs are shown instead of being "eaten" without rendering the CamelCase link.

IMO it would be worth a github issue or a PR, since the existing implementation isn't backwards compatible.

-mario

[PMario]

On Wednesday, May 3, 2017 at 9:20:05 AM UTC+2, PMario wrote:

IMO it would be worth a github issue or a PR, since the existing implementation isn't backwards compatible.

I think it can be solved with a simple plugin, that could be part of the core in a second step.

-m

[PMario]

On Wednesday, May 3, 2017 at 4:53:02 AM UTC+2, Stephen Kimmel wrote:

True, though in the past at least that meant I had to either tolerate a bunch of ugly tildes or I had to hunt them down and delete them manually. Its a minor price to pay for TiddlyWiki but that doesn't stop it from irritating me. I'm equally positive there are users who can't imagine TiddlyWiki without CamelCase. Different strokes for different folks.

Hi,
I did add an attachment "unwikify-fix.json", which you can download and import to your TW. ...

It passes all TW tests if imported here. So there should be no compatibility problems. ...

I'll create a pull request shortly. ...

Feedback is very welcome!

have fun!
mario

[Mat]

PMario, thanks for creating and sharing!

I think it can be solved with a simple plugin, that could be part of the core in a second step.

Maybe I misunderstand you but IMO it should be a separate plugin that you can get-use-remove, i.e not anything that is part of the core plugin or the standard distro.

<:-)

[PMario]

IMO it should go into the core, since the existing handling is a bug. If someone disables wikilinks, there should be no other effects as NoWikilinks. At the moment if you use ~NoWikilink in the text and then disable the core wikilink parsing you'll see the tilde, which is the bug.

The new parser module will fix this in a backwards compatible way. ... But for the PR there is a little bit more refactoring needed. ... We'll see, what Jeremy says.

-m

[Mat]

IMO it should go into the core, since the existing handling is a bug. If someone disables wikilinks, there should be no other effects

 
Ya know, I take back my point. You're right. Especially considering that it is not necessarily a one-time thing as the user might switch back and forth between CamelCasing and plain.

<:-)