#13

The problem is that it’s insufficient. Competing flavours that do the same thing can be resolved but insufficiency always invites extensions.

#14

wrt the polls, I don’t think any of the issues are entirely true. Eg Evernote is easy to escape, Onenote less so. Physical storage formats are often the most intractable issue.

The huge advantage of plaintext, which is what has powered its expansion, is that it is much lighter on resources (space, processing, developer). This makes it desirable for phone apps, the web and search. It’s held back by the lack of common standards that are sufficient for all developers and users.

#15

Commonmark or markdown in general? What benchmark are you using to determine if a flavor of markdown or other markup is sufficient?

#16

Both.
Easiest way is to look at the number of developers creating extensions for their own apps and the number of users expressing a desire to do something that isn’t possible. Nothing to do with benchmarks.

#17

How so? When you have thousands of evernote links, please share your wisdom on how those can be converted to wiki-links? It won’t save me the hours lost trying to salvage those notes, but it may help others.

1 Like
#18

My main reason for using this tech is [[backlinks]]. I don’t know any other software which makes back linking as fluid as what obsidian provides.

Although i agree that markdown files in itself are future proof, I’m afraid that the [[backlinks]] handling will be broken outside obsidian.

I’ve tried fiddling with md files in VScode, and i realise that backlinks pointing to notes in other folders or sub folders are broken.

1 Like
#19

?
You must realise that markdown and document format has nothing to do with the ease, or otherwise, of exporting links.
A link is just a search function using unique identifiers. Virtually all programs using them have them in a database for speed. That’s not easy to export or import. I’d expect similar issues in Obsidian and other programs using markdown. I assume you’ve tested Obsidian to make sure you can easily export your links.

As it is, Evernote does export the links with its HTML export; the problem is that it’s a link within its database (ie cloud) so it is a slow process. But there’s no lock-in.

#20

I’ve not probed at all but that’s what I’d expect. One way of trying to achieve it is possibly is to drop in a unique identifier at every link destination, but that won’t give you backlinks unless you also ensure you have the unique identifier for the starting point. Downside of that is that you lose the gain of using the program.

My own approach is a combination of adding unique headers where I think I might want them (usually x+timestamp), and a fast text editor with grep. I know this will always works and I can test it when I want. But a degree more effort and time, so I do it judiciously.

#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