Daily notes, tasks, and templates

Jotura has three features that turn a folder of markdown files into something closer to a planner. Daily notes give you one file per calendar day, created for you in advance. The task rollup scans every note in the vault for markdown checklist items and collects them into one list. Templates give new notes a starting body, with a small set of variables substituted at creation time.

All three work on plain files. A daily note is an ordinary .md file in an ordinary folder, a task is an ordinary markdown checkbox line, and a template is a markdown file stored inside the vault. Nothing here uses a database or a proprietary format, so anything you build with these features stays readable in any other editor.

Daily notes

Where a daily note lives

Every daily note has a path derived from its date. The folder comes from a setting, then a four-digit year folder, then a two-digit month folder, then a file named for the full date:

Daily/2026/08/2026-08-30.md

The desktop app uses Daily as the folder name. That value lives in the dailyNotesFolder field of settings.json and has no control in the Settings window, so changing it means editing the settings file by hand. See the Settings reference for where settings.json lives on each platform.

The date the app uses is your local date, read from the system clock. The clock is re-checked just after local midnight and again whenever the window regains focus or becomes visible. An app left open overnight therefore rolls over to the new day on its own.

Daily notes are ordinary notes, so they sync across devices like everything else if you have Sync. Sync is the one paid part of Jotura, priced on the pricing page.

Turning daily notes on

Daily notes are on by default. The Settings window has a Daily Notes section with three rows, and the lower two disappear entirely when the first is off.

Setting	What it does	Field	Default
Enable daily notes	Shows the calendar pane in the right sidebar and pre-creates notes for upcoming days.	dailyNotesEnabled	true
Auto-create window	How many upcoming days to pre-create. Accepts 1 to 60.	dailyNotesAutoCreateDays	14
Task window	How far back the task rollup looks. Accepts 1 to 365 days. Covered in detail below.	taskListWindowDays	30

The folder itself is the fourth field, dailyNotesFolder, and it has no row in that section because it has no control anywhere in the app.

Turning daily notes off hides the calendar pane and stops the pre-creation pass. It does not delete anything that already exists, and the task rollup keeps working because it is not gated on this setting.

When a daily note gets created

The pre-creation pass creates today’s note plus the next dailyNotesAutoCreateDays minus one days, so the default of 14 covers today and the following 13 days. It stops quietly at the first failure rather than reporting an error. Four things trigger it:

1. Opening a vault.
2. The local date rolling over while the app is open, which is what makes an overnight session create a fresh batch of empty files.
3. Switching daily notes on in Settings.
4. Changing the Auto-create window value.

The pass runs at most once per vault per day within a single app session. That guard is held in memory, so restarting the app lets it run again for the same day.

Clicking any cell in the calendar creates that day’s note if it is missing, then opens it. This includes the greyed-out cells for the previous and next month that fill out the grid, so browsing the calendar and clicking around will leave empty files behind. The Today button does the same thing for the current date and also returns the grid to the current month.

A newly created daily note is empty. The desktop app does not apply a template to daily notes. If you want a daily note to start from a template, create it with the command-line tool instead, which is described below.

The calendar pane

The calendar is one of the panes in the right sidebar, which is hidden until a vault is open and starts collapsed. Collapsed, it shows a narrow rail of buttons labeled Open calendar, Open tasks, and Open history. Expanded, it shows Calendar, Tasks, and History as a row of tabs with a collapse button beside them. Turning daily notes off removes the calendar from both places: the rail loses its Open calendar button, the tab row loses its Calendar tab, and the pane falls back to Tasks.

The right sidebar is resized by dragging its edge with the mouse, between 200 and 500 pixels wide. There is no keyboard equivalent for that drag.

The grid is a fixed 42 cells starting on Sunday, with Previous month and Next month buttons and a Today button. Each cell carries at most one mark. A day with open tasks shows the count, capped at 9+. A day that has a daily note but no open tasks shows a dot instead. Adjacent-month cells never show either mark, even when the note exists.

