You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the wiki and the Obsidian world, they use a bracket-style syntax for cross references within and between pages. These are roughly the links I'm talking about:
[[ link target ]] (target can be a page or a file
[[ link target | Displayed name ]] (to display custom text)
[[ link target#id ]] (to link to a specific section/header/block/etc on a page. (it might also be [[ link target #^id ]] I'm not quite sure the difference).
![[ link target ]] (the ! represents embedding, similar to how we use markdown image link syntax)
This is very similar to the markdown-based link syntax we already use (structured like [Displayed name](link target#id)), so perhaps we can parse this Wiki-style link into the MyST document model in the same way.
Benefit to users
While the syntax provides redundant functionality with markdown style links, it would make it much easier to interoperate with Obsidian and Wiki-style documents. Given that MyST has a similar kind of use-case, this could be useful either as a two-way street (e.g. using Obsidian to author documents that you then build with MyST) or as a one-way street (e.g., making it easier to convert a Wiki document to a MyST document). These are both very popular and well-used systems so this could be a bridge into a fairly large community without adding too much extra complexity to the MyST document engine.
On the one hand, I'm worried about having multiple ways to do things in MyST. On the other, I think this is a nice change. Having raised a concern, I do think that our current link-handling is scheme-based, which doesn't feel like custom syntax such that really this suggested change leaves us with only 1.5 ways to add links ;)
I wonder how we'd tie-in xrefs - should they still be autolinks with special schemes? Probably ...
As a recent Obsidian convert who thinks we should have closer integration with Obsidian-like workflows in the Jupyter ecosystem, I'd love some of this. I haven't yet thought through the implications enough to advocate about specifics, but I'm here to brainstorm together, as I generally would love to be able to have Jupyter and Obsidian "coexist" more closely...
The fact that Jupyter lets you work off regular files à la Obsidian and shares some of its philosophy makes them in my mind natural companions, so I'm happy helping explore the possibilities... I suspect @colliand might be interested in this discussion too...
In the wiki and the Obsidian world, they use a bracket-style syntax for cross references within and between pages. These are roughly the links I'm talking about:
[[ link target ]]
(target can be a page or a file[[ link target | Displayed name ]]
(to display custom text)[[ link target#id ]]
(to link to a specific section/header/block/etc on a page. (it might also be[[ link target #^id ]]
I'm not quite sure the difference).![[ link target ]]
(the!
represents embedding, similar to how we use markdown image link syntax)Here is documentation on Obsidian link syntax
This is very similar to the markdown-based link syntax we already use (structured like
[Displayed name](link target#id)
), so perhaps we can parse this Wiki-style link into the MyST document model in the same way.Benefit to users
While the syntax provides redundant functionality with markdown style links, it would make it much easier to interoperate with Obsidian and Wiki-style documents. Given that MyST has a similar kind of use-case, this could be useful either as a two-way street (e.g. using Obsidian to author documents that you then build with MyST) or as a one-way street (e.g., making it easier to convert a Wiki document to a MyST document). These are both very popular and well-used systems so this could be a bridge into a fairly large community without adding too much extra complexity to the MyST document engine.
Additional references
The text was updated successfully, but these errors were encountered: