FR: add templating language to include relevant date in template

[ksdavidc]

I would like to know more about the templates.

In the core daily notes plugin one can use template variables such as:

Variable	Description
{{title}}	Title of the active note.
{{date}}	Today's date. Default format: YYYY-MM-DD.
{{time}}	Current time. Default format: HH:mm.

If I put {{date:YYYY MM DD -- dddd, MMMM Do, YYYY}} into the template, I get: 2024 11 25 -- Monday, November 25th, 2024

If I try to use that for daily note calendar, I get the original {{date:YYYY MM DD -- dddd, MMMM Do, YYYY}}, not the interpreted result.

Does your template have a similar function?

[bartkessels]

Hello, right now the plugin is extremely simple when creating a new file. It just copies the template-file you've specified in the settings. But I like the idea of having variables in the template for the date and time, so I'm going to incorporate that.

As for the {{title}} variable, in which cases would you like to use that? (just curious about your use-case). And do I understand it correctly that if you create a daily note with the name template yyyy-MM-dd you want the {{title}} to reflect that value, thus 2024-11-27?

Thanks for your feedback and I'll start working on adding variable-support to the plugin, haven't thought about that myself. Feel free to suggest more features you're missing, or bugs you've encountered! And for now, keep enjoying the plugin when this features is implemented I'll let you know!

[ksdavidc]

That's great.

I don't actually use {title}, but it is an option in Obsidian's standard template language. I can imagine a way it is intended to be used is as follows. If one were working, say, on file "Cool Thing", one could create a daily note related to "Cool Thing", with file name YYYY MM DD, but with a first Heading: ## About Cool Thing using the formatting ## About {title}

On a related matter, let me explain my use case. I don't use the Daily Notes as a diary, like it seems it usually is, but for planning future events. This means the date I create the file is not related to the date of the file (the event), so it doesn't show up in that day's list.

This makes me think it would be nice if there were an option for the given day's file to appear, as well as the files created on that day, in the file list.

Also, it would be nice if there were an indicator to show that there are files on a given day.

Lastly, some css to make it look a little nicer:

.workspace-leaf-content[data-type="daily-note-calendar"] table {
    width: 100%;
}

.workspace-leaf-content[data-type="daily-note-calendar"] div.header span.title {
    margin: auto;
}

It could probably use some improvements, but I am not an expert at css.

[bartkessels]

Thanks for your reply, that sounds good. It's a bit more complicated, but I still think that it is a good addition. Right now I'm trying something to make it work but it's going to take a little while.

As for your CSS, thanks! Right now I'm creating a new release to add it (version 1.6.2), and I'll mention you in the release! I'm not that good at CSS, so I don't see anything wrong with it either, but if anyone comes across with CSS knowledge I'd be happy to hear them out.

[bartkessels]

Hello, in the latest PR I've added support for the following variables

Add support for the following variables

Variable	Template	Description
{{date:yyyy-MM-ddd}}	Any date format, only dates are properly supported. The time may be incorrect	This uses the date based on the date you clicked in the calendar
{{today:yyyy-MM-dd HH:mm}}	Any date or time format.	This will always be the current day and time of creation of the note.
{{title}}	Not supported	Get's the title of the active file before you clicked on date in the calendar.

Is this what you had in mind as well? If so, I'm going to create a new release.

[ksdavidc]

Absolutely, for me as well. That's awesome.

Any hope of an indicator for days that have notes? I know that kind of thing depends on what your algorithm naturally exposes, but it would be visually very nice.

Since you have been so giving, I am going to tell you something that I am fully aware is more than likely way beyond the scope of your plugin, but it would be a dream: If the calendar displayed not as a monthly "paper" calendar, but as a scrolling/scrollable calendar. This seems much more natural to me, and allows me to see the weeks before and after the currently in focus date, regardless of the week they fall in in the month. I know, probably beyond what you envisioned, and may be very difficult or near impossible to implement smoothly, but that would chef's kiss for me.

At any rate, don't let that sound like I am not thoroughly pleased with this, 'cause I am. I am looking forward to seeing the release. Thank you!

[bartkessels]

