Support for #note linking syntax

[lsx7]

Use case:
Every note is also a tag and linking to other notes can be done interchangeably with #note and [[note]] syntax (similar to how it works in Roam Research).

Could this be supported in Memo?
From the extension perspective, both types of links are exactly the same (later, maybe they can be displayed in a different style, but that's just cosmetics).

[srid]

Hey! I have been thinking about this exact idea. Tagging is indeed semantically equivalent to linking, but do note that the direction of linking is different. When you open bar.md and tag with #foo, it is equivalent to linking foo.md to bar.md (semantics of directionality would make more sense from folgezettel linking standpoint, which isn't supported in vscode-memo). See srid/neuron#379

Also, one could support #[[note]], so that white space is supported in tags (i.e., #[[Hello World]]). This is just a specialization of the labelled directional links proposal at srid/neuron#514

[lsx7]

Hey @srid, thank you for your comment.
IMO, the important benefit of treating them as truly equivalent (including the direction) is simplicity - the whole thing becomes easier to reason about.

Also, one could support #[[note]], so that white space is supported in tags (i.e., #[[Hello World]]). This is just a specialization of the labelled directional links proposal at srid/neuron#514

Yes, that's something that could also be supported later. Although, avoiding spaces in names of the pages which could be used as tags is probably a good idea anyway.

[RoyiAvital]

@lsx7 , Are you basically asking for parsing and semantics on how to link or there a different motivation behind it?

As I see it, Zettels are information containers while tags are context agents. Why consolidate it?
Or is it, like I understand it, just for the sake of having another way to parse links?

[lsx7]

Or is it, like I understand it, just for the sake of having another way to parse links?

Yes, that's basically it. You can decide whether you want to link notes together with [[wikilinks]] or #tags, but the extension wouldn't really care.
You can check Roam Research for example of that in practice.

[RoyiAvital]

OK. So it is just parsing thing.

Aren't you worried that you'd lose the ability to discern when you mean a link (Explicit context) and tagging (Implicit context)?
Also, what happens if one day you create a file with the name of the tag you used widely?

You can start working around it, but I think it is better to keep different syntax for different tools.

[lsx7]

Yes, it's just a parsing thing.
And no, none of this is a problem because there is only one context.

[lsx7]

@RoyiAvital and @srid, since you use and prefer folgezettel, which is very far in complexity from Memo (or even Roam's core model), why do you use this extension (which doesn't even support tags)? I'm not trying to start a holly war, I'm genuinely interested.

[srid]

A folgezettel is just a special kind of link. This extension already (implicitly) supports neuron's folgezettel links, and it will have no problem parsing the upcoming #[[Foo bar]] tag-style links either. There is no complexity here; don't like folgezettel? Just don't use it.

As far as I'm aware, this is the only extension that does one thing, and one thing only, (i.e., support [[..]] style links in vscode) ... and does it well, without becoming bloated in features (hello Foam). I do find this extension to be a bit slow the larger the zettelkasten is ... but that can be addressed via srid/neuron#213 (which might necessitate writing an entirely new extension for vscode that talks with neuron LSP server).

[RoyiAvital]

@lsx7 ,
I use it as a front end to write my notes when I do it on VS Code.
I now use 3 tools for the notes:

1. VSCode Memo - On VS Code.
2. Obsidian - For their Sliding Window Mode (See Andy Matuschak's Notes).
3. Neuron - Generate web site.

Neuron isn't robust and future proof solution as the only way I can use it (I'm on Windows) is using GitHub actions which makes things harder. But for now it supplies a nice web site generator. I hope to see Windows compatibility in its future. Then it could be an engine under VS Code (But Windows support is a must for this to really happen).

I don't like the mixing between Tags and Zettels Linking. I think mixing between them makes no sense even at the syntax level. But Syntax is a choice of the user to use or not. Neuron idea about Tag = Zettel doesn't make sense at all in my opinion. Since this is the analysis of the graph level it means it will have affects which the user might not like.

Anyhow, since linking by [[]] and tagging by #<> is basically a syntax and a pattern for the parser, the obvious choice would be setting many options for syntax and the user will select. With [[...]] being the default.

[lsx7]

OK, thank you for your explanations, that makes some things clearer.

I don't like the mixing between Tags and Zettels Linking. I think mixing between them makes no sense even at the syntax level.

OK, we obviously disagree here. Popularity of Roam Research also shows that there are lot of people who prefer using using just one context for linking&tagging, but in the end, I guess that will always be a personal preference.

What still makes me confused is - since you're using tags as a separate context, doesn't using this extension make the whole experience cumbersome? I mean, you don't have things like autocomplete and find-all-references, which are IMO the most important features that editor can provide when working with notes. Wouldn't using something like https://github.com/kortina/vscode-markdown-notes make more sense?

Anyhow, since linking by [[]] and tagging by #<> is basically a syntax and a pattern for the parser, the obvious choice would be setting many options for syntax and the user will select. With [[...]] being the default.

There could be an option, i.e. something like roam_style_links or tag_links, which when enabled, would just enable existing [[links]] functionality also for #links (I guess that should be very easy to implement).

[RoyiAvital]

@lsx7 , I totally agree on this:

There could be an option, i.e. something like roam_style_links or tag_links, which when enabled, would just enable existing [[links]] functionality also for #links (I guess that should be very easy to implement).

Once you give the user both choices it is great for all.

As I wrote, what you ask is a syntax sugar :-).
I think creating automated Zettel per tag, is bad. As this basically changes the (Removes it?) boundary between the information containers to the context containers.

