[TW5] Link rendering

[Arkady Grudzinsky]

Jeremy,

I noticed that TW5 does not allow to use custom protocols for links.  E.g. [[Link|http://someurl.com]] is rendered as a link to the web page.  I think, there is a set of protocols rendered as external links (http:, https:, ftp:; mailto:, etc.)  But any protocol outside this set is rendered as a link to a tiddler.  This takes away one useful capability I had with TWC.  I often need my tasks in mGSD to be linked to emails.  In mGSD, I can create a link to an email as follows:
 
[[Email|mutt://<message_id>]]

I have a protocol handler set up in Firefox which makes Firefox open a shell script that extracts the message_id and opens the specific email in mutt client.  There is a Thunderlink Firefox add-on as well which allows to link emails as "thunderlink://message_id".  However, TW5 does not interpret mutt:// as a protocol and opens an empty tiddler named "mutt://message_id" instead. 

Is there a compelling reason to check the protocol name?  If not, I'd like TW5 to allow me define my own protocols at the expense of an occasional browser error message.  By the way, TW5 does not seem to recognize the magnet:// protocol used for torrents as well.

I can still link to Gmail messages using http:// syntax, but I'd rather not be limited in my choice of a mail client.

[Stephan Hradek]

Not too long ago Jeremy wrote something about it: https://groups.google.com/d/msg/tiddlywikidev/6pEU2E5VcTo/F8YyYaLKQhwJ

[Arkady Grudzinsky]

Thanks.  Back then, you suggested a regexp

/[a-z][a-z0-9+.-]*:/

How about adding two slashes at the end?  That would produce a lot fewer false matches.

/[a-z][a-z0-9+.-]*:\/\//

Apparently, there should be an exception for mailto:

In old mGSD, link [[Email|mutt:email_id]] opens an empty tiddler named "mutt:email_id", but [[Email|mutt://email_id]] opens my script - exactly what I want.

[Stephan Hradek]

Am Montag, 28. Oktober 2013 05:18:31 UTC+1 schrieb Arkady Grudzinsky:

How about adding two slashes at the end?  That would produce a lot fewer false matches.

Because that's not following the RFC: http://tools.ietf.org/html/rfc3986#section-3

[PMario]

On Monday, October 28, 2013 5:18:31 AM UTC+1, Arkady Grudzinsky wrote:

Apparently, there should be an exception for mailto:

In old mGSD, link [[Email|mutt:email_id]] opens an empty tiddler named "mutt:email_id", but [[Email|mutt://email_id]] opens my script - exactly what I want.

That's why I'd be in favor of a configuration option. So every user can define the rendering behaviour. ... After a while we may see if there are some common settings, that cause problmes if you transfer tiddlers from one TW to an other.

There are very view external link issues popping up here in the group for TWc. So imo the existing regexp worked quite well for a long time.

As Jeremy pointed out, with TWc there where a lot of "false negative" issues, with a less specific regexp. We shouldn't ignore his experience.

So +1 for a user configuration option. May be there are folks out there, that prefer "teamspeak://" over "skype://" ;)

May be there could be an option like this:

a) simple mode: use the existing mechanism
b) RFC 3986 mode: use a regexp described at: http://tools.ietf.org/html/rfc3986#page-50

I didn't check if regexp b) is possible with Javascript.

have fun!
mario

[1] http://en.wikipedia.org/wiki/URI_scheme

[PMario]

@Jeremy
what do you think?
-m

[Stephan Hradek]

 

I didn't check if regexp b) is possible with Javascript.

It's a fairly easy regexp and yes: It is possible with JavaScript.

[Arkady Grudzinsky]

IMO, false positives are not as bad as false negatives.  False positives can always be escaped with ~.  There are plenty of false positives with CamelCase syntax.  At work, I frequently use internal product names in tiddlers, such as "SM3G".  They are recognized as tiddler names, but that's fine.  It has never bothered me as much as the inability to create my own protocol.  This is just my subjective user experience.

On Mon, Oct 28, 2013 at 5:04 AM, Stephan Hradek <stephan...@gmail.com> wrote:

 

I didn't check if regexp b) is possible with Javascript.

It's a fairly easy regexp and yes: It is possible with JavaScript.

--
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/3r9z2mq8N2Y/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/groups/opt_out.

--
Arkady

[Arkady Grudzinsky]

Another thought is to create a token in the link syntax to force Tiddlywiki use external link rather than internal link - e.g. [[Link text||mutt://message_id]] or [[Link text|~mutt://message_id]].  This can be useful in addition to the improved external link regexp.

--
Arkady

[Arkady Grudzinsky]

Continuing my thought, a token to force internal links might be useful too.

How about this:

[[Link text|URL]] - use regexp to detect external links (current behavior)

[[Link text|'TiddlerName']] - indicates that 'TiddlerName' is a tiddler name.

[[Link text|`URL`]] - indicates an external link.

--
Arkady

[Jeremy Ruston]

There are a few issues here. The simplest one is that we need a regexp that can detect URLs within wikitext. I believe that we should evolve a regexp that minimises false positives; negatives can always be fixed by writing an explicit <a> element.

I do think it makes sense to allow users to extend the built-in list of protocols. The easiest way to accomplish that would be to dynamically build the regexp by concatenating the known protocols from $tw.config.

Another underlying issue is the way that TW Classic implemented pretty links ambiguously; they can be used for external links or tiddler links. There are heuristics within the core to choose the correct option at the time the link is clicked, based on the characters within the link text, and by checking for a reference to an existing tiddler. Thus, one can write either of these:

[[a link|http://google.com]]

[[a link|HelloThere]]

But it isn't possible to link to google with [[http://google.com]].

I've been making some changes to link handling in the "widgetsredux2" branch:

https://github.com/Jermolene/TiddlyWiki5/pull/178

The changes so far are:

* Explicit external links are parsed directly as <a> elements (instead of as <$link> widgets that are resolved at click time)

* Pretty links can only be used for tiddler links, and not for external links

My  plan now is to introduce a pretty syntax for external links as discussed on an earlier hangout. I think we discussed something like this:

[file[a link|http://google.com]]

Hopefully we can come up with something a bit more concise.

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/groups/opt_out.

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

[Jeremy Ruston]

I made a small error: the current state of affairs in the branch is that pretty links can be used with external links if the link matches the external link regexp. So you can still say this:

[[google|http://google.com]]

But you can do this to link to a relative URL:

[[page|index.html]]

To be more explicit about the next step, the idea is to introduce an explicit syntax for both tiddler and external pretty links:

[tiddler[HelloThere]]

[file[index.html]]

Then, if the `tiddler` or `file` is omitted the parser will use similar heuristics to TW classic to determine whether to generate an <a> element or a <$link> widget.

Best wishes

Jeremy

[Arkady Grudzinsky]

On Mon, Oct 28, 2013 at 8:44 AM, Jeremy Ruston <jeremy...@gmail.com> wrote:

To be more explicit about the next step, the idea is to introduce an explicit syntax for both tiddler and external pretty links:

[tiddler[HelloThere]]

[file[index.html]]

Then, if the `tiddler` or `file` is omitted the parser will use similar heuristics to TW classic to determine whether to generate an <a> element or a <$link> widget.

Thanks, Jeremy.  The ambiguity between tiddler links and external links is the accurate description of the issue I raised and the solution is exactly what I had in mind.

I love TW for its flexibility.  Even as-is, it's super-easy to tweak the Javascript to add whatever protocol.  I also love the idea that in TW5 all the guts are accessible through the .js tiddlers. 

[PMario]

On Monday, October 28, 2013 4:38:07 PM UTC+1, Jeremy Ruston wrote:

My  plan now is to introduce a pretty syntax for external links as discussed on an earlier hangout. I think we discussed something like this:

[file[a link|http://google.com]]

Hopefully we can come up with something a bit more concise.

hangout #5 link: https://www.youtube.com/watch?feature=player_detailpage&v=SX0jvQ0vYVk#t=1565
-m