Good to hear that this will work, tomorrow I'll create the release to incorporate the variables. As for an indicator on the calendar to display which dates have a note, I'll be adding that in the release after the variables-release (as it was already asked in #34).

As far as the scrolling of the calendar goes, I haven't thought about that but it sounds like a nice feature to have. It will give you a bit more context about the previous and next months dates. I'll be adding that after the notes indicator. So for now I don't know exactly when that's going to be.

Again thanks for your initial suggestion and your new suggestions and keep them coming!

P.s. I'll leave the issue open until the scrolling calendar feature has been released.

[ksdavidc]

I feel I should say, in light of your amenability to suggestion, please do note that I am in no way trying to hijack you. Feel completely free at any time to reject, postpone, amend, neglect, them in any way you please. Take your time, and I hope you don't feel any compulsion, as I intend none. I was giving you food for thought, and I am already grateful for what you'd done even before you started adding things. I use a lot of plugins and I notice things that are missing, but often they are missing for a good reason, such as they would be impractical to implement. I don't want to have sent you down a rabbit hole. It's easy to imagine the moon, but it's better to keep your feet on earth. Pick your battles wisely.

[bartkessels]

Oh no, I don't feel hijacked or anything. I always like to hear feedback to make the plugin a lot better. And by hearing multiple people suggesting new features allows me to think of the plugin in whole other ways, and this extends to other software-products as well. And I do like the idea of having a scrolling calendar instead of the buttons to navigate to another month, because that allows me to see the weeks surrounding a month as well, which is something that I'm missing myself.

As for the variables, the release 1.7.0 has just finished building. So in the next couple of minutes/hours you should be able to update the plugin and use the variables in your notes!

Again thanks for this suggestion as it's something I need as well 😂

[ksdavidc]

Okay, I updated and it is sort of working. If I click on a day that is in a MONTH that does not have notes in it already, then it produces a file correctly, templates working fine.

However, if I click in a month that has diary entries, any diary entries, and click on a day that DOES have a diary note I get this error:

plugin:daily-note-calendar:13 Uncaught (in promise) 
Error: File does not exist: Class Notes/2024/12-December/2024 12 06 -- Friday, December 6th, 2024.md. 
at Dn.openFile (plugin:daily-note-calendar:13:73936) 
at kn.tryOpenFile (plugin:daily-note-calendar:13:73410) 
at async Bt.process (plugin:daily-note-calendar:13:107006)

(this file DOES exist.)
No file is opened.

If I click on a date that does NOT have a diary note, I get:

app.js:1 Uncaught (in promise) Error: Folder already exists.
    at t.<anonymous> (app.js:1:733572)
    at app.js:1:237228
    at Object.next (app.js:1:237333)
    at a (app.js:1:236051)

and no file is opened.

Again, it appears that months without entries do work fine.

Some of this may be likely due to my unusual folder structure for my notes:

yyyy/MM-MMMM/yyyy MM dd '--' EEEE, MMMM do, yyyy
for example:
/2025/01-January/2025 01 02 -- Thursday, January 2nd, 2025

( I also tried LL-LLLL instead of MM-MMMM since I don't really understand the distinction, but anyway it didn't help)

(in standard Obsidian notation: YYYY/MM-MMMM/YYYY MM DD -- dddd, MMMM Do, YYYY
I believe I have converted it right.)

This is my template.

```toc
```


## {{date:yyyy MM dd '--' EEEE, MMMM do, yyyy}} 

## Plan

## Notes

```

[ksdavidc]

Ah yes, and the strangest part is that IF I do start a new month, then I CAN create new entries and see current entries as should be. It seems it is not expecting there to have ALREADY been folders/entries, but when installing into a vault that already has entries, this would naturally be the case.

[ksdavidc]

I've tried to recreate it in a sandbox vault but haven't quite been able to reproduce it.

I did find out that if I delete the new files in the new month, I then become unable to add them back again UNTIL I RESTART.

[ksdavidc]

Okay. Riddle me this. Inside this archive are two nearly identical vaults.

One I created by taking my non-working vault and eliminating everything inessential.
The other I created from the ground up and checking it works along the way.

They have the same files, the same plugins (as they were copy and pasted -- can't remember which direction, shouldn't matter.), at least as far as I can tell. Most of the plugins are disabled. The settings for the daily notes are identical, as far I can tell. There may be some other settings here or there that I missed??

One of them creates daily notes, the other doesn't, in the way I described above.

I could have reduced even more, but I will leave that pleasure for others. The point is they should behave identically....but don't.

Good luck.

Daily note calendar test vaults.zip

(PS...I mean, of course, if you are inclined. Presented here for your amusement only.)

[bartkessels]

Hmmmm that's an interesting issue, do you perhaps have a folder with the same name as a note? Because maybe that might be the problem. I've tried recreating the issue but haven't succeeded (yet), I also don't understand why you get the File does not exist exception as I can't place it. I thought that it might be because of the {{title}} variable, which tries to read the current file name but that doesn't seem to be the issue either.

Thanks for the test vault, I'm going to try to recreate the issue and hopefully fix it.

[bartkessels]

Okay, I think I found the issue. Your settings for the daily notes folder is Class Notes but the actual folder is named Class notes (lower-case n). When the plugin is trying to open note it checks if the folder and the file both exist, but in the current check, it ignores the casing. So, the plugin thinks the file Class Notes/x exists but it actually doesn't.

I'm going to try and see if I can find a way to ignore the casing of the folder/file when opening because it doesn't really matter all that much.

On a side note, you can also change your settings so the path is in the folder setting instead of in the name template setting (both settings allow you to use custom date-formatting rules).

Setting	Value
Daily note name template	yyyy MM dd '--' EEEE, MMMM do, yyyy
Daily notes folder	'Class notes'/yyyy/MM-MMMM

It's not a big deal, it does behave the same. But it might be a little bit easier to read the settings yourself.

[ksdavidc]

Brilliant, my friend, brilliant.

IMHUUO I am out on a limb here, but is ignoring casing the right way? Obviously something cares about casing, hence the error.¹ Wouldn't not ignoring casing be the safer bet, and perhaps easier since it is one less thing to track? Ignoring casing is user-friendly, but also people, and by people I mean ME, should be more careful about casing. I know there are a lot of cases² where code ignores casing for user-friendliness, or user unfriendliness³ (I'm looking at you Dataview⁴), but too much sloppiness in this regard can blur the useful distinction of case to a fault. Maybe ignoring is okay in this case, but I think it would have helped me as well, in this case, if the error message has been more explicit about which folder it is that already exists. I think a note to users to be careful about Case (since most people who are not me are and should be careful of it) would probably be simpler to implement than inserting code (and more possibility for error) that undoes user input where there may be a reason something else wants to observe case here. Users should have no reason to EXPECT you to ignore case. End OF uninformed unsolicited OpiNioN.

On the other hand, thank you so much. It was right there in front of me, so to speak. Sorry to have taken your time for such a silly, avoidable mistake on my part.

The placement of the path thing is cool, and I agree is sensible⁵ and user-friendly. In my case, I will stick to the first, if only because it mirrors what is in the Obsidian core Daily Note settings (despite the switch to date-fns). But it may grow on me.

P.S. more feature requests on the way.

Footnotes

1. I don't know your code, so I could be misinterpreting wildly. ↩

2. ha ha ↩

3. ah hyphens ↩

4. the whole this kind-of-problem Kind Of Problem irks me. ↩

5. especially since they are actually different types of data, in the two settings. Arguably, Obsidian should do the same. ↩

[bartkessels]

The problem preserving the casing is that, in the plugin you can only choose to ignore the case when checking if a folder/file exists. Let's say the folder Class Notes exists, but in the settings you've specified the folder Class notes. If you try to open a daily note, the plugin thinks the folder Class notes doesn't exist and tries to create it. However, in Obsidian, you can't have two folder-names that only differ in casing. Thus, if the plugin tries to create the folder it will inherently fail because Obsidian will say that the folder already exists.

Therefore, I thought that it might be easier to just ignore the case of the folder-path when creating a note. But that doesn't seem to work. Just like you said, failing with an error-message might be the best solution in this case where the error-message includes the folder path so the user can validate whether or not the path is correct.

[bartkessels]

In the next release (version 1.7.1), the error-handling has been improved in such a way that you can see what went wrong when opening or creating a note (including the complete file path). Hopefully this will help a lot, if not, I'm not sure how to fix this properly.

[ksdavidc]

I think this is the best that could be hoped for, since Obsidian is strict about casing. THANKS!