More convenient links

[srid]

More convenient links

[srid]

One idea is to use a single protocol, z:, to refer to all link types (deprecating zcf, zquery, zquerycf):

z://link/2012342 # Equivalent to [2012342](z://...)
z://link/2012342?linkType=nobacklink # Like zcf
z://query?tag=science # Like zquery://search
z://query?tag=science&linkType=nobacklink # Like zcfquery

And then have <2012342> as an easy-to-type alias for z://link/2012342, as it would be most commonly used.

[srid]

I'm close to finalizing the proposal. I think the scheme below will facilitate a as clear as possible implementation with the new query type #117:

* <1234567> -- Alias for <z:zettel/123456>
* <z:zettels?tag=foo>
* <z:tags?filter=foo> -- Yup, this is an *upcoming* query type

Anchor can be used for annotation (ignored by neuron):

* <1234567#foo-bar>

Connection type can be specified using query flag:

* <1234567?cf>
* <z:zettels?cf&tag=foo>

And it goes without saying that regular links (aside from the henceforth legacy links) won't be supported. For example, the following won't be handled:

[.](z:zettels?tag=foo)
[some text](1234567)

We require the URI to match the link text, before processing them.

---

There is one thing pending on this proposal. That is the link theme query params need to be normalized, in light of the new query types.

[srid]

The proposal has been implemented (except for annotations) in the master branch, if anybody would like to give it a try. I'll wait a few days day before making it official (and putting in the documentation).

[Nadrieril]

I see this is a limitation of mmark :/ I would support switching to pandoc, because it would allow so much more stuff like syntax highlighting, math or latex.
That could support a naked z://20200101 link for example, which mmark doesn't support.

[streaps]

z://link/2012342 # Equivalent to 2012342
z://link/2012342?linkType=nobacklink # Like zcf
z://query?tag=science # Like zquery://search
z://query?tag=science&linkType=nobacklink # Like zcfquery

I don't like it very much, too many special characters for simple functionality:
: / ? = &

It's hard to remember. Not everyone is a web developer and is used to the syntax.

And third, the URL doesn't make much sense:
"z" ist not really a scheme
"link" and "query" not really an authority

Why not use just relative URLs that map to the http URL? From a user's perspective I don't see any reason for the z:// and also not for //link.

<2012342>
<2012342!> for nobacklinks
<tag/science> (I couldn't find any clickable search link on the website, no idea how the http URLs look like in the browser)

(... the markdown syntax for links is really stupid. The rest of markdown too ;)

[Nadrieril]

the most intuitive thing is to use relative URLs. On wikipedia you don't put wikipedia://link/Uniform_Resource_Identifier in the brackets.

That's quite nice actually; the wikipedia example is good. Imagine instead of serving a zettel at http://127.0.0.1:8080/2012342.html we served it at http://127.0.0.1:8080/zettel/2012342. Then <2012342> would just be a relative link, and we could have </query?q="tag=science OR tag=math"> for queries. The idea would be that even if neuron decided to stop processing links, they would still point to something that makes sense.

[srid]

Having just [20200101] was what I was originally trying to do. Yea, it is a limitation of mmark, but maybe we can extend mmark or mmark-ext to support it.

Syntax highlighting is already supported by mmark/neuron. See example. You need to include the language name as the first thing in the code fence (see source for that example).

Math support was added in this PR. And I'm not sure how you plan to use latex in a Zettelkasten.

I feel ambivalent about switching to Pandoc; it will require some thought. MMark is just simpler to deal with. But if it proves to be too restrictive, and Pandoc is not too complex to use, then it may be worth considering.

[Nadrieril]

Oh, I had no idea neuron supported highlighting and maths, that's quite cool ! FWIW I've used Pandoc to parse markdown before and found it relatively straightforward.
I just discovered the <https://example.com> markdown syntax, which seems to be equivalent to [https://example.com](https://example.com). mmark supports it. Maybe we could convert <20200101> and <z://20200101> to zettel links ?

[srid]

Interesting, I didn't know about the angle brackets.

Maybe we could convert <20200101> and <z://20200101> to zettel links ?

Yea, I'd be open to that. The exact format will have to be decided first. The ID in "z://20200101" is currently ignored by Neuron, which requires the ID to be in link text. So it is more straightforward to support <20200101>.

But in general I wonder if neuron should support z://<id> style links as well.

[Nadrieril]

Yeah, looks nice! The main issue I have is the extra keystrokes required. Can we bikeshed shorter links? E.g.

z://2012342 # Equivalent to [2012342](z://...)
z://2012342?nobacklink # Like zcf
z://?tag=science # Like zquery://search
z://?tag=science&nobacklink # Like zcfquery

In fact we don't need z:// anymore, do we ?

<2012342> # Equivalent to [2012342](z://...)
<2012342?nobacklink> # Like zcf
<?tag=science> # Like zquery://search
<?tag=science&nobacklink> # Like zcfquery

Unless you plan other things than links and queries

[srid]

By the way, syntax highlighting is now documented here: https://neuron.srid.ca/2013702.html

And mathjax here: https://neuron.srid.ca/2013701.html

[srid]

@streaps It is an URI ("a string of characters that unambiguously identifies a particular resource"), not an URL, which is just a form of URI. URIs won't be going away from neuron; I think they are vital in defining simple and clear links to resources (zettels). Aliases to them would be introduced so that users won't have to type in the full URI.

---

Here's what I've tentatively come up with, using some ideas from above:

URI spec:

z://link/2012342 # Equivalent to [2012342](z://...)
z://link/2012342?conn=bare # Like zcf
z://linkmany?q="tag=science" # Like zquery://search?tag=science
z://linkmany?q="tag=science"&conn=bare # Like zcfquery

Aliases:

<2012342> # == z://link/2012342 
<2012342?bare> # == z://link/2012342?conn=bare

Nothing is finalized, yet.

---

Note that:

• z://link basically says "link to this zettel"
• z://linkmany says query the zettelkasten and link to the results
• Query q= is a string, because it will support operators like OR as well as custom fields in the future.
• I'm not convinced if an alias for z://linkmany (which doesn't seem used very often) would be worth it; besides I can't find a good alias that will allow arbitrary query strings.

