#21

Can you provide an example of your approach, please? I don’t think I understood you correctly.

#22

Why markdown [[wiki-links]] are future-proof is that I can open my note library in four different software programs on my computer, right now, and each program can read them and use them straight out of the box. No tinkering.

Compare that to proprietary programs like Evernote. Here’s a typical link:

[Evernote Note](evernote:///view/219912759/s8/6ab76137-f9a6-400f-bf91-5bee5c8772f9/6ab76137-p7b4-400f-bf91-5bee5c8772f9/)

It’s fair to say those links are not readable by anything else right out of the box. It discourages users from leaving. Trying to export and figure out how to automate this part and manually change that part is a situation that most of us would describe as dealing with lock-in.

1 Like
#23

Databases tend not to make human readable links. Switching systems always causes some upheaval and inconvenience. What you are describing is having to open door yourself rather than having to break out because you are locked-in. Evernote is one of the better database systems for retrieving data - there’s no shortage of them that do lock you in.

[[wiki-links]] are searchable but don’t simply work as links, especially if a name change has removed uniqueness. And the notes are as you wrote them, but Obsidian is a proprietary program too (and I have no problem with that). Many FOSS programs have databases that are hard to work with. And having programs able to work with those links now is no indication they are future proof, even now many markdown programs would require those links to be converted.

Before putting information into a database, I believe it is always worth checking how you will retrieve it if something goes wrong or you want a change. That includes databases I set up myself. There’s always inconvenience and a loss of the functionality that made you want to put it in there in the first place.

#24

All I mean is that I have a fallback position where I am essentially working with separate documents and no functioning link system. For some important links, I insert a UID so that I can be certain a search will identify the correct file and position. I prefer to use this rather than a file path, because even relative file paths decay when you least want them to.

For the moment, I use the syntax

The idea is that it won't render and will remain hidden but is easily searched. I don't know if this syntax will always work - Markdown requires some playing around to check because it doesn't have its own comment syntax. Just noticed that it seems to render YAML front matter; I'll have to check; maybe I typed it wrong; maybe it uses a different syntax.
#26

“<!–pist>”

#27

Can you name the softwares you are mentioning?

So far I’ve found that only zettlr can handle the [[wikilinks]] properly.

#28

There will certainly be ways to export to more standard links (in the format of [Link name](../link to file.md)) so that other editors can understand it too.

3 Likes
#29

The Archive on Mac (what I used before Obsidian), Zettlr, and nvUltra. Drafts too from what I hear… If I’m speculating I think the numbers will grow quickly in the next year.

#30

Oh I see. I think you are trying to convey that linking md files should be done in a standard way as we link other files (for examples the way we do PNG in Obsidian).

Am I correct ?

#31

I prefer the way it’s done at the moment.
I’m not even convinced about the gain from exporting in different formats. Most programs have importers that will autoconvert and this is quite a common format.
Which isn’t a hard thing for many people to script.

#32

That’s the relatively standard way, as it will be understood by apps like Typora. These links work in Obsidian right now as well.

I’m not conveying this is what we want users to do, as it’s not semantic and doesn’t look as nice as [[note name]]. I mean that there are an increasing number of apps that support [[wiki links]], but if you still don’t feel safe using it, the Markdown long-form link is the safest it can get.

Hopefully that’s more clear!

1 Like
#33

Yes.

Even I would prefer a smaller link like [[NoteName]].
As @nickmilo have mentioned that other apps can also read this syntax of note linking, I am a bit relaxed knowing that my notes will not turn garbage if in case I decide to swtich to other apps. :slight_smile:

Thanks to all of you for the clarification

2 Likes
#34

(Sorry for the huge message)
My main takeaways from this topic:

  • Markdown is great for being just text™, which makes it ultra portable
  • But conflicting implementations and features can become a problem for the long-term
  • But then again, having no headaches in migrating off of systems used for a long while seems like an unachievable dream

This does resonate with me even though I haven’t had a huge headache with this yet, but coming from the media-intensive world of web design, Markdown feels very limiting. Basic formatting, links, headings and lists can only get you so far. This is why people built MDX and similar tools to insert complex blocks in the middle of the text, which suffer from being coupled to the presentation layer (web + javascript + react), which makes it hard to take them to other places. It’s the tricky trade-off Silver raised:

Text-only data also has its shortcomings. Complex queries such as “how many check-boxes are out-there in my second brain and what percentage of those are ticked” are nearly impossible, for example.

Right now I’m very keen on exploring structured data in a future-proof way, such as that provided by PortableText. It has a lot of shortcomings, such as depending on system-defined _types, but I believe it’s a great structure when you’re talking about building your own workflows. For example, I’ve built my digital garden on sanity.io (that uses PortableText under its hood), and there I can write specific annotations with short thoughts I distill in the middle of my notes. Then, I query them all by project, displaying them without the rest of the notes.

I’m enamored by Obsidian due to future-proofing and local-first concerns, but Markdown is the thing blocking me from going all-in in it. The thought of building with short-codes to provide more expressive notes gives me a bad feeling, and staying with only the basics limits my own process… From a tool’s standpoint, I believe MD was the best choice for Obsidian, but I’d love your personal thoughts on this issue regarding your workflow!

1 Like
#36

I would be very interested to know how it is easy to escape Evernote.

#37

@Ward You can use Joplin or Yarle to convert Evernote to Markdown. Not too difficult, and works for me.

#38

A similar conversation came up a while ago on the Dynalist Forum. Since it’s pertinent, I’ll quote part of what I said there: https://talk.dynalist.io/t/visual-editing-wysiwyg/34/94

My main reason for loving Markdown is that it is an excellent way to organize and format text documents. As a software developer, I do a lot of work in GitHub, Visual Studio Online, and other collaboration platforms. The teams I work with use Markdown as our common text format for documentation, instructions, reference, and even online discourse such as this forum. Because it’s plain text, it’s easy for both humans and computers to work with. It can be read by humans without special software, imported and transformed by computers, and easily version-controlled.

I also use Markdown in my personal note-taking, because it allows me to focus on the content of the text (e.g. headings, tables, and emphasis) without getting distracted by the appearance of the text (font family, size, margins, etc.). In graphical text editors such as Word, I sometimes get distracted by trying to make a document look perfect instead of finishing the content. Using Markdown helps me to focus instead on what needs to be communicated and leave the formatting to the many excellent tools available.

I don’t just write in Markdown, I think in it.

7 Likes
#39

So, is Obsidian really future proofed? If the likes of Github and Stack Exchange are using Commonmark, then how is Obsidian universally compatible? I don’t get it.

#40

@oxysmart Obsidian also supports Commonmark.

1 Like
#41

It’s still a plain text file, that any editor will be able to open.
For a nice format you only need a program to render the MD to HTML based on a theme.

3 Likes