-
-
Notifications
You must be signed in to change notification settings - Fork 43
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
Wikilinks #26
Comments
Whenever I have a pile of files (directory of directories of files, possibly a few levels deep), and I want to link to one doc from another, I've always just written my links like |
It's not really necessary, but in heavily-interlinked systems of documents, like notes, it is more convenient to write |
Ah. I see. For wiki's:
so that shortcut syntax is convenient. For my "nested piles of notes", I don't often want to write
Also though, since djot doesn't use double characters for markup (e.g., there's no I see that gitit uses |
I agree that |
Which principles? |
No double delimiters |
I think the worry was not about double delimiters per se, but about ambiguities arising from their interaction with single delimiters. I don't think this case poses a serious problem, especially because we have directional delimiters here |
@jgm , in your example
What purpose does "optional description" serve? That is, if Incidentally, whenever a syntax has two things in a row like that, I always find it difficult to remember what the order is. I think it's more readable to have |
It's the link text. |
Would you consider supporting path and anchor in wiki link. For example
|
Maybe there should be a clear spec about whether we should use either path or path without extension in wiki link. If djot file has a specified extension (such as |
@wrvsrx , the idea is that Anyhow, sorry about the confusion above re double-delimiters vs double matching (left-right) delimiters. I missed that distinction when I wrote my comment. Personally, I've never found the need for a
And another reason I haven't felt the need for them: most of the time I'm wanting to give a more descriptive link, as in But, like I mentioned earlier, I can see it being useful specifically for implementing a wiki. |
Given the many uncertainties surrounding wikilinks, not least of which is what goes before and after the pipe1 perhaps some convention for interpreting a regular link would be better. Assuming there is metadata (#35) one could have
Where by convention a lone That way the whole thing could potentially be handled by the host program and/or a filter. I have a filter for Pandoc which does this (and more). Footnotes
|
@uvtc When I say "a link to By the way, I just think we need a unambiguous standard to represent the link between source file, no matter using the wiki format or the format suggested by @bpj . |
@bpj's suggestion about conventions is a good one (and similar to what I did with gitit, where wikilinks were |
Another advantage of |
It would be good to support wikilinks, in the style of obsidian:
The text was updated successfully, but these errors were encountered: