question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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.

Issue Analytics

  • State:closed
  • Created a year ago
  • Reactions:2
  • Comments:13 (6 by maintainers)

github_iconTop GitHub Comments

2reactions
artempyanykhcommented, Aug 24, 2022

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?

1reaction
MilanVaskocommented, Dec 20, 2022

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! 🙂

Read more comments on GitHub >

github_iconTop Results From Across the Web

Use H1 or YAML property "title" instead of or in addition to ...
I'm interested in a setting that would use a note's H1 or front-matter title instead of or in addition to the filename as...
Read more >
Use H1 or YAML property "title" instead of or in addition to ...
I'm interested in a setting that would use a note's H1 or front-matter title instead of or in addition to the filename as...
Read more >
Following markdown links : r/ObsidianMD
I've configured Obsidian to use markdown links, rather than wiki links (not that it matters for this discussion).
Read more >
WikiLink syntax support · Issue #56
... use the full file name of a note: [foo](@note/My Other Note.md) , my understanding is that WikiLinks perhaps refer to the title...
Read more >
FeatReq: Autocomplete links with notes titles, not filenames ...
click on placeholder - filename = placeholder text. Currently I am hardcoding my way through the extension code to use "Daily note format"...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found