Separating title from file name

[nathanbraun]

Just found this plugin today, great work!

I think I'm going to switch over to it from my current solution (vimwki + vim-zettel), the only thing it'd really be missing is the ability to separate file names from titles.

For example, in vim-zettel, each file is named with a timestamp (with letters if you create two notes in the same minute) so everything is unique, e.g. 220103-1159.md. Separately, each note has a title ("renerocksai on how to take good notes") that you can change. I find this reduces friction taking notes because you don't have to worry about coming up with a perfect filename (and title) that you never will be able to change.

Then to link to a note from another you use the [text to display](link) format, e.g. [renerocksai on how to take good notes](22013-1159.md). vimwiki hides the actual link and just displays the text to display, but you can follow the link etc.

Misc stuff:

• It's also be nice to be able to highlight some existing text in visual mode, then run a telekasten function (create new note) and with the automatic unique filename and have that visual selection as the title.
• vim-zettel includes separate commands for searching by title and by note contents, which is kind of nice.

Any thoughts? Cheers!

[jglueckstein]

I have used vimwiki quite a bit but never vim-zettel. I think these ideas all have merit. I'm missing some of the vimwiki features you've mentioned. Not sure how difficult it would be to implement any of it. I'm a lua noob.

[nathanbraun]

vim-zettel is purely a vimwiki add on, it's not meant to be used standalone. I think it's basic features are what I mentioned: unique timestamped filenames (optional), backlinks, display title vs filename, etc. It does a lot of the same stuff as this plugin (backlinks, tags, etc) but it's not neovim specific and is quite a bit slower. I think with the separate filename and title functionality this plugin would be clearly better. I don't know any lua either, but I'd be happy to pay/sponser this project if it really turned into my full time notes solution since I use it so often.

[nathanbraun]

In terms of implementing this, two features that would make a big difference I think:

1. The ability to do [display text](link_to_file.md) syntax. Maybe eventually so the filename part is hidden and it just shows display text, but doesn't have to be right away.
2. A setting to turn on automatic timestamped/unique filenames on new zettel creation.

Then maybe later could do something with titles, templates and the ability to prefill them or copy a zettel and have it grab the link in [title](filename.md) format, etc.

[sbock17]

Hello,

I am a vim-zettel user as well - regarding @nathanbraun, I would like to have the same feature.

Regarding the linking:

The best way would be to have a linking style like so:

The filename would consist of a ID_Title.md, like %Y%m%d%H%M_%title.md, corresponding to
202201152015_Titel.md

Now, it would be super great if the linking behavior would be possible just by linking with the ID, even regardless of the filename, e.g.

[[ID]], meaning [[202201152015]], instead of [[202201152015_Titel]], or[Titel](202201152015_Titel.md).
By linking only with the ID, it would not matter to rename a file. If it somehow would be possible to work out, the same linking style suggested from @nathanbraun should then also be possible [Display text](202201152015)

This would then also be an overall improvement for vim users on linux for using a zettelkasten with UUIDs in general that has not yet been available, to my knowledge at least.

By chance, How much would this be possible? Is it even realistic, or just wishful thinking?

Kind regards :)

[lambtho12]

Just proposed a PR to solve parts of this. See #84

[renerocksai]

In previous projects I have dealt quite a bit with ID-based Zettelkasten notes. With telekasten I wanted to make it easier - as many requests were "please support [[wiki style]] links".

Having wiki style links even now gives you the possibility of only working with [[ID]] links. If you have an ID generator (in nvim or external), this is trivial. Then you can have all the metadata (everybody has their own idea there, too) inside your note. If you use [[ID#Some-title-for-display]], this is a quick workaround since telekasten only looks at the part before the # when resolving file names.

I am explicitly NOT a fan of putting titles in the yaml-block and have telekasten grep for the title in yaml-blocks when trying to resolve a link by title. This is bound to lead to worse performance than just searching for files with the given name.

However, ignoring parts of the link to get to the filename, so that [[ID]] and [[ID some extra title stuff]] would be equivalent, I see no problem with. This is the way I implemented it in earlier projects. (sublime_zk and sublimeless_zk). I, personally, would also prefer it this way if I went back to using IDs- just like @yetipowers (great name btw)!

As a side-note: parts of my notes still are ID-based - and work fine with telekasten. Because: telekasten does a filename search on the IDs - and finds notes starting with the ID as well as notes having only the ID as filename.

I agree, a [markdown link](title) would be a great option, too. The drawback here is: how should telekasten distinguish such a link from a real link to a local file? Why it needs to distinguish: it might need to search in sub-folders, depending on the already supported options. Also, following a note-link requires different behavior: optional note creation with template substitutions, etc. Whereas 'normal' markdown links can just be passed on to xdg-open or open. One trick would be to either: leave the filename extension in the link: [title](filename.md), as suggested by @nathanbraun - that way telekasten could treat all .md files as its own. But then, the filenames should always be correct. So if you have a filename scheme like id_title.md, you shouldn't mess with the title part in there even if your real title changes. But nobody would do that anyway - I hope, or else there wouldn't be a point for having [title](filename.md).

The other option would be: to cut the filename extension off: [title](filename-without-extension) as a signal for telekasten that this is a note-link. What do you think?

Regarding the misc stuff:

• the current implementation by its very own nature separates between searching by title and searching in notes. 😄
• creating note by visual selection: yes, that would be nice. In my previous projects I supported multi-line selections: the stuff in the first line would become the title and the remainder would become the note's body. This was neat and worked well for template-expansion.

Implementing ID stuff and have it optional requires a bit of thought and work. One thing comes to mind: timestamp-based IDs. When I had second-based IDs there were people that were creating multiple notes per second. So we had to support millisecond-based IDs.

I will come up with something.

I see [markdown](links) as a way to have alternate titles. Other people prefer [[filename|Alternative title]]. I am a bit surprised nobody asked for that (yet) 😄 - or maybe I missed it.

I prefer [[ID Title]] or [[ID]] for purists.

Let's discuss - but I think I can support

• wiki links like they are now
• markdown links to notes
• ID based links where only the ID part counts

relatively easily - it will just be an option "nightmare" - something to consider for the README, too.

[sbock17]

the current implementation by its very own nature separates between searching by title and searching in notes

Yes, the ability to search by title was also the reason why I came up with ID_Titel filenaming, to on one hand have still a unique ID, and on the other hand let all my files being human readable. I can see why you now don't use ID's anymore, because it is just way more practical than having only IDs, e.g. if you send some notes to another person and They are confused about all the numbers :)

I still find the idea of ID's fascinating and practical and experimented with just using ID, (sidenote: no milliseconds yet, but from a time where I didn't use ID's, there were some moments where I prepared files, created new files in the milliseconds range too…).

ID's have this big advantage - surely finding a note with just it's unique number. And I think using the timestamp is really a good idea, because it can also be a replacement for date and letting them therefore easily list in chronological order (even though that's not what they're supposed for).

There are of course lots of different ID naming conventions, like the concept of nearness (e.g. classic Folgezettel), or just a Note count starting from 000000001 :D, or just completly random IDs which are here already used for paragraph referencing (which is very powerful and also a reason why I am about to switch the tables).

wiki links like they are now
markdown links to notes
Other people prefer [[filename|Alternative title]]. I am a bit surprised nobody asked for that (yet) smile - or maybe I missed it.

Big surprise: At least in vimwiki, it is totally possible to conceal filenames with this wikilinking [[File | Title]], essentially leading to the same solution like markdown style Title.

If this [[filename | Title]] concealed as Title (with our without .md would'nt matter I believe) could be implemented, I guess @nathanbraun will be fine with the solution aswell I hope.
To me it is also a big caveat that Markdown note Links can be confused with other local file links, web pages, images etc. .. And also counting links inside of a note would be just a simple $ grep -c [[ "Filename.rmd" away.

I prefer [[ID Title]] or [[ID]] for purists.

Yes, I've also used both approaches, except that, I only have the habit of replacing whitespace in filenames with _, [[ID_Title]].

ID based links where only the ID part counts

If the user could define their ID's on their own (with some basic rules, like no hyphen inside of ID, and then using the ID variable optional as „Prefixlinking“ (and maybe setting a rule, how Prefix is concatenated, with title element e.g. with _ or - ) or simply act as the standard way for the title, this would be very great! If then this „Prefixlinking“ element thus the ID, could be somehow used for link resolving, while being 100% sure every ID being truly unique (easily ensurable). So that everything after this Prefix could be arbitrary text, or even empty, and this defined Prefix, such as a timestamp ID, would be the sole linking element

Well… then I would be very much happy, that's for sure :)

In vimwiki, I can easily let it read .rmd as the filetype for markdown as well. I would like to know how to apply this setting to telekasten, and how code fenced blocks, such as R code chunks could be syntax highlighted, amongst other languages… and how to basically allow to let the notefile be seen as telekasten filetype, and at the sametime Rmarkdown filetype, so I could still open up my R console via nvim-r plugin. This has worked so far using vimwiki / vim-zettel, and there should be a workaround in telekasten too for sure … If even this could be solved in the future, that would be amazing :)

[renerocksai]

Wow, I just discovered your reply.

I agree with everything you say, including underscores 😄!

Regarding .rmd I am a bit biased since I don't particularly like R. I see highlighting of syntaxes for other languages not part of this plugin. Treesitter seems to do an excellent job here. If supporting Treesitter means we should make a parser for telekasten-specific syntax, then I think we should do that - and leave all the other syntaxes to Treesitter as well.

The reason we have our own filetype is to separate it from ordinary markdown files - and still be able to support our syntax extensions to "markdown" files. Maybe there is a way to have telekasten import other syntaxes based on original file type - but it might be tricky. Treesitter should be able to help here - I guess...

[sbock17]

If supporting Treesitter means we should make a parser for telekasten-specific syntax, then I think we should do that

I believe the solution for me would be just:

    -- markdown file extension
      extension    = ".rmd",

To be honest, I do not know how to use treesitter. But it does have an R module, and have just read that rmarkdown support is worked upon. It seems that in the near future, the initial thought of code fenced blocks should be possible.

As far as I can tell, code fenced blocks in markdown simply mean that a different language can be activated. So as you say, highlighting different languages clearly has nothing to do with telekasten. I took a look on sublime_zk, such great work, and it also had syntax highlighting. Usage of footnotes as well, to be rendered via pandoc.

Rendering via pandoc is one of the reasons why I work in rmarkdown by the way.

Another example of code fenced block would be e.g. argdown, starting off with the question for how to generate syntax highlighting for code blogs of argdown in vim, and it seems even this could be done with treesitter as well. E.g., argdown, markup for communicating logical argumentation structure for e.g. debates. As far as I understood now, treesitter just needs some source code to build a syntax highlighting. I have realized that neovims new feature of treesitter is a really big topic and I do not know how dificult it might be.

To the topic:

If making a treesitter module for telekasten would not be that difficult to you, and this would result to syntax highlighting for features like footnotes or paragraph links would be nice.

I would also like to know, how pandoc-compatible rendering a note would be e.g. with paragraph links.

And a feature request: What about footnotes which are compatible with pandoc, where this would be a valid footnote: [^1]

[^1]: And here would be an explanation of this footnote.

I think, these things, along with paragraph links, could be syntax highlighted as well in a telekasten treesitter module.

But again - I know there could be a lot to think about. And I think the things mentioned in this reply do not have a high priority in my humble opinion!

[renerocksai]

I don't know a lot about Treesitter either, yet. However, it enables multiple (treesitter) syntaxes in the same file.

So if you put in a fenced code block like this:

    ```R
    some R code
   .```

Tree-sitter would probably know how to syntax-highlight the R portion there. It should also know what the correct comment character(s) are if you want to comment-out a block, etc.

Using .rmd as extension should work. But telekasten only imports nvim's built-in markdown syntax. This is something that would need to be changed. Maybe I can find a way to make that configurable. I am not sure if it's possible. Loading syntaxes based on file type - is usually done by having a filetype-named syntax file in place, not sure if this can be intercepted. However, if markdown syntax is OK for your RMarkdown stuff then extension = ".rmd" should do the trick.

I imagine, to support treesitter, I need to create a telekasten syntax for treesitter. Maybe with some code that tells it that it's basically just markdown plus a few extras for wiki link highlighting. I have no idea how to do that yet.

Footnotes! Yes, I haven't had the need for them since switching to telekasten yet. But that's a great idea!

I would also like to integrate pandoc's @bibtex-key syntax and being able to insert citations (see sublimeless_zk, sublime_zk). There's just so much I want to do. This stuff, a really good tag search syntax+parser+actual search code, the "special buffer" with all sorts of useful stuff incl. saved searches, .... .... ....

[renerocksai]

BTW title changes: Obsidian can rename the file and update all links. This is also something to consider, while at the same time appearing a bit dangerous to me. It would probably need to be done in a transaction .... But let's not go down that route.

[sbock17]

BTW title changes: Obsidian can rename the file and update all links. This is also something to consider, while at the same time appearing a bit dangerous to me. It would probably need to be done in a transaction .... But let's not go down that route.

vim-zettel, as it builds upon vimwiki, also has the function VimwikiRenameFile - which searches and updates links after renaming the file.

nmap <Leader>zr :let @*=zettel#vimwiki#new_zettel_name(zettel#vimwiki#get_title(expand("%")))<cr>:VimwikiRenameFile<cr>

But it does take some time when there are lots of notes cycled through.

[renerocksai]

Oh: no hypens in IDs or else telekasten might get confused: do you want to link to a daily note or a regular one....

[nathanbraun]

If you use [[ID#Some-title-for-display]], this is a quick workaround since telekasten only looks at the part before the # when resolving file names.

Excellent, this works for me for now vs something like [title](link).

The only missing thing then would be an option to automatically make new zettels created with a timestamped/unique ID (vs asking for the title and using that for the filename like it does now).

I tried making an insert mode shortcut to automatically insert a formatted timestamp by pressing ;dt, but it didn't work — it must not technically be in insert mode when it asks for the title. Seems like it could either "prefill" some default timestamped or just create it and take you to the new note.

Implementing ID stuff and have it optional requires a bit of thought and work. One thing comes to mind: timestamp-based IDs. When I had second-based IDs there were people that were creating multiple notes per second. So we had to support millisecond-based IDs.

It's wild that people are creating multiple notes a second; vim-zettel does it down to the minute, with a letter (a, b, etc...) if you create more than one. Personally I don't have strong feelings on the format of the timestamped files, I wouldn't care if they weren't even timestamped, just as long as they're unique. In my view, the ID/filename itself is just so telekasten can link to the correct files.

Ideally we probably wouldn't even have to see them. That's why I like the [text to display](filename.md) format vimwiki/vim-zettel use now, where they it only shows text to display (unless your cursor is over the link); it messes up formatting sometimes on long/wrapped lines but it's not too bad. Also why I wouldn't ever (personally) use the id_title.md schema that @yetipowers talks about.

If it looks like the id is going to be showing up a lot in notes (e.g. the hide filename part is a long way off/never happens) i guess I'd prefer a shorter unique id, vs something really long and down to millisecond.

The other option would be: to cut the filename extension off: [title](filename-without-extension) as a signal for telekasten that this is a note-link.

This seems like a good option to me, seems reasonable for telekasten to treat links without extensions as its own.

[sbock17]

Ideally we probably wouldn't even have to see them. That's why I like the text to display format vimwiki/vim-zettel use now, where they it only shows text to display

By the way - you can actually link files with [[filename | title]] in vim-zettel, and you would just see the title. Have you tried it?

I tried making an insert mode shortcut to automatically insert a formatted timestamp by pressing ;dt, but it didn't work — it must not technically be in insert mode when it asks for the title

Not sure if this would be of any help, some mapping for timestamp assuming ; is your <leader>
(without milliseconds - I have not yet understood how to realize it)

" Inserting datetime  timestamp for a new ID (YYYYmmddHHMM)
nnoremap <leader>dt "=strftime('%Y%m%d%H%M')<CR>P "inserting the ID in normal mode
inoremap <leader>dt <C-R>=strftime('%Y%m%d%H%M')<CR> "inserting the ID in insert mode

[nathanbraun]

I guess the only other related issue with all this, is it'd be nice to be able to get the links (when using yank_notelink(), show_backlink() or control + i or control + y in the picker) in the [display](filename) type format (or whatever the format ends up being). I know you said you're opposed to searching for title in the YAML @renerocksai , but would you be opposed to using it/something like it in this case to generate the display link?

[renerocksai]

This is a funny question. What are your assumptions here?

Theoretically: yes, that would be doable: [display](filename) format on link insertion, by reading the title from the file. There's only 1 file involved and it's a special case, so why not? 😄

However, what should the picker display in the first place?

If your file naming convention is only {ID}.md - then how useful would the picker be when all you get to see are a bunch of note IDs and a preview window? You'd have to scroll through the entire list to find the right note by preview - and then you can insert a link - which could be a nice [title](filename) link.

If your file naming convention is {ID} {title}.md, then you wouldn't need to grep for the title necessarily for link-creation, since the title would be contained in the filename anyway and hence would end up in any link that shows the filename like [[filename]] or [{title part of the filename}]({entire_filename_including_title}). The only advantage with grepping the title from the file would be that you'd be able to change the 'display' title without having to change the filename with all its consequences.

So if you start with 123_awesome_note.md, and later change the title within the file to super awesome note, your generated link would become [super awesome note](123 awesome note.md).

In the example with {ID}.md we're entering territory I find sub-optimal: in order to show anything meaningful in the picker, ALL notes would have to be opened and read from to get their titles. That is bound to have a performance impact. The difference in large note archives will be noticeable - comparable to doing a text-search (Telekasten search_notes).

Having said that: Telekasten uses no cache whatsoever. So every tag search is always done 'live'. Finding the number of links and back-links also requires reading ALL notes upfront. So far, this has been no problem. Performance upgrades by caching and some sophisticated cache invalidation stuff (if you copy in a whole bunch of notes) can be done at a later time...

One other reason why I don't like hiding the title in the file and not even having the fallback title contained in the filename is: if you mess up the header, the notes will be 'lost': accidentally removing the colon in title: - boom, your note title is no longer findable. It also opens another can of worms: I suspect different people will have different flavours of putting titles into their notes. One might prefer a yaml-header with the title: "keyword", another one might prefer a localized Titel: and yet another one might prefer it heading-style: # The Title. Supporting all these formats in a customizable way seems ... Not ideal.

My examples here are also based on assumptions - so I might have gotten everything wrong 😄. Can you be more specific? I think I understand where you're going with your comment but it's either not thought through well or I totally misunderstood it.

I hope that didn't come across too unpleasant. I really value your suggestions and I am super happy we're having this discussion! 👍 😄

[nathanbraun]

However, what should the picker display in the first place?

Interesting, I was envisioning just using basically the search_notes() function, typing in some text, seeing it in context on the left (and in the preview) on the right, and opening/inserting links (using enter or control i or whatever) that way. You are right that with purely ID based notes, searching on filename doesn't make a lot of sense.

I didn't realize that there'd be significant performance hits to searching (large) note archives, but I guess it makes sense. I have about 220k lines in my note system, and performance doesn't seem too bad with vim-zettel (and my impression was that this would be faster, but could be wrong), but not sure how that compares to the usual sizes people would be using.

The way I have it set up right now is basically two functions, both using the full text search. One searches full text, the other searches full text but automatically inserts "title: " at the front so i can search by title name. This works well for me, and is what I was trying to get at here, but obviously people use it different ways/I'm not knowledgeable about how things are implemented/it needs to be well thought out etc.

I'm definitely open to including some sort of title/slug in the filename if it will make things way easier to work with. I just really like being able to create new notes with 0 thought/friction at all, and if they're ID based I don't have to worry about coming up with a good, unique, searchable slug or getting a great title right away etc. I also like being able to link to things in context and not nec by title, so if I have a note about something, I often include a link like:

"Here's how to set up a new server on digital ocean. Once you set it up, here's how to [get your ssh keys on it](2019-0912.md) and [install postgres on it](2022-01011234.md)."

Which with the filename hiding appears like:

"Here's how to set up a new server on digital ocean. Once you set it up, here's how to get your ssh keys on it and install postgres on it."

[renerocksai]

I get it. For you, a purely ID-based naming makes sense. Title slugs would only help as long as they are correct - otherwise, some might end up as distractions.

If all you ever do is search_notes() then that should be fine. There is an objective performance cost associated with searching through files as opposed to listing the filenames of a directory - and filtering that. How searching within files requiring opening and reading at least the top N bytes from them and then searching within those blocks should be faster - I don't see that.

But: perceived performance is highly subjective and depends on expectations. With SSDs being pretty standard, you'd probably need to have thousands of notes to even see a noticeable difference when you're not sitting there measuring it. So a purely file-content-search based usage of telekasten is feasible.

From a programmer's point of view - I still prefer to have somewhat meaningful filenames. Also from a longevity point of view: if I have NO tools whatsoever I can still navigate through my notes by just using a file browser. If all note names are IDs, I need to look into every single one of them to find out what they are about. So I would definitely need a find-in-files function at the very least. Think of browsing through notes on GitHub. I like to be prepared for situations like that.

But all solutions have their drawbacks or costs. So, configuring a filename template that only contains the ID is something I wouldn't object to.

[renerocksai]

Regarding ID prefixes: a quick fix would be to define a prefix-format in the config that new_note() uses. If it's emtpy: fine. If it's some os.date() compatible format string, you'll end up with a timestamp. To top it off, the prefix could be stripped from the title for the {{title}} template expansion, and an {{ID}} field could be added. That would be super easy and quick to do.

However, links generated would be: [[{ID}{title}]]. We could change that to [[{ID}#{title}]], though when we have a non-empty prefix.

What do you guys think? Would that be a liveable quick-fix until we have something better?

Regarding naming the files, here I'd suggest going with the entire string: {ID}{title} for reasons I stated in the previous comment.

[renerocksai]

Yes, good point. I am working on a PR to add note renaming, I will try to improve the sed command to be more robust.

YESSSS!!!!!! Mind you, links may also contain #heading and #^paragraph-id parts - and soon |alternate title parts.

[lambtho12]

YESSSS!!!!!! Mind you, links may also contain #heading and #^paragraph-id parts - and soon |alternate title parts.

I am not as skilled as you when it comes to lua (or development in general).. So one baby step at a time 😄

[renerocksai]

Baby steps! 😄 Fair enough! We will get there!

[lambtho12]

Ok just, pushed a WIP PR #67.
Still very basic, but it seems to be working ok (on linux)

[lambtho12]

Completely forgot that you already proposed a basic set of features for these IDs... I just made a PR to add UUID to filenames (and reuse theses in templates). It is not overly complex and should already fill the needs of most people.

This could serve as a base to future improvements related to filenames.

[renerocksai]

I find it increasingly difficult to use these discussions - and not miss a new addition to a thread. I actually open my gmail to check for new entries, then go back to GitHub and search for the reply within the browser.

Should we try to go somewhere else? Discourse seems to be pretty hyped these days. But TBH 100$ per month is not worth the odd discussion or two.

Any opinions / suggestions? Maybe there's a cool option in GitHub that I'm missing that enables a more sane thread-based view?

[sbock17]

And yeah, underscoring all kinds of such characters is what I also always do for the titles, vim-zettel also does that, with a defined seperator.

For alinear / network / context / discussing, no clues what alternative to use. I guess the simplest solution is keeping it linear by just avoiding directly replying so every new answer is 100% at the bottom. And maybe for other features a new thread should be opened instead.

I'm really happy about the resulting list for the kind-of-quick fix @renerocksai !!
Also for the @lambtho12's sed magic, simple enough to grasp it, very helpful :)

[lambtho12]

@yetipowers thank you. I am working on the PR to implement that in telekasten now. Seems to be working ok on my side. I am going to improve the sed command so it work with regex and be more robust.

For now, I look for [[ markers as well as suggested by @renerocksai . However, I only look for the first ones, not the ones at the end of the link. That way, if the link is like [[filename#heading]], I only look for [[filename and replace it with [[newname so the #heading is preserved.

[renerocksai]

That sounds like a good solution!

[sbock17]

Currently, I rarely use new_note() as the {{title}} template would give me YYYYMMDDHHSS-My_awesome_title, which would require me to change it at multiple place after that. I use snippets and custom functions instead to create new notes. It is not that big of a deal, but it takes a lot of operations to have the new note setup as it should be.

@lambtho12, could you please share your custom snippets regarding zettel note creation?

I'm now going to try out build my nvim config in lua from scratch and finally switch the tables in favor of telekasten instead vim-zettel. Vim-zettel had just a simple function for creating a new zettel.. So could you please show, how you are doing it basically?

Kind regards from Germany :)

[lambtho12]

Sure! It is not the simplest stuff and there is probably a million ways to improve that (but eventually I will not need to do that once titles and filenames will be differentiated :D) .

Convention

My files are all named like so YYYYMMDDHHmm-Short_title.md.
Usually, a note will look like that

# Note title

Bla bla bla [[202112111010-Some_link]]. 

---
title: Note title
date: 2021-04-08T17:04
type: #note
tags: #mytag #myothertag
---

Note that the title in the note # Note title is not necessarily the same as Short_title used in filename. Sometimes it is, sometimes not.

Nvim setup

• I use basically two snippets with LuaSnip. One for generating UUID in the form of YYYYMMDDHHmm, one for the note template.

{
  "uuid": {
    "prefix": "UUID",
    "body": [
      "${CURRENT_YEAR}${CURRENT_MONTH}${CURRENT_DATE}${CURRENT_HOUR}${CURRENT_MINUTE}"
    ],
    "description": "UUID",
    "autotrigger": true
  },
  "znote": {
    "prefix": "znote",
    "body": [
      "# ${1:Title}",
      "",
      "$0",
      "",
      "---",
      "title: $1",
      "date: ${CURRENT_YEAR}-${CURRENT_MONTH}-${CURRENT_DATE}T${CURRENT_HOUR}:${CURRENT_MINUTE}",
      "type: #${3|zettel,hub|}",
      "tags: #${4:untagged}",
      "---"
    ],
    "description": "Zettel note",
    "luasnip": {
      "autotrigger": true
  }
}

• I also have a lua function to paste the filename (after sripping the UUID and replacing the _by spaces. I call this function with a mapping.

local function cleantitle()
 filename = vim.fn.expand("%:t:r")
 filename = string.sub(filename, 14, -1)
 filename = string.gsub(filename, "_", " ")
 vim.api.nvim_put({ filename }, "", true, true)
end

Note creation

1. First I create a new file.

• If I am already editing a note and want to link to the new file, I just create a link to the non-exsisting file by typing [[uuid (uuid expands with snippet), then -Short_title]] and then I use Telekasten.follow_link to create a file with that name.
• If it is a standalone note, I just do :e YYYYMMDDHHmm-Short_title.md(very inefficient)

2. Type znotein the new note so the snippet expands the template
3. Either type a longer title, or use my mapping to paste the sanitized filename
4. Jump to the other snippet stuff with <C-j>to quickly adjust all that

[lambtho12]

Now that I detail all of that, I realize that half the pain could be removed easily by just adding an option to Telekasten such as prefix_title_by_uuid. If true, the title will be prefixed by an uuid automatically and the {{title}) template variable could maybe remain untouched. That would make the note creation 2x faster for me...

[lambtho12]

Just did a basic implementation 😄 See #84

Now users will be able to specify to new_note or new_templated_note if they want an UUID...

[TheTaoOfSu]

This has covered a couple different topics, and there's been some confusion from all the reply nesting, so I'm just going to drop a new top level here.

On the subject of titles, I do think some configurability would be beneficial. I can understand not wanting to overly complicate the configuration, but I think a lot of that can be avoided by choosing sensible defaults that will match what a majority of users want. Many will probably be fine with just about any default system, but some will have their own preferences, and even just a few swappable options could go a long way. The templates system also already gives people a handful of defined tags or markers that users can use to define their own custom file name formats.

I saw some discussion of supporting markdown style links. A lot of this discussion is over a year old, and I only just recently started using this plugin, so I'm not 100% clear on if it has been implemented yet, but this is definitely something I think would be a good idea. I prefer to avoid working in custom and wiki formats because it makes it easy to export content that needs to be shared through something like pandoc. Introducing a new format and restricting users to it breaks this potential functionality.

There was also mention that hyphens in IDs, I assume particularly IDs that include dates, may confuse Telekasten since it might not be able to differentiate between a daily note and a regular one. Since Telekasten sets a designated location for daily and weekly journal entries, shouldn't this be a relatively trivial distinction? If the note is located in the journal folders, treat it as a journal entry, and if it's not, treat it as a standard note. I take it this means that multiple journal entries for a single day might lead to conflicts, then, too? The dated nature of journal files is useful for some content I intend to share, so I'd thought to use journal entries for it, but there's a nonzero possibility I may eventually need to make multiple distinct notes on the same date.

[lambtho12]

I saw some discussion of supporting markdown style links

This is indeed something that is on the ever expanding backlog. We all agree that it would be nice to support these as well. Unfortunately, as stated in multiple other discussions, Rene and myself are the only two active maintainer of this project and we are pretty busy with our work life already. So development is slow. Besides that, the codebase is a bit messy currently. This makes it difficult to maintain and more prone to issue with every new PR or change. I am trying to set aside one or two hours a week to work on the refactoring, but even that is rather challenging. Same for Rene.

Since Telekasten sets a designated location for daily and weekly journal entries, shouldn't this be a relatively trivial distinction?

Yes and no. This only makes sense if the link is e.g., [dailies/2023-03-27], which is not the case as these would be linked as [2023-03-27]. As we only use follow_linkfor opening any type of link, having a fixed pattern allows the function to know where to look. Without this pattern, we would have to look into the entire zettelkasten.
That being said, we could have a simple switch follow_link{dir="daily"} that would let the user customize the mappings and restrict follow_link to some directories only. This would allow a ton of new usecases. And we can also create a follow_date function that would just alias to follow_link{dir="dailies", dir="weeklies"}or something. If (when) we have something like that, then we can remove all hard-coded notations altogether and let people name their files as they want. As for UUID/title, we could let the user set the format in the options.

But once again, even if this does not looks too hard to implement, I think a good refactoring would be a great first step in order to avoid making this +3000 lines file a lot longer and harder to maintain...

[TheTaoOfSu]

Having cloned the repo and started looking through it to get a feel for the structure, I do agree that a refactor is a great idea. I am interested in helping expand some functionality for Telekasten, especially as it applies to my use cases, but since I don't know much about how neovim plugins are made quite yet, it has been a bit challenging. I would be happy to help implement things and squash some bugs, but refactoring is probably best left to those with a deeper understanding than I have.

[nathanbraun]

Have you seen:

https://github.com/mickael-menu/zk
https://github.com/mickael-menu/zk-nvim

I moved to those, seem better for my uses/more well-maintained.

[lambtho12]

@TheTaoOfSu, I think I will refactor progressively by making a few commits here and there very week-end. Originally I planned to make a separate branch to do it, but I am afraid that I will never finish it if I go this route.

@nathanbraun, zk is great indeed and their development is much more consistent and organized than ours, that is for sure. I personally do not use it because it has the "drawback" of being a separate tool, while Telekasten is just a neovim plugin that has minimal dependencies outside of neovim itself.