[ENHANCEMENT] Inline ID links in markdown syntax ([]([[id]])) should be handled normally

[Bestulo]

My build:

Windows 10
Zettlr 1.8.0-beta.1

This one is funny because you already know it and make note of it. It is expected by the user to be able to link to other notes through inline hyperlinks ([]([[id]])). This, in my opinion, should be a feature, as any Zettelkästen user browses their notes as they write new ones.

Since Zettlr makes such an emphasis on Zettelkästen, inline direct linking to other notes through IDs should be part of the deal.

If this causes any problem, it's at the export stage, but the problem is already caused without inline linking, and it can be solved with some export-stage parsing of links for normalization.

[nathanlesage]

An internal link only consists of [[id]], you don't need the Markdown link syntax for that!

[Bestulo]

I know. But I want my text to lead to another document. I want to link inline. That's why hyperlinks were invented. It's very convenient to say something and on the same text, link to it, instead of having to do the ugly thing and put it somewhere else.

I tried using footnotes and I can't click the link of the footnote to go to the footnote, so I have to scroll down to the bottom to click it. Overall it's an uncomfortable mechanic that could be solved by simply allowing inline ID linking.

[Bestulo]

Aha, like Wikipedia links. If you can link it inline, you're much more likely to do it than if you have to throw a link elsewhere. It's also a much more effective system due to the link being right on top of the topic, instead of out of sight where it might be missed, omitted or procrastinated.

[nathanlesage]

Aha, like Wikipedia links.

Exactly.

[Bestulo]

But Wikipedia links can be embedded inline too.

And it makes way more sense sometimes. I think that's one of the things that makes Wikipedia so good for the inter-relations in each article.

If we had to link each and every reference at the bottom, that reference section would be endless and nobody would read it or go to related articles. Inline links haven't always existed, but since they exist now, why not make linking to cards more fully functional?

I'm not saying it has to look like this: [textile manufacture]([[20201104055302]])

but it could also look like this: [textile manufacture](20201104055302)

or even the Wikipedia way [[20201104055302|textile manufacture]]

This could really strengthen Zettlr's Zettelkästen potential. I'm not sure what the problem is (apart from how tedious it must be to code) that makes this not viable here. The technology is clearly there.

[nathanlesage]

I'm not sure what the problem is (apart from how tedious it must be to code) that makes this not viable here. The technology is clearly there.

The problems are manifold. It's not only about the coding issue, it's mainly about several things:

1. This would make Zettlr's syntax even more non-portable, as it is still not (and should, in my opinion, never be) standard Markdown syntax, but only for the specific use-case for Zettelkästen. No other Markdown editor should be expected to understand what the Markdown link [[something]] refers to.
2. These links work very specifically, by also triggering a search, and in no case should these be expected to be exported (exporting by transcluding is a planned feature)
3. Enabling titles like with Wikipedia has also been ruled out, because this will cause a lot of confusion.

The main problem here is that Markdown is a source code, and not a finally compiled file. Doing syntax-magic can only go thus far. We need custom elements (like ZKN links) in order to enable cool stuff like inter-linking with searches, and we cannot do this using default Markdown elements, because this will then lead to confusion, as when users will encounter Markdown somewhere else on the internet, they'll be wondering why their cool syntax they know from Zettlr doesn't work. Or if they send a Markdown document to a friend not using Zettlr, the friend will wonder why the Markdown document looks funny.

[Bestulo]

Since it's already not portable, and portability is being developed to export into normally linked content, here's what I expect things should look like:

• Custom Zettlr file ending supported by default: .zmd or mdz or zem or who knows what.
• Emphasis on an "export to normal Markdown" functionality that parses links, then substitutes them into absolute or relative paths.

This would already happen even before inline links are supported, because ID links are a whole beast on their own, as you say.

It's not due to inline links but already (current edition Zettlr) that people should not be able to think that they can share a Zettlr markdown file and expect it to work somewhere else unless the other person has access to the full directory and a program that can parse these urls. Therefore, since the problem already exists, and since steps have to be taken to counter it already, it seems to me that the load from your points 1 and 2 are reduced to very little extra.

Wikipedia titles are already there with Yaml syntax AFAIK.

I'm not trying to appear or be hostile, btw. I'm just deconstructing this problem to see where the obstacle is. So far, I'm still unable to see it. Perhaps there's a mistake in my reasoning? I see that the problems you mention already exist, and thus adding this feature would cost nothing and break nothing that isn't already broken. Am I missing something?

[nathanlesage]

There's nothing wrong with your arguing, nor is anything hostile, do not worry. As a matter of fact, the underlying problem of all of these discussions that I have already had in the past with other users boil down to the fact that these are decisions which I cannot fully justify, as there is no real right or wrong.

All I can attempt so say is that my aim is to keep Zettlr as compatible as possible without keeping it toothless. This means: Yes, there are incompatibilities to other programs, but I keep their frequency to an amount as small as possible. It's a "gut feeling" situation where the estimations vary depending on the situational context. Whenever there might be an avenue of implementing a functionality using common standards, I choose that one, even if that means more mental work for the users, rather than develop a highly specific solution which then renders all documents unusable with other editors.

This means that things such as custom file extensions are completely out of the question, as are completely novel elements, as are introductions such as the proposed Zettelkasten-link-inside-Markdown-link thingies. This kind of stuff is just too conflating of common standards and custom syntax which I could not implement without sacrificing the last three years of work.