[srid]

URIs won't be going away from neuron

Although URN might be more suitable.

<z:2012342>
<z:many?=q="tag=science OR tag=math">

[streaps]

I don't think that any of the examples is correct (but I could be wrong)

z://link/2012342 is in the form of an absolute URL (which is also an URI), but link is not an authority (domain, network location).

<z:2012342> is not an URN, because it's missing the urn: scheme. It looks like an URL to me, where z is the scheme and 2012342 is the path. I would expect that my browser would open an app that understands the z protocol and connects to resource 2012342 or something like that.

<z:many?q="tag=science OR tag=math">
I don't know what this is, but it's not an URN and it's not "globally unique and persistent"

In the context of markdown pages, which are rendered to html and served by a web server, the most intuitive thing is to use relative URLs. On wikipedia you don't put wikipedia://link/Uniform_Resource_Identifier in the brackets.

[srid]

I had a chance to look more into this. Some thoughts:

• URN is impractical, unless we add support for it in mmark (which supports only URIs), which is a shame because it is more a conceptual fit (identifying something vs locating it)
• The URI schemes discussed in the proposals above are still generally valid, but because mmark's URI parser is strict it will become a pain to have to quote characters like double-quotes (which are used in q="...") when writing in Markdown.
• It also becomes clear, upon further reflection, that alias syntax is more compelling.

That said, URIs would be used internally, and the alias syntax must have a 1-to-1 mapping with URI representation.

So the revised proposal would be:

# Aliases
* <1234567> -- A zettel connection
* <1234567?cf> -- A zettel connection that doesn't affect graph
* <?tag=foo> -- A zquery (Note that using double quotes will require escaping)

This would map to the following URIs (which are also allowed in Markdown, but would rarely be needed):

# URIs (mapped from their corresponding URN)
* <z://link/1234567>
* <z://link/1234567?conn=cf>
* <z://linkMany?tag=foo>

The URI for a general search would look like z://linkMany?q="...", however it will require escaping of unallowed characters be they in their URI form or their alias form (mmark would treat the alias as an URI too). I'm not sure how to solve this particular problem.

[Nadrieril]

I've started implementing at least <1234567> since we seem to agree on that

[Nadrieril]

Looks good! I have one objection about using anchors for annotations however: they make sense when the link zettel has markdown headers. For example: https://neuron.zettel.page/2011501.html#test-your-install points to a particular section of the zettel.
So we could want to allow linking to sections in zettels that way. Otherwise we might decide that this goes against the "one note = one idea" precept, which would be fine by me

[michelk]

Is there editor integration for following links in the markdown?

With [Text](1234567.md) and gf in vim, that would do the trick.

So in addition to <1234567> also <1234567.md> would be nice.

[srid]

@michelk Not a bad idea. I suppose we could support that as well (though not document it predominantly, but only as a footnote).

Is there editor integration for following links in the markdown?

I use @felko's https://github.com/felko/zettel-mode with Doom Emacs (that uses VIM keybindings in Emacs). It has a function to follow zettel links, but it does more (insert zettel links, create new zettel, insert tags, open rib generated page, etc.)

[michelk]

Moved to #148

We should keep in mind that the current zettel-id-scheme is not ideal for community zettelkästen, since multiple users can generate the same zettel-id on the same day, which results in annoying merge conflicts.

Some sort of random hash would be more appropriate for that.

[srid]

... and documented.

[felko]

Migration script to switch to new style links: https://gist.github.com/felko/e8bac68ece2f8a3f52e954fe5be78952. Usage: python3.8 migrate.py zk-dir (do a backup unless you use git)

[srid]

If anyone is wondering what the new links look like, on Emacs (with neuron-mode, which overlays the title automatically):

Image from https://neuron.zettel.page/2011406.html

[michelk]

Has anyone already setup a configuration for vim to search and insert zettel-IDs?

[vcavallo]

@michelk In case you hadn't seen it yet: https://github.com/ihsanturk/neuron.vim