Zettlr: opening links doesn't work

[akstrfn]

Description

Ctrl + Click does not open most of the links on ArchLinux.

Reproducing

Click on any of the following links:

www.google.com (but http://www.google.com works)
[myFile](./file.md)
[myFile](file.md)
[myFile](/full/path/to/the/file.md)
[myPDF](/full/path/to/the/file.pdf)

Expected behaviour

Open the file in default application.

Platform

• OS: ArchLinux
• Zettlr Version 1.4.2
• Electron 7.0

Additional info

It seems that electron just calls xdg-open if it doesn't recognize the link because the console output when clicking on the link in Zettlr is the same as when xdg-open is ran with no parameters i.e.

~ xdg-open 

   xdg-open -- opens a file or URL in the user's preferred
   application

Synopsis

   xdg-open { file | URL }

   xdg-open { --help | --manual | --version }

Use 'man xdg-open' or 'xdg-open --manual' for additional info.

I tested this hypothesis by checking it in the hello world app from electron where I put different urls in require('electron').shell.openExternal(url).

For files this seems to be offending line: https://github.com/Zettlr/Zettlr/blob/8eceae9f963b547c42da1caf9914b52cf7a9b179/source/renderer/zettlr-editor.js#L183
This is because no exception seems to be thrown so whole code block after it is never executed. Before the cited line I've hardcoded few lines with openExternal("file:///location/to/my/file.pdf"`) and it seems to work fine.

[pihentagy]

I also would say, that let's assume I'd like to open a markdown link in Zettlr, even if it is not the default markdown application…

[nathanlesage]

Hey, thanks for the feedback -- I also recognised this problem. However, I'm not completely sure of how to handle this, but I'll be thinking of a solution asap!

[akstrfn]

Maybe check if the name ends with some known file extension and if so use that to form file:// url. It is not nice but it should work.
xdg-open does not give enough info to Electron but electron also messes up the urls, quite unfortunate situation.

[nathanlesage]

Yep, additionally we need to account for at least four different OS architectures, which doesn't make it easier! The current state was the solution to some previous problem circling around this exact problem, but I'm afraid I forgot what exactly the problem was ...

[akstrfn]

I suppose it was this commit 43fc17c723a64cba0619147a1061e52b2c927af3? Probably solving this properly is quite hard and would require some sort of probing of a file but simple file extension heuristic should work reasonably well.

I just tested xdg-open whatever and it opens whatever in my browser :man_shrugging:

[nathanlesage]

Mh, I think what I need is a new helper function. This way, we could have tests for that thing and also handle it a little bit better. After all, I urgently want to put the Editor class on a diet, it's way too big!

[nathanlesage]

I just added a commit that tries to address these issues. Please try the new beta (coming in a few minutes) and report whether or not it works!

[pihentagy]

Unfortunately not working for me :(
Neither formats:

 * [Konfiguráció](configuration.md)
 * [Authentikáció](./authentication.md)

[nathanlesage]

Hah, that's where the new logs come in! Please try to click all the links that don't work and then open the log viewer (debug mode: on, and then in the Develop-Menu). What does it say?

[akstrfn]

I just added a commit that tries to address these issues. Please try the new beta (coming in a few minutes) and report whether or not it works!

Which commit was supposed to fix this issue? Issue is still present, same manifestation of the problem.

[nathanlesage]

This is strange, it works on my machine o.O

Mhh… maybe it's still an issue with shell.openExternal (the electron function Zettlr is calling).

Basically, what Zettlr is doing when it encounters a relative or absolute link, it's trying to tell the operating system to open that link (a.k.a. file://your/path/to/the/file.md). (Why? Because it's much cheaper to implement). I remember that there were some problems in the past.

What operating systems do you guys use?

[akstrfn]

ArchLinux with xdg-open version 1.1.3+. It seems as if electron is passing empty value to xdg-open since the output is the same on terminal as if I typed xdg-open without arguments.

[nathanlesage]

Oh gosh, I suspected that much … do you think you might be able to test if it's really a bug with Electron on Arch?

[akstrfn]

I did investigate before and as mentioned in the first post I think the problem is that no exception is thrown by electron and exception is used as a control flow

[nathanlesage]

Aaaaaaaaaaaaaah, sorry, I totally overlooked that (I'm pretty much ill right now). But yeah, then my alternative idea should work! I'll get to it before the next beta!

[akstrfn]

Take your time and rest :)

[nathanlesage]

Soooo, just hacked together a small heuristics and wrote some tests for it. It should cover most cases:

(Please note the highlighted case, where the heuristic will fail. In this case, you'll need to specify exactly that it's a file, either by providing the file://-protocol or by prepending a ./, see the following test cases).

[nathanlesage]

So, the new algorithm is in version control, so I'll close this issue for now (to keep the issue list clean) — if the error still persists in the next beta version (which will hopefully be released next (not this) Friday), please comment again on this issue to re-open it!

[pihentagy]

I find it a bit confusing how it handles different links.

So, if github.com becomes https://github.com, what is your idea about another.md? Should it resolve to https://another.md? I would like it to be file:///home/foo/documents/another.md and generally I would prefer as internal link __unless__ there is _evidence_, that it is a web address.

…if you would like Zettlr to be a useful drop-in replacement for browsing markdown directories.

[nathanlesage]

Oh I see, I haven't thought about that, you're right!

The reasoning for the algorithm to prefer weblinks is because, a link is most of the time a weblink. Even file-links are, in the end, web-links that will be filtered through respective algorithms, which is why the file://-protocol needs to be appended. Besides, it's extremely easy to tell Zettlr "this is a file, not a weblink" by simply prepending a ./.

Furthermore, another.md is _really_ a possible weblink, because .md is the valid TLD for the republic Moldova: https://en.wikipedia.org/wiki/.md — hence, we cannot presuppose file over link. Zettlr can still act as a drop-in for navigating markdown directories, and I think, weighing adding ./ versus having to add https:// for indicating links rules clearly in favor of leaving it with favor to weblinks, b/c while you can shorten file:// to ./, you cannot shorten https:// in any meaningful semantic way.

[pihentagy]

Then I won't be able to use it for markdown docs. We store docs in git (in gitlab) and docs are full of relative links without ./ and it works in gitlab web UI. I won't rewrite those links, so may I ask you to consider adding an option to choose the type of protocol-less links.

[nathanlesage]

I could offer a preferences switch to change the behaviour. Thanks, however, for the very valid point, I'll take it into serious consideration!

[pihentagy]

I could offer a preferences switch to change the behaviour. Thanks, however, for the very valid point, I'll take it into serious consideration!

Let's simplify it further. Given a link, just prepend file:///. If it is a valid link (can you check it from the electron app?), treat it as a link. If not, then

• treat it as a web link
• user preference for creating a new file there (you are trying to create a new .md file, don't you?) or go to website in external browser ;)

Yes, I know that [[]] syntax is shorter, but the value of a standard syntax is higher…
Maybe if there is a switch for standard Markdown syntax, you can bind to that functionality:

• compatibility mode: standard markdown style links, every link is file
• Zettlr/Wiki style links: all standard Markdown links are treated as web addresses

What mode are you in:

• let's make a preference
• look for [[]], and if you find one, go to compatibility mode (otherwise ask the user)

[nathanlesage]

mhmhmh … this sounds more complicated than other possibilities. In the last days I've been thinking hard of making an exception for links matching the regex /^(.+)\.md/ — this would make .md-domains harder as these would need a protocol, and let's really be honest: The changes of encountering a .md-FILE instead of a link are so incredibly higher in a Markdown editor than vice versa, so it seems reasonable to fall back to a file-link instead of a web-link in that very specific instance …

[pihentagy]

I would be happy with trying protocolless links as file links first. That's not complicated I guess.

[nathanlesage]

It is, actually, because I'd have to make an IPC-call to main to test all these things properly. The main reason for why my heuristics currently are only based upon pure string-comparisions is that I can't query the file system from the renderer, and the IPC calls are still ugly due to some legacy code from two years ago :/

[nathanlesage]

@pihentagy Hey, as you complained that a lot of your documentation code contains links in the format [Some Title](file.md), I just added another weighting to the heuristics. Now the following three rules apply:

1. If there is a non-Markdown file you'd like to link relative (e.g. [Text](file.pdf)), you need to prepend ./ (or something else for the heuristics to identify this as a file). This is just as it was before.
2. If there is a file ending in .md, .markdown or .txt (e.g. [Text](file.md)), it will now be automatically treated as a file instead of a URI, so no need to prepend ./ (or similar) anymore.
3. Both markdown and txt are not valid TLDs, but if you actually need to link to a moldovian page (such as [Government](gov.md)), you now simply need to append a trailing slash to indicate it's not a file (e.g. [Government](gov.md/))

I hope that solves your headaches using Zettlr with Gitlab!