[lsx7]

@lsx7 , I totally agree on this:

There could be an option, i.e. something like roam_style_links or tag_links, which when enabled, would just enable existing [[links]] functionality also for #links (I guess that should be very easy to implement).

Once you give the user both choices it is great for all.

As I wrote, what you ask is a syntax sugar :-).

Yes, exactly. Sorry if my initial post was not clear enough.

I think creating automated Zettel per tag, is bad. As this basically changes the (Removes it?) boundary between the information containers to the context containers.

On this part, we won't see things eye-to-eye - and that's fine :)

[RoyiAvital]

Let's say that in the format of consuming your notes (HTML or whatever you use), what would you expect to see when clicking on a tag?

I'd expect to see a list of Zettles which are tagged by the tag.
More advanced option would be analysis of connection to infer similar tags and display them as well.

Now, you could do that by creating automated Zettel of just that o you can leave it to the layer which generates the HTML.
I prefer leave it to the layer which creates the HTML for 2 main reasons:

1. No other program should have any writing privileges to Zettles.
2. Prevent conflict with a user created Zettel with the same name.

What's the big advantage you see in it?

[lsx7]

It's not that this approach has some big advantage, it's just that I'm not convinced that creating&maintaining those two things as separate contexts is really beneficial for my notes.

We've gone way offtopic, but just to address your last example: HTML export tool also doesn't need to differentiate between them - both [[note]] and #note can just result in a link to /note page, which also contains list of backlinks/tags. You can use a different styling for them (or not, it's a personal preference).

Just to make this clear: I'm not claiming that this way is superior, there's no one size fits them all. Best way to organize your notes is the one that works best for you - and that will always be highly subjective.

[RoyiAvital]

@lsx7, this is the synthetic sugar:

We've gone way offtopic, but just to address your last example: HTML export tool also doesn't need to differentiate between them - both [[note]] and #note can just result in a link to /note page, which also contains list of backlinks/tags. You can use a different styling for them (or not, it's a personal preference).

Of course I don't care about the syntax. If this syntax works for you great.
I am talking why generate automated pages for tags in the Zettel level?

This is the context I don't like.
Linking syntax? I'd go even farther, let the user define any syntax for links :-).

[lsx7]

Well, yes, it's a syntax sugar and you don't need to generate anything you wouldn't generate for wikilinks.

I'm not sure what exactly you mean by automated generating. All I need is a feature which already works for [[note]] links - ctrl+click to #note also would "automatically" create note.md if it doesn't already exists.

[RoyiAvital]

I will try to explain, there are 2 way to interpret the unification of the syntax for tags and links:

1. Syntax Sugar - Make it easy for user. Have a single syntax for both. If there is a Zettel with the same ID as the string, parse it as a link. If there is no file, parse it as a tag.
2. Graph Changing - There are no such things called tags. If you happen to link to a non existing Zettel, the engine will automatically create it.

If I get you right, your idea is (1).
@srid idea, which I don't like, is (2).

I think it could be nice the HTML generator will create a page per tag which shows analysis of that tag. But I don't want it to create a file. Moreover, I'd rather the engines to have no way to create or edit .md files.

[lsx7]

I've re-read your comment and I'm not sure I understand what this part "If there is a Zettel with the same ID as the string, parse it as a link. If there is no file, parse it as a tag." means in vscode-memo extension, which doesn't support tags?

Without that part (or if it doesn't have any meaning in this extension), yes, my idea is (1) - as simple as possible.

Regarding the @srid's idea of automatic generation of linked notes in the background - I wouldn't mind that as an another option.

I think it could be nice the HTML generator will create a page per tag which shows analysis of that tag. But I don't want it to create a file. Moreover, I'd rather the engines to have no way to create or edit .md files.

I think this is a symptom of deeper issue - generating anything more dynamic (like tag analysis) will be very limited if you have just a static html generation at compile time. If you want anything that isn't trivial, you need some kind of webapp, which can create anything dynamically at runtime.

[svsool]

Hi all and thanks for starting an interesting discussion!

I briefly mentioned my opinion on this topic here #60 (it was also linked above). In general, my stance on this matter did not change much since that.

Hash links #note isn't exactly the same as wikilinks [[note]] format. Hash syntax isn't whitespace and extensions friendly and less powerful than wikilinks, so syntax sugar isn't precisely a syntax sugar in this particular case. With hash links you won't be able to link filenames with whitespaces and extensions other than .md which Memo is currently able to link. In my opinion, the hash syntax is a step back compared to wikilinks given knowledge base context.

I have a little motivation to introduce hash syntax due to its limited and subjective value for the knowledge base until we figure out the unique use case and explain it clearly to the other users of this extension.

Maybe I'll change my mind about hash syntax, but so far, it does not look convincing enough.

[lsx7]

Thank you for your comment @svsool.

Just want to point out here again that this wouldn't change any of the existing functionality, just complement and reuse it in a very simple way. I've already commented on whitespaces and other mentioned issues in other comments.

Anyway, I'm fine with forking this or some similar repo and implementing this myself, I just wanted to see if there's an interest to have this support in the main repo.

[svsool]

Regarding tags support, AFAIK vscode-markdown-notes supports wikilinks and tags OOTB (perhaps you forked it already).

About your idea to fork one of the repos, it would be cool if a dedicated extension would exist for providing proper tags support in vscode so that any user could choose between wikilinks & tags or combine both.