Org reader handles links poorly

[tarleb]

The org format allows for many different types of external link types. Many of these are not supported by the org reader.

See also #756.

[csantosb]

IMO, links should work from within emacs+org as well as from the gitit web interface. Problem is now you have to decide which standard you follow, right ?

Wouldn't it be easier if we define a gitit tag, that we drop, in addition to file ? This way we may use for example

[[gitit:MyCategory/MyPage][Label]

From the gitit web interface, it would bring to the MyPage, as usual. Now, from emacs+org we would do

(org-add-link-type "gitit" 'my-function)
(defun my-function (regexp)
     (find-file (concat "/Whatever/wikidata/" regexp ".page")))

to open the page, or whatever any code he wishes, this approach might let the user implement custom actions to fit his workflow.

[marcbowes]

#1813 causes file:/ to have the / dropped, making it hard to do relative links.

[tarleb]

The current link parsing code is a rather ugly piece of code. I'm rewriting it completely. Progress is slow as free time is a bit scarce right now.

[marcbowes]

In HTML, / means "relative from the server root". In mediawiki, / means "a subpage of the current path". What are you plans to handle this sort of conflict?

If you're only exporting for a single target (e.g. org to mediawiki) then it doesn't really matter because you can just author the source in a way that works in the target. But if you're exporting to both mediawiki and HTML then one of them is going to be broken.

Personally, I would prefer that the semantics of the source form were preserved. That is, the syntax for all of the relative links that org supports should be translated to the targets' syntax:

• subpage of the current path, e.g. if you are at /foo (HTML) then you need to be able to link to /foo/bar
• sibling of the current path, e.g. /foo -> /bar
• ancestor of the current path, e.g. /foo/bar -> /foo or /baz
• relative from the root, e.g. /foo/bar/baz -> /peanuts/and/bananas

I'm not exactly sure how you're meant to understand "root" in pandoc sites, so I'm happy to work around that with postprocessors if it's difficult..

FWIW, my current strategy is to author in org and use [[rel:/subpage][Just another title]]. Using rel stops pandoc stripping the / if I used file:/. I then do the following at build (for mediawiki targets):

• make a temporary copy of the org file
• gsub rel:/subpage to file:full/site/path/to/subpage
• pandoc to mediawiki
• delete temporary copy of the org file

The output of this is that the link will become [[full/site/path/to/subpage|Just another title]]

[jgm]

@tarleb is this still an issue?

[tarleb]

It's not optimal yet, but link handling has improved considerably since my last comment. I believe the remaining issues mentioned above are solvable via pandoc filters and not a reader problem, so this can be closed.