Bases (saved queries over your notes)

A Base (.lnq, under File → New → New Base) is a saved query over your notes: filter by type and by properties and see the result as a table or a board. A Base stores no data at all — the rows are your .md notes and the source of truth for each cell is the note's frontmatter. Deleting a .lnq loses no note.

Editing a cell writes to the note. In the table, changing a property rewrites only that line of the file's frontmatter. In the board, dragging a card from one column to another writes the new value of the grouping property (for example moving from reading to read).

Table, board and filter

Filter, grouping and columns. A cell opens for editing with a double click or F2. In the Filter dialog, choose between All conditions (AND) and Any condition (OR); the operator is shown in words (is, contains, is empty…) and the button next to each condition removes it. On the board, the Group by selector picks the property of the columns — with no choice, the Base suggests status. The width you drag on a table column is saved in the Base, and Export CSV takes what the table shows, with the quick filter applied. Keys with accents (situação:) and lists (authors: [Ana, Bia], or one item per line) become columns; editing a list in the cell writes it back as a list, in the same form. A property that is a nested block is shown but cannot be edited from the Base — the bar says why.

Cells by type. Each column is drawn by the type of the property: a checkbox you tick with one click, pills for lists and option lists, dates in your language’s format, numbers aligned to the right and the title highlighted. The type comes from the declared schema and, without it, from what the notes already use; an option list opens a picker and a date, a calendar. Click the header to sort (again, to reverse) — the sort is saved in the Base, as with the Sort button. Drag the header to change the column order; right-click it to rename the column (only the display name — the note’s key does not change) or hide it. The filter conditions show up as tags below the bar: click to edit, × to remove. When nothing shows up, the table says why. On the board, each card shows the properties chosen in Card properties, each column shows how many cards it has, and declared options become columns even when empty. Right-click a row to open the note — also beside. With the note open in a tab, the edit goes to the tab: if it had no changes, it is saved right away; if it had, the change stays there until you save.

Several views and totals. The + button next to the tabs creates a new view of the same Base — Table, Board, Gallery, List or Calendar — which starts with the current columns and sort and from then on keeps its own. The filter is the Base’s, the same for all. Right-click a tab to rename, duplicate or delete the view (the first one cannot be deleted). In the gallery, choose in Cover the property that points to an image in the folder (cover: photo.png or ![[photo.png]]); in the list, the properties come on the same line as the title; in the calendar, each note shows up on the day of the Date field, and dragging it to another day writes the new date. The table footer shows totals: click below a column to choose sum, average, minimum, maximum, median, standard deviation, the earliest or latest date, the checked ones, the filled ones or the unique values — only the functions that fit the column’s type. The total follows the quick filter. An older version of the app that opens the Base sees only the first view. Right-clicking a tab also changes the layout of the view. The tabs sit on their own row, with the count and the ⋯ menu; below them are the actions and the search, and in a narrow tab the buttons show only their icon, with the name in the tooltip.

Formulas and Obsidian Bases. In Properties → New formula... you create a calculated property, which becomes a column like any other and is referred to as formula.name — for example rating * 2, if(read, "✓", ""), (due - today()).days or file.hasTag("book"). The value is calculated on the fly and is never written to the notes; right-click the header to edit the formula, and an error shows up with its position. An Obsidian .base file is imported by right-clicking it in the tree and choosing Import as Base (.lnq): a Base is created next to it with the filters, views, formulas, sort and totals, the .base stays where it is, and whatever has no equivalent is listed at the end. A filter that is an expression becomes an expression condition, shown as a tag with ƒ — an older version of the app ignores it and shows more notes, never fewer. Through MCP, query_notes with base (and view) gives the same answer as the screen.

Embedding a Base in a note. On a line of its own, ![[reading.lnq]] shows the Base as a read-only table in reading mode, in the formatted editor and on export; ![[reading.lnq#Read]] shows the Read view (a view without a name answers to its tab name, such as Table). The name at the top opens the Base, the title of each row opens the note, and past 50 rows the table says how many were left out. If the view groups (the table with Group, or the board), there is one table per group, with each group's name and count in bold, in the same order as on screen. It is as current as the note index, which the window updates when the folder is opened. In formulas and filters, this is the note the Base is embedded in (or the Base itself, when opened): project == this.file.name makes one Base serve every project, and file.hasLink(this.file) lists the notes that link to this one. Lists accept map, filter and reduce — for example authors.map(value.upper()), ratings.filter(value > 7) and prices.reduce(acc + value, 0), with value, index and acc — as well as containsAll, containsAny, flat and slice.

Grouping, wrapping, freezing and coloring the table. In the table, Group splits the rows by a property, with a header per group showing how many notes it has; clicking the header collapses or expands the group, and collapsing only affects the screen — it does not change the Base, the count, the totals or the CSV. Display holds Wrap text in cells (the row grows to show the whole text), Freeze the first column (it stays put while the others scroll sideways) and Row colors...: each rule is an expression, such as status == "late" or due < today(), and a color; the first true rule colors the row, in a tone that follows the light and the dark theme. All of this is saved per view, and an older version of the app simply shows the table without these options.

Timeline, option colors and cover. The Timeline view draws one bar per note, from the Start field to the End field (with no end, a single day), with today marked and the scale in days, weeks or months; dragging a bar moves both dates by the same number of days and writes them to the note, and the bar color follows the row colors. In the types editor, Option colors... gives a color to each value of an Option list: it shows in the table pill, on the cards and as a dot in the board column header. In the gallery, the cover can be the First image in the note, with no property needed for it.

Properties, schema and Git

Each note declares its properties in the frontmatter (type, status, author…). Use the note's Properties side panel to edit them as typed fields (text, number, date, checkbox) instead of raw YAML — see Markdown notes.

The .lnq file is NDJSON (one record per line), designed for Git: two machines can edit the same Base in parallel — one adds a column, the other tweaks a filter — and the merge keeps both changes without conflict.

Declared schema (optional). By default LightNote infers each type's fields from what your notes already use — you don't have to declare anything. When you want to pin the schema down, open Tools → Note types... (or the gear button on the note's Properties side bar): declare each type's fields, their data type (text, number, date, checkbox, option list) and a default template. With a schema, an option list field becomes a drop-down of the allowed values, declared fields show up in the Base's column and filter pickers even before any note uses them, and the Apply type template button drops in the note's skeleton. The schema lives in .lightnote/types.ndjson — mergeable NDJSON, versioned in Git along with your notes; deleting it changes no note, it just goes back to inference.

Relative dates in the filter. In the value of a condition you can write terms like today, yesterday, tomorrow, 7 days ago and in 2 weeks (also 3 months ago, in 1 week). With them, due = today and due < today (overdue) still hold tomorrow — before, you could only type the day's date by hand, and the saved query aged out in 24 h. The value is always a point in time, and the range comes from composing it with the operator: modified > 7 days ago means "touched this week". A note with no readable date in that field matches no date comparison, not even the negative one. An ISO date typed by hand (2026-09-01) still works as text.

The index runs in the background. The Base and Tools → Query notes (SQL) scan your notes before showing the result — a stat on every file plus reading the ones that changed since last time. That now happens off the window: the Base opens right away saying Indexing the notes… in its bar and fills in when the scan ends; the Reindex button stays disabled meanwhile, because a second scan of the same folder would gain nothing.

Task fields

Task fields. Each task in a task board (.lnt) has a note, and that note shows up in a Base with the board's fields: task.status, task.column, task.done, task.due, task.start, task.end, task.completed, task.priority, task.progress, task.effort, task.tags, task.checklist, task.archived, task.board. In the table, the header shows the field name (Status, Due date…), and the technical name is in the tooltip and in the Properties menu. task.done is true in the last Kanban column, task.priority shows the priority name, as on the board (from Low to Urgent, empty when there is none) — sorting and filtering use the stored number, from 1 to 4 and task.checklist shows done/total items. They only appear in the pickers when the folder has a board, and they are read-only: the board is the source, and the note never gets a copy in its frontmatter — so dragging a card on the Kanban never leaves the two disagreeing. To change the status, use the task board; on the Base's board, grouping by a task. field shows the columns but does not accept drops. For a task with a relative start, task.start is empty, because that date is only computed while the board is open. A status you write yourself in the note's frontmatter stays yours and editable, next to task.status. In Tools → Query notes (SQL) the same fields read as task.status. task.column is the column's position on the Kanban (1, 2, 3…), which is why the Base's board grouped by task.status shows the columns in Kanban order rather than alphabetically.

Edit the Base with AI

Edit with AI…, on the Base's toolbar, takes a request in plain words — fill in the author of each book, mark as read what has a rating, show the author column and sort by year — and the AI proposes the changes: writing properties to the notes' frontmatter and changing the Base's structure (showing or hiding columns, a column's display name, formulas, sorting, grouping and filter). It does not create or delete notes: that is still done in the tree.

The review is the same as in the custom table: nothing is saved before Apply, and whatever you untick is left out. A property reaches the note the same way a cell edit does — in an open note with changes, it goes into the tab and waits for you to save. Calculated fields (the built-in ones, the task ones and formulas) are not written. The structure leaves the Base with changes to save (Ctrl+S). After applying, the strip at the top offers Undo, which reverts the properties and the structure at once.