No.
Currently absolute-uri only refers to wikidot-domain …

Currently absolute-uri only refers to wikidot-domain …

Ah, my error! Fixed it, thanks.

relative-uri still shows wrong sequence [ anchor ] [ page-args ]

Fixed it, thanks.

Shouldn't [[[wikidot:blog/design:14]]] mean page blog in category wikidot on current site with /design:14 appended to args or do we strict-count slashes and count on this heavily?

Also I don't see the explanation of why this is an interlink in the design, instead it says :blog:design:14 is the proper link.

Using idea from hartnell, interwiki syntax could be sitename::[page_fullname]. But if current proposal for interwiki links is :site:page_fullname it seems equally good.

Also there is a problem with using square brackets in normal text like this [see below], or click [edit] (to mimic button appearance). With this link design, they will become links.

Sorry, the comment was out of date: I'd already updated the syntax to work unambiguously:

[[[:blog/design:14]]]

For using square brackets in normal text… good point. However, note that the new syntax insists on a fullname, with category:pagename. So it would be [_default:start] and not [start]. I need to add support for a page shortname for internal links only. It's not needed for href links.

Nope.

Design says:

href-link = "[" [ "*" ] link-target [ "|" ] [ link-text ] "]"

link-target can be page-fullname

and

page-fullname = [ category ":" ] page-name

which means:

"[edit]" is a valid link in current grammar.

You're right! My eyes were deceiving me. Amazing how the mind works sometimes.

OK, what do you think about the solution I proposed; that a full link needs a full page name, so [_default:start] is a link but [start] is not, and [[[start]]] is a link…?

And, obviously, [http://mywiki.wikidot.com/start] is a link, then.

It seems not to break too much, but still, all of this increases number of ways you can make a simple link. This scares me a bit.

And if we actually have now different syntax inside of two link types (so it doesn't make them consistent) I would suggest again, to improve only one of syntaxes, allowing both kind of links in it and then deprecate the worse one. I would like to discuss this, but if you can for a minute forget how much you have the "[[[" links :-P (if this would make you hate them less, I would suggest typing "[[[" should automatically insert "]]]" after your cursor).

I don't mind a lot of functionality if it gives us consistency, which this does, except for the shorthand for pages in the default category. It's a consistent design with one optimization for very common cases. Easy to understand, easy to learn and use. Fine.

The reason for keeping both types of link is that one does backlinks and the other does linkbacks, orthogonally to the link itself. If we treat backlinks and linkbacks seriously, we need to be able to switch between link styles without changing the insides.

So this design separates different aspects that are co-mingled in an unpleasant way today.

Automatically adding ]]] is a smart idea, I suggest you create an issue for that. Also a shortcut like Ctrl-L to insert a link.

In my opinion sending Pingbacks and making Backlinks should only depend on what you link to and not on the link format you use, (so each time you make a link to some Wikidot page, that page should get a backlink (or if different wiki, this can be a pingback if we eventually capture them). And each time you make a http:// link, that external page gets a pingback.)

That makes sense. In which case we can simplify the whole thing right down to:

- [[[ ]]] is for internal simple wiki style links
- [ ] is for all other links

and the changes here apply only to the full link format. Then the only reason for allowing the wiki style link is to do classic wiki-style mangling to turn words into page names.

Yes, this makes sense.

But, in fact, "classic wiki-style mangling" is the most common way to insert links. And this is why people use this link syntax more, and make mistakes like this:

[[[http://www.somecoolsite.com/some-page | Visit my new cool site]]]

People only use the "[url text]" format when they discover, the "[[[url | text]]]" does not work with URLs. And then once they are gurus and create Wikidot-based applications, to do stuff like "[/%%fullname%%/edit edit]".

So this change would help 5% users, and still leave 50% of them with the old link problems.

People only use the "[url text]" format when they discover, the "text" does not work with URLs.

Exactly. This is why I don't like two separate link formats. OK, we have them historically but they just create pain. So the fully general design (plus single optimization) works for everyone.

OK so let's start from the beginning.

What's the problem? The problem is people use the syntax they are used to ([[[this | syntax]]]) to create URL links, which does not work.

Possible solutions:

1. change the recommended (or the only one documented) link format to [this one]) OR
2. enable [[[this | syntax]]] to link to external URLs, anchors and page with parameters

What's wrong with #1? To create a simple link to page, you need to:

• explicitly name the category: [_default:abc] (which is strange, because most users don't even know there are categories!) OR
• retype yourself: [abc abc] (much typing) OR
• (not yet implemented) type [abc *] that would get the page title of page "abc" and use it as link title (only works for already-created pages)

And the problem with this is that you need to use "|" for some links, and for other ones you don't.

What's wrong with #2?

• a few characters too much typing?

but, it makes links really visible in the source and unlikely to be there by accident and enables link having "[button like]" descriptions. As I suggested, the "]]]" part may be added automatically, so it's not that much more typing from [this syntax].

I think [ and ] is good as it is.

Extend [[[ and ]]] to allow external links — problem solved, right?

To have ]]] to appear automatically after typing [[[ would also be a great addition (suggested by Gabrys I think)