The counts come from the same windowed list the Tasks pane uses, so the Task window setting applies to them. Browse back to a month older than that window and you see dots but no counts, even on days whose notes are full of unticked boxes. Future months are unaffected, because future-dated tasks always pass the window.

The History tab opens version history for the note in the active tab, and it is disabled unless that tab holds a markdown note.

Daily notes from the command line

The jotura today command is the command-line equivalent. It creates the note if it is missing, then prints the path.

jotura today

jotura today --json

Flag	What it does	Notes
--read	Prints the note’s contents instead of its path.	Takes precedence over --append. Passing both reads the note and appends nothing.
--append [TEXT]	Appends text to the note, or reads standard input when no value is given.	Newlines are normalized around the appended block. Because a bare --append is the signal to read standard input, you cannot append a literally empty string.
--date YYYY-MM-DD	Operates on a specific date instead of today.	A malformed or impossible date exits 9.
--folder FOLDER	The daily-notes folder.	See the note on defaults below.
--template NAME	Initializes a newly created daily note from a named template.	Applied only at creation. An existing note is never re-templated.

Output depends on the form, and two of the three forms print JSON whether or not you pass --json.

Form	JSON shape	Without --json
Bare, --folder, --date	{ "path", "hash", "created" }	Prints the path.
--read	{ "path", "hash", "body", "frontmatter", "created" }	Prints the file’s contents, frontmatter block included. An empty note prints nothing.
--append	{ "path", "hash", "created", "appended": true }	Prints the same JSON. This form has no text mode.

The created field is the only way a caller learns whether the note already existed, which is usually the question after asking for today’s note. Note that body and frontmatter are split only in the JSON form; text mode never separates them.

jotura today --date 2026-08-30 --read

jotura today --append "- [ ] call the bank @due(2026-09-02)"

jotura today --folder Journal --template daily-review

Two differences from the desktop app are worth knowing. First, jotura today defaults to the date in UTC while the desktop app uses your local date, so the two can disagree for a few hours either side of midnight depending on your time zone. Second, the command never reads the desktop app’s dailyNotesFolder setting.

That second point matters if you have changed the setting. The command’s help text says the folder defaults to daily, but the real default scans the vault root for any directory whose name matches daily case-insensitively and reuses it. An exact-case daily wins if it exists, otherwise the first existing variant is used, and only when nothing matches does it fall back to the literal daily. This exists so a bare jotura today cannot create a second folder differing from Daily only by case, which would split into two folders on a case-sensitive device at sync time.

So the two surfaces agree only because the desktop default happens to be Daily. If you set dailyNotesFolder to something else, such as Journal or notes/daily, pass --folder on every jotura today call. Without it the command silently creates its own daily/ folder, which the calendar and the task rollup’s date inference both ignore.

The append path reads the file, then writes with a compare-and-set guard against the hash it just read. A concurrent edit from the desktop app between those two steps exits 2. Exit codes are listed in full in Exit codes and JSON output.

The task rollup

Writing a task in the editor

The rollup reads checklist lines, and the editor writes them. Each gesture below needs editor focus, and Mod means Cmd on macOS and Ctrl on Windows and Linux. The editor covers the surrounding list behavior in depth.

Gesture	Effect
Mod-Shift-9	Turns the current block into a task list item.
Type [ ] at the start of an empty paragraph	Starts a task list. [x] starts it ticked.
Type - first, then [ ] or [x]	Converts the bullet item you just started into a task item.
Type / at the start of an empty paragraph, then pick Task list	Same as the chord, from the slash menu.
Tab and Shift-Tab	Indent and outdent the task item, which is how nested checklists are made.
Enter on an empty task item	Leaves the list in one press, however deeply nested the item was.

The second and third rows are two different gestures for the same result. The second is the stock behavior; the third exists because typing - and then [ ] did nothing without a Jotura-specific rule.

Saved to disk, all of this becomes ordinary GitHub-flavored markdown: - [ ] open task and - [x] done task, with two spaces of indentation per nesting level.

What counts as a task

The rollup scans line by line. A line becomes a task when it starts, after any leading whitespace, with a list marker followed by a checkbox marker. The checkbox marker is the three characters after the list marker, and it must be exactly [ ], [x], or [X].

Line	Result
- [ ] draft the brief	Open task
* [ ] draft the brief	Open task
+ [ ] draft the brief	Open task
1. [ ] draft the brief	Open task
1) [ ] draft the brief	Open task
- [x] draft the brief	Completed task
- [X] draft the brief	Completed task
- [] draft the brief	Not a task, because the three characters after the marker are [] , not [ ]
[ ] draft the brief	Not a task, because a list marker is required

A bullet marker must be followed by a space. An ordered marker accepts a space or a tab after its . or ). Leading whitespace is trimmed before the check, so indented and nested checklist items are collected the same as top-level ones. The task’s text is everything after the checkbox marker, kept exactly as written.

The scan covers every file in the vault whose extension is .md or .markdown, compared case-insensitively, so .MD and .Markdown are included too. Notes inside folders shared with you are scanned like any other. Anything whose own name starts with a dot is skipped, folder or file, which is how the vault’s internal directory, your templates, and a file like .notes.md all stay out of the list. The scan has no awareness of fenced code blocks, so a checkbox line inside a code fence is collected as a real task.

How a task gets a date

A task can pick up a date two ways, and the rollup keeps both plus the one it actually uses.

The first is an explicit due date written inline as @due(YYYY-MM-DD). The scanner takes the first @due( in the line and reads up to the closing bracket. If what it finds is not exactly ten characters long, the marker is ignored and the task simply has no due date. The @due(...) text stays in the task’s text and is shown as part of the task in the sidebar.

The second is inferred from the file’s path. A note sitting at the exact daily-note path shape contributes its date to every task in it. That shape is the daily folder, then a four-character year, then a two-character month, then a ten-character date file name. So every checkbox in Daily/2026/08/2026-08-30.md is dated 30 August 2026 without any markup.

The date the interface uses is the due date when there is one, and the daily-note date otherwise. A task in a daily note with a @due marker is filed under the due date, not the day it was written.

One caveat sits on the due-date parser. A marker that is ten characters long but not a real date, such as @due(2026-13-01), makes the scan of that note fail. The failure is logged as a warning and every task in that note is dropped from the list, rather than an error being shown. If a note’s tasks vanish unexpectedly, check its @due markers first.

Which tasks appear

The list is not the whole vault. A task is included when any one of three conditions holds, using the Task window setting as its number of days.

1. Its effective date is later than today. Future-dated tasks always appear, however far ahead they are and however old the file is.
2. Its note is a daily note dated on or after the start of the window, where the window covers today and the preceding days back to taskListWindowDays minus one.
3. Its note was modified within the last taskListWindowDays days.

The practical effect is that recent work and everything still ahead of you shows up. An untouched note from last year does not resurface just because it has an unticked box in it. Raising the Task window setting widens the recent-file and daily-note reach without changing the rule for future-dated tasks.

The Tasks pane

Tasks is the second pane in the right sidebar. Three tiles across the top show the number of open tasks, the number of completed tasks, and a completion percentage labeled past {N}d, where the number is the Task window setting. That percentage is calculated over the tasks that are not future-dated, meaning those with no date at all and those dated today or earlier, so future work does not drag the figure down. A refresh button sits beside the tiles, and the list also refreshes on its own whenever a file change reaches the app.

Below the tiles is a filter box labeled Filter tasks. It matches your text against four things at once: the task text, the note’s title, the note’s path, and the effective date. Typing a note name or a date therefore narrows the list as readily as typing part of a task. The three tiles are computed from the unfiltered list, so filtering never changes the numbers above the box.

The results are grouped into five fixed sections, and a section with nothing in it is hidden entirely.

Section	What it holds
Overdue	Open tasks whose effective date is earlier than today.
Today	Open tasks whose effective date is today.
Upcoming	Open tasks whose effective date is later than today.
No date	Open tasks with no due date and no daily-note date.
Done	Every completed task in the list, whatever its date.

Within a section, tasks are ordered by effective date, then by note title, then by line number. Each row shows the task text, the note’s title, and the month and day formatted for your locale. Clicking the text opens the note. Clicking the circle to its left toggles the checkbox.

The pane has three other states. It reads Loading tasks... while a load is in flight and No tasks found. when every section is empty. Any failure, including a refused toggle, appears as an alert row between the filter box and the list.

Toggling a task from the sidebar

Toggling rewrites only the three characters of the checkbox marker in the file, leaving indentation, the task text, and the line ending exactly as they were.

Four things can refuse the write, and each leaves the file untouched. If the note is open in a tab with unsaved changes, you get Save the open note before toggling this task from the sidebar. If the line’s text on disk no longer matches the text the sidebar is showing, the write is rejected as a conflict. If the file has grown or shrunk so the line number no longer exists, you get task line was not found. If that line is still there but is no longer a checklist line, you get line is no longer a task. The last three are the normal outcome of editing a note elsewhere and then clicking a stale sidebar row, and refreshing the pane clears them.

A task inside a folder shared with you as a viewer cannot be toggled at all. That write is refused with this file is in a read-only shared folder, the same guard that applies to every other edit there. See Sync and sharing for how roles work.

When the toggle succeeds and the note is open in a clean tab, that tab reloads so the editor and the sidebar agree.

Tasks from the command line

The command-line tool has no dedicated task command. The equivalent is a regex search with jotura grep, which can be narrowed to the daily folder with a glob:

jotura grep "\[ \] " --include "Daily/**" --json

That returns matching lines with their paths and line numbers, which is enough to read or edit them with the ordinary editing commands. Note that grep has no understanding of due dates or the task window, so it returns every match in the files you point it at.

Templates

Where templates live

A template is a markdown file under .jotura/templates/ inside the vault. A template named meeting is the file .jotura/templates/meeting.md. Nested names are allowed, so work/standup is .jotura/templates/work/standup.md, and the name you use everywhere else is the path with the .md removed. Names are listed in sorted order.

Because that directory is dot-prefixed, templates are deliberately invisible to the rest of the app. They do not appear in the file tree, they are not indexed for search, they are skipped by backlink, task, and grep walks, and they are not synced. A template you create on one machine has to be recreated on your other machines, even with Sync enabled.

Creating and editing templates in the app

Templates are managed in the Settings window, in a collapsed sub-group called Templates inside the Editor section. The group is inert until a vault is open, showing No vault open instead of the list.

Each existing template gets a row with Edit and Delete buttons, and a New template… button opens a blank editor. That editor has a name field, stored as .jotura/templates/<name>.md, and a plain textarea for the body. The textarea’s placeholder shows a two-line example using the {{title}} and {{date}} variables. Save template writes the file, and Cancel discards the draft.

Renaming is not supported. When you edit an existing template the name field is fixed and the helper text tells you to create a new template instead. Saving an existing name overwrites that template. Delete asks for confirmation with Delete the template "<name>"? Existing notes are not affected., which is accurate: templates are copied at creation time and notes never refer back to them.

Creating a note from a template

There are two entry points, and neither has a keyboard shortcut. The command palette lists New Note from Template…, and the file tree’s right-click menu on a folder offers New note from template. Both open the same two-step picker. The palette itself is covered in Keyboard shortcuts.

The first step lists your templates with a filter box. The filter is a plain substring match on the name rather than a fuzzy match, so typing stand finds work/standup but typing wsu does not. Arrow keys move the selection without wrapping at either end, and Enter picks the highlighted template. Two empty states can appear: No templates yet. Create one in Settings. when you have none saved, and No templates match. when the filter excludes them all.

The second step asks for the new note’s name, pre-filled with the template’s base name, so work/standup offers standup. Enter creates the note, and .md is appended when the name does not already end in it. Back returns to the template list. Escape closes the whole picker rather than stepping back one page, and so does clicking the backdrop outside the dialog.

The note is created in the folder you right-clicked. Opened from the command palette there is no such folder, so the note lands beside the note in the active tab. With no note open, it lands in the vault root. If a file with that name already exists, the new note gets a numbered suffix before the extension, so standup.md becomes standup (2).md.

What gets copied, and the variables

Applying a template copies the file whole, frontmatter included. This is true on both surfaces and both commands, so a template that starts with a YAML block gives every note made from it that same block. Seeding a template from an existing note with jotura templates create --from is the easy way to set that up.

Four variables are substituted during the copy. Substitution is a plain text replacement of every occurrence, with no escaping mechanism, so there is no way to write a literal {{date}} into a template and have it survive.

Variable	Expands to	Notes
{{date}}	The current date as YYYY-MM-DD	In UTC, not your local time zone.
{{datetime}}	The current timestamp as YYYY-MM-DDTHH:MM:SSZ	In UTC.
{{filename}}	The new note’s file name without its extension	meeting-notes.md gives meeting-notes.
{{title}}	The file name stem, title-cased	Only hyphens and underscores are word boundaries.

The title-casing rule is narrower than it looks. Hyphens and underscores become spaces and the letter after each one is capitalized, so meeting-notes gives Meeting Notes and daily_review gives Daily Review. A space in the file name is not a boundary, so meeting notes gives Meeting notes. Since note names with spaces are common, expect that second form more often than the first.

There are exactly four variables. There is no {{time}}, no custom variables, no conditionals, and no way to add more. The stem used for {{filename}} and {{title}} is the final name of the note, so a note that received a numbered suffix gets that suffix in its title.

Templates from the command line

The same templates are readable and writable from the command line, and the templates subtree is the one documented exception to the rule that .jotura/ paths are off limits.

jotura templates list --json

jotura templates show meeting

jotura templates create standup --from inbox/standup-draft.md

Without --from, templates create reads the template body from standard input until end of file:

jotura templates create standup < standup.md

Command	Arguments	Output and caveats
jotura templates list	none	Respects --json: { "templates": [...] } as JSON, one name per line as text.
jotura templates show <NAME>	template name	Respects --json: { "name", "path", "frontmatter", "body" } as JSON, the raw content including frontmatter as text. A missing template exits 3.
jotura templates create <NAME>	template name, optional --from <PATH>	Always emits JSON, { "name", "path" }, with or without --json. Seeds from an existing note including its frontmatter, or from standard input. An existing name exits 9 rather than overwriting.
jotura templates delete <NAME>	template name	Always emits JSON, { "name", "deleted": true }.

One behavior differs between the two surfaces. Saving over an existing name in the Settings window overwrites the template, while jotura templates create refuses an existing name and exits 9, telling you to delete it first or pick a different name.

To create a note from a template, pass --template to jotura create:

jotura create projects alpha --template meeting --json

The template’s content is read, its variables are substituted, and the result is written after the empty file is created. A template that does not exist exits 3. create always emits JSON, and its other flags, the .md suffixing rule, and the collision behavior are covered in Creating, moving, and deleting.

Settings summary

Every setting that affects the features on this page, with the field name used in settings.json.

Setting	Field	Default	Accepted values
Enable daily notes	dailyNotesEnabled	true	on or off
Auto-create window	dailyNotesAutoCreateDays	14	1 to 60
Task window	taskListWindowDays	30	1 to 365
Daily-notes folder (no control in the app)	dailyNotesFolder	"Daily"	Any folder path with no .. anywhere in it

The folder value is trimmed of surrounding whitespace and slashes before use, and an empty value is rejected. Because there is no UI for it, a bad value is easy to introduce and does not fall back to Daily: daily-note operations fail instead, so the calendar stops opening days.

Templates have no settings fields at all. They are files, and the Templates group in Settings is a file editor rather than a preference. If you are new to the app, Getting started covers opening a vault, which everything here depends on. Troubleshooting covers what to do when a file written to disk does not appear where you expect it.