Behaviour with Vaults regarding daily, weekly notes

[plum]

Please confirm

• [x ] I am running the latest version of this plugin

Tell us about what's bothering you... ... I've played hard with Telekasten.nvim, over the last week, and must take this opportunity to congratulate you on your vision and its realisation; it's very good indeed, and, I believe, much needed. The calendar, the journal, and its overall scope is superb as a whole.

I've long used vim for writing as my preferred writing instrument (by far) in markdown. I do not write for code development, but for education, practice, publication, and contemplation.

Now onto my question, asking if this is desired and expected behaviour with vaults;

• Q. When searching for notes in a vault,
  • Telekasten asks for permission to create a (non-existing_ daily , weekly and template dir, on each occasion, before telescope is permitted to start up with a file list, for selection. And so, each vault has to have such directories in order to function in Telekasten, as a vault.

For me, such dirs are redundant; I would not wish to keep a journal in every vault of notes, such as Vehicles, and Crafts, Computer, Music_Theory, and Recipes. It is possible that I may wish to have a different template, sure. You can see I have already five vaults in all, each with subdirs, and may add another five, all rather distinct.

In m Journal I do keep a personal diary and blog ; I even have one 'diary' in vehicles, not a dir of daily writing, but a single file called 'service-history' ; I think I've made my point!

You can view my outline of vaults in the config snippets below....

Confirmation of expected behaviour would be appreciated.

We have a 'default' vault, and this is called 'home'

    require("telekasten").setup({
      home = vim.fn.expand("~/Notebooks/Journal"),

Next, I have my 'secondary' vaults:

     vaults = {
        crafts = {
          -- alternate configuration here. Missing values are defaulted to, 
                    -- default values from telekasten.
          auto_set_filetype = false,
          extension = ".md",
          template_handling = "smart",
          home = "/home/chuee/Notebooks/Crafts",
        },
        Recipes = {
          home = "/home/chuee/Notebooks/Recipes",
        },
        Computer = {
          home = "/home/chuee/Notebooks/Computer",
        },
        Vehicles = {
          home = "/home/chuee/Notebooks/Vehicles",
        },
      },
    }),

Cheers! John

[lambtho12]

Yes this is the expected behavior, although I agree it is not optimal to be nagged every time, especially when you do not plan on using the daily/weekly functions for instance.

As it is now, you have three possibilities:

1. Set the template/weeklies/etc directories to nil in all other vaults. That should normally get rid of the nagging when you are in these vaults.
2. Set these directories to the one you plan on using for all vaults, so you can always access the journal/template for any vault.
3. Embrace the true Zettelkasten way of doing things and have everything in one single vault (with sub-directories if you really need to)

[plum]

@lambtho12 Thanks for a comprehensive, useful and quick reply. Perhaps you could point out a a decent tag method?

I haven't used them since I left OSX and NV and ran with arch 10 years ago.

I had since looked into and implemented ctags with vim, but stopped, I did implement them, but didn't get much further, as I was struggling with plugin conflicts. Oftimes plugins would bog vim down, and there were few for Neovim. Things have changed though now, as regards Neovim plugins; Its' going places. Perhaps skilled use of ctags could well help me. Mere word search was not enough, and linking files remains important.

I do recall that I considered that,

• Tags that didn't persist worried me.
• Writing tags in a file metadata slowed down my note taking, unless simple (like NV); but THEY didn't persist out of NV.
• I didn't much enjoy seeing the yaml file metadata, or attending to it
  • ( BUt, Perhaps it ok with templates. Or now with telekrasten, just use simple markdown tags).

Some points on my setup

• My Creative notes and techincal notes exist in the same cabinet.
• I use a rofi script to call up vim and either create a new short note or bring one up, from a 'quicknotes' dir .
  • It's like NV, but without the tags.
• Oh, and now presently, I'm getting into Telekrasten.

Cheers, JOhn

[lambtho12]

Telekasten supports various tag notations. You can either use #tag, :tag: or have a specific tag: tag1, tag2, ... line in your YAML metadata. The tag support in telekasten allow you to quickly search for tags in notes and isolate the notes with a specific tag.

I personally like the tidyness of setting up the tags in yaml, but I name my tags following #tag notation. This way, tags are easier to find and it is also simpler to call a tag in plain text. Example:

---
title: mynote
tags: #notetaking #example #tag3 #tags
---
This is an example of note using #tags. By having my tags in the frontmatter, 
I can quickly have a glance at the main topics of the note. 
By using the `#tag` notation, I can also put a reference to #anothertag 
and it will be picked up by the `search_tag` function if needed.

All these tags persist as they are integral part of the note. As they all follow the same naming convention, you can easily search for tags using any external tool if you do not open the note in nvim or with telekasten. This tag format is also the most common one, make it easy to port your notes to an other system in the future if you want (zettlr, obsidian, etc).

[plum]

Thanks for sharing that @Iambtho12 I delayed my reply while I more thoroughly work intensively trying out Telekasten in a flow of intensive work, checking subtle aspects of features. I must say I am very happy.

I am using the same method as you tags: #tag, for similar reasons. the tag: line beginning ensures that I don't get a split there when on occasion I choose to split larger files at #, ##, ### section title marks.

• q. I guess you mean by 'reference to #anothertag, you mean #anothertag in the text body?

My practise used to be wiriitng in yaml metadata tiitle:MyTitle, However, I have for a long time (since losing use of my old web engine and taking up hugo) disposed of that and just use #title.

• q. Do you see any potential disadvantage in my present practise?

John

[lambtho12]

the tag: line beginning ensures that I don't get a split there when on occasion I choose to split larger files at #, ##, ### section title marks.

This is not needed. As long as you do not have space between the # and the word, it will be considered as a tag. If there is a space AND it is at the beginning of the line, it is a heading. Example:

# Heading
## Heading 2
lorem ipsum #tag #anothertag 
lorem ipsum # noting special

I guess you mean by 'reference to #anothertag, you mean #anothertag in the text body?

Yes. Basically the tag functions in telekasten will look for all strings that match the pattern #<text> (if you set the option for tag_notation to be #tag). So it does not matter where it is in the document (header, or body).

Do you see any potential disadvantage in my present practise?

Not really, except if you plan to move from plain markdown to something else that expects to parse the yaml frontmatter.

What I do is that I have a template for note creation that will fill automatically the yaml frontmatter (that I prefer to place I the bottom of the document). See below. What it does is that when I call new_note, it prompts me for the note title, then automatically pre-fill the appropriate information (title and date) in the document. I then complete my note and add the tags properly in the yaml. Having a default tag #untagged allows me to quickly skim my notes and see which ones need to be improved.

# {{shorttitle}}

---

title: {{shorttitle}}
date: {{rfc3339}}
type: #zettel
tags: #untagged

---

[plum]

@Iambtho12 Thanks for kind confirmation, concerning tags in the #tag form.

As you may well know (and almost certainly do, I think), such confirmation really does help as a tip to facilitate fair progress, without unnecessary testing of alternatives for outcomes, , because there is a lot of that to do anyway when changing or incorporating tools for the job, in interpreting documentation, and streamlining and optimising the work flow with the new tools.

I was just about to tackle the templates, having settled in now. I liked your method; It answered all needs and is plain simple, and it's now implemented.

For existing and new atomic notes notes entered outside nvim at the terminal with cat, I'll use a completion snippet fin place of the template.

Concerning unfaltering ease of writing inspiration immediately into a note , if I were to forego writing in the terminal,

• I do have a system-wide shortcut to launch vim in the inbox, with a prompt for filename:
• • _ q. Perhaps I could modify it to launch a new note invoking telekrasten's newnote in nvim with its prompt for note title?

A further question of functionality, in order to define a scheme, follows;

• q. Do you choose to use the yaml template for atomic zettles in a vault, or only for larger concatenated compositions drawn or publication? AND IF for atomic zettles too,
  • q. What purpose other than publication does the yaml serve, given that creation and modification dates are accessible in file metadata if at all needed at any time, and such dates not needed for note selection and manipulation?

As for position of the yamyl metadata in a note, from past I had been constrained to using the first n number of lines in a document for yaml, due to early site rendering engines, like webber's dictates, THEREFORE,

• q. I ask, Does, E.G., Hugo and Pandoc then find the yaml anywhere in the file?
• • I'm wondering if this is now a conventional capability for site rendering scripts. I recall that pandoc does, but not at all sure about static html rendering engines in general or, Hugo in particular. I'd have to check that.

Finally, concerning the initial question of vaults, I've decided to take all vaults for technical notebooks out , and have only a 'Box.File' dir a 'pure zettlekasten' method, BUT,

• Addtionally a Box.In for clippings - a kind of staging area. I'll follow your tip and set the same 'special dirs' for all vaults, using full path.

Aside, The technical notebooks can handled outside telekasten , using telescope and also, integrate a ctag search for markdown syntax, in order to pick up subtitles in the longer documents. I use markdown folding fo r such files.
Some my notebooks are 'semi-technical' , or include dissertations and studies; ideally I'd like to incoporate some of that in the one zettle BOX.Files, but that will take considerable time; selecting files for break up, and introducing summary files. First I have to continue with the present 270+ in the BOX.Files, getting them into better shape, some more to atomise and, place links and summaries. It'll take about a month. Fortunately the 'split_md_05.py' (apparently made for Ulysees), which I discovered recently on Github, makes the splitting straightforward on markdown subtitles, and kindly offers a summary file with inclusions to the atoms created.

Cheers, John

[lambtho12]

Perhaps I could modify it to launch a new note invoking telekrasten's new_note in nvim with its prompt for note title?

There is probably a way to call nvim then directly pass :Telekasten new_note to it from the command line, but I do not know how

Do you choose to use the yaml template for atomic zettles in a vault, or only for larger concatenated compositions drawn or publication? AND IF for atomic zettles too, What purpose other than publication does the yaml serve, given that creation and modification dates are accessible in file metadata if at all needed at any time, and such dates not needed for note selection and manipulation?

I do not rely too much on YAML. It is mostly a question of being future-proof should I use an other system at some point. My only real use for it is to put tags neatly there instead of in the rest of the document.

I ask, Does, E.G., Hugo and Pandoc then find the yaml anywhere in the file? I'm wondering if this is now a conventional capability for site rendering scripts. I recall that pandoc does, but not at all sure about static html rendering engines in general or, Hugo in particular.

No idea, as I do not use it currently. I prefer to put it at the bottom so it is not in the way. If at some point in the future I need to rely more on YAML and it needs to be on top, I can hack a quick script to skim over all notes and move it to the top in no time.