-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for #note linking syntax #243
Comments
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 Also, one could support |
Hey @srid, thank you for your comment.
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. |
@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? |
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. |
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)? You can start working around it, but I think it is better to keep different syntax for different tools. |
Yes, it's just a parsing thing. |
@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. |
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 As far as I'm aware, this is the only extension that does one thing, and one thing only, (i.e., support |
@lsx7 ,
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 |
OK, thank you for your explanations, that makes some things clearer.
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?
There could be an option, i.e. something like |
@lsx7 , I totally agree on this:
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.
On this part, we won't see things eye-to-eye - and that's fine :) |
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. Now, you could do that by creating automated Zettel of just that o you can leave it to the layer which generates the HTML.
What's the big advantage you see in it? |
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. |
@lsx7, this is the synthetic sugar:
Of course I don't care about the syntax. If this syntax works for you great. This is the context I don't like. |
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. |
I will try to explain, there are 2 way to interpret the unification of the syntax for tags and links:
If I get you right, your idea is (1). 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 |
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 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. |
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 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. |
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. |
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. |
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).
The text was updated successfully, but these errors were encountered: