Use filename instead of the title when auto-completing wiki-links

[MilanVasko]

Hello, thank you for creating this project, it looks really useful!

My usecase is that I have a Zettelkasten repository containing a lot of interlinked notes with generated filenames. For example, my typical note might have a filename 202208240944.md and a content like this:

# Some title here

Lorem ipsum

If I try to link to this note from another file, I can type [[some and I will correctly get a list of suggestions with this note on the top. However, if I decide to use that suggestion, the result will become [[some-title-here]] instead of [[202208240944]]. In other words, marksman seems to assume that the title directly translates to the filename - but I think that is often not the case.

I've tried to use it with Kakoune (using kak-lsp) and Helix and both editors show the same behavior.

[artempyanykh]

Hi @MilanVasko! This is the expected behavior — my assumption was that when doing Zettelkasten style note taking, each note’s title should be unique to the note (otherwise, how would you tell them apart?). Therefore it’s fine to use the title’s slug rather than the file name in the link because it’s easier to tell what the link refers to when you have [[some-title-here]] vs [[202208240944]].

I think it should be possible to make this behavior configurable, e.g. in .marksman.toml we could have a section

[wiki]
style = title | filename

But I’d like to first learn more about your case.

marksman seems to assume that the title directly translates to the filename - but I think that is often not the case

Could you give an example where the assumption about the title is not true?

[MilanVasko]

Hi, I will try to answer part by part.

This is the expected behavior — my assumption was that when doing Zettelkasten style note taking, each note’s title should be unique to the note (otherwise, how would you tell them apart?).

That's generally true, though not always. As an example - in my notes, I have two notes with the title Projects. So what's the difference? One is for personal projects, and one for work. I differentiate between them by context - the links leading up to that note are different.

Granted, I might not be using the purest form of Zettelkasten, so I admit notes like that may be unusual :slightly_smiling_face:

Therefore it’s fine to use the title’s slug rather than the file name in the link because it’s easier to tell what the link refers to when you have [[some-title-here]] vs [[202208240944]].

That's true, for this kind of workflow you need to have tool support. I currently use Emanote and before that, I used neuron. Both of these tools parse the markdown files and generate a webpage with all the links rendered. Coming back to my previous example, this text in markdown:

Please refer to [[202208240944]] for more info.

Would get rendered like this in the webpage:

Please refer to Some title here for more info.

"Some title here" will, of course, be a link.

I think it should be possible to make this behavior configurable, e.g. in .marksman.toml we could have a section

[wiki]
style = title | filename

That would be great :slightly_smiling_face:

Could you give an example where the assumption about the title is not true?

I hope I've answered this question in the previous paragraphs :slightly_smiling_face:

[MilanVasko]

One more thing for clarification. I got this idea of a unique random note identifier from neuron. The idea is that the filename is immutable, eliminating the need to rename all the references if you decide to change the title of a note.

Some more info about this is on the neuron webpage:

• https://neuron.zettel.page/id

[artempyanykh]

Thanks for the explanation @MilanVasko!

Not trying to challenge your workflow, rather further clarify:

I have two notes with the title Projects. So what's the difference? One is for personal projects, and one for work.

Why not rename one to Personal projects and the other to Work projects?

I got this idea of a unique random note identifier from neuron. The idea is that the filename is immutable, eliminating the need to rename all the references if you decide to change the title of a note.

I sympathise with this idea. But it feels like a workaround for not having the tooling support to do renaming. Marksman has a rename refactor that can rename e.g. a heading and all its references across the whole workspace; so renaming is not really a problem.

I currently use Emanote and before that, I used neuron.

I think this is a valid angle on the problem. If e.g. a tool such a emanote or neuron (which further support zettelkasten) require wiki links to use filenames rather than slugs; it'd be nice for Marksman to be able to play nicely with them.

[MilanVasko]

Why not rename one to Personal projects and the other to Work projects?

I might as well do that, my notes are always work in progress :slightly_smiling_face: The point I was trying to make, however, is that clashes may happen.

I sympathise with this idea. But it feels like a workaround for not having the tooling support to do renaming. Marksman has a rename refactor that can rename e.g. a heading and all its references across the whole workspace; so renaming is not really a problem.

I understand your point of view, but IMHO there are also other concerns at play here in favor of immutable filenames:

• less diff noise (I have my notes in Git)
• easier renaming when my usual tooling is not available (on mobile, different computer)
• huge pile of existing Markdown notes and not enough will to migrate to a new style
• just plain old personal preference

I think this is a valid angle on the problem. If e.g. a tool such a emanote or neuron (which further support zettelkasten) require wiki links to use filenames rather than slugs; it'd be nice for Marksman to be able to play nicely with them.

Exactly. The way Marksman currently works lends itself more to starting from scratch rather than using it with existing notes, which I think is a pity.

[artempyanykh]

Ok, cool. In summary, I think having a configuration for the style of wiki-links would be a valuable addition. I can't give an ETA, but I can say that it definitely will be on my list. That is, unless somebody else volunteers to implement it 🙂

[MilanVasko]

Of course, no pressure! Thanks for your understanding.

I might give it a go myself, but since I have no experience with F# or writing language servers, I can't promise anything 🙂

[dzintars]

Just will add my two cents. This is how my notes looks like. I use those file names as it gives me an flexibility to move and transform notes around. To split notes. To rename notes. Whatever. I don't need to think where does this note belongs to. I have a flat file structure. Which IMHO is HUGE benefit. I was using Obsidian before, but lately for like a 6+ months i use only https://github.com/mickael-menu/zk-nvim as it is right at my fingertips because i work only in Neovim. Obsidian is a great software, but it's an Electron and requires context switch from me. I like how Obsidian treats Aliases and blocks, but i can live without those. Also image management is nice as you can just drop the image there. After i switched to zk-nvim i don't bother with images anymore, thou i would like to. Sometimes it's helpful to have illustrations. So, zk-nvim's compatibility with Obsidian's file structure and core features is somewhat important to me, as i can use one or the other software when necessary. Unfortunately zk-nvim does not support #'s when referencing the notes which could be helpful. But at the same time this sounds like a "zettel antipatern". If you have a lot of # in your notes, this means your notes are not "atomic" enough and thus are breaking "composability rule". Also in zk-nvim currently i can't search notes by their aliases. For example SSH and Secure Shell Protocol should refer to the same note file because those are listed as aliases in frontmatter. Also integration with Telescope is great. I think i would not use it if there would not be an easy way to search and see the previews.

[edrex]

I also want links to use filename (without suffix) rather than the embedded title. The title changes too easily, and anyway that's what other tools in my toolchain (emanote, obsidian) expect.

I also note that many of my files don't have an h1 title, and they don't show in the autocomplete list at all.

I think making the completion behavior configurable makes a ton of sense. Also, the note title note filename should be matched on for autocomplete, in general.

p.s. thank you thank you thank you for writing marksman. I have been wanting such a tool for a loong time, you've done a great job.

[artempyanykh]

This feature is coming along nicely in #117 I hope that soon basic support will be ready.

[artempyanykh]

Now that #117 had landed, the basic support should be there. There are more things to sort out around link resolution and further tunings to the completion, but check the latest release and do give it a spin.

[MilanVasko]

I haven't followed the PR discussion nor studied the code so I'm not aware of any lurking edge cases, but I tried the latest release with the wiki.style = "file-stem" option and it seems to work correctly for my needs, so I'll go ahead and close this issue.

I'll definitely start using this for my notes and I'll reopen if I encounter any problems.

Thanks a lot! 🙂

[artempyanykh]

Glad to hear that @MilanVasko! Sure, feel free to open new issues if you come across any problems.