2025-05-04

2025-05-04

Neorg

Becuase it is taking way more time than I expected on Language Server due to desigining rich data structure for a markup language, I should step back and re-establish my goal again.

What I want to make right now: a blog

What feature I'm missing with it: tags that can be expanded to list of links (for /post page)

What API I need to implement: (neorg/query-note query) to query from document storage

What I need to do:

  • initiate DB to index all documents under workspace

  • API to re-index from cached DB and current filesystem

Uhhh but

  • should I create new DB for every single workspaces?

    seems so, just call it as a "workspace cache"

  • how about single file support?

    just don't initiate NorgBerg when workspace couldn't be found

Some new ideas about norg's link syntax

  • ditch :$/path syntax and replace it with :/path. can't imagine user wanting to link norg file for same workspace from upper directory

  • {:../path/to/file} is supported but should be avoided. (may target to file outside of workspace) Applications should set hard boundary for links to placed under same directory where root.toml lives

  • external workspaces will be treated similar to how vite does with @src/ path. They will be specified in root.toml like vite does with vite.config.js

  • (not related to syntax) workspaces doesn't have a name by default. $this is just a local namespace defined for each workspaces

  • line number syntax follows github's rule: file:///path/to/file.txt#L12. This makes sense because we can generalize link location as range (#L12-L13)

OK, back to norgberg implementation. from really high level, the app should be able to

  • get optional workspace from given norg file path

  • get name & path pairs of external workspaces listed on current workspace manifest

So link resolvation flow is:

doc_path: Path
-> workspace: WorkspaceManifest // manifest of workspace associated for that document (containing external workspace namespaces)
-> resolve links in that context

But what I want now is not link resolvation. I want to query notes from current document.

(call macro in document, with doc_path)
-> workspace: WorkspaceManifest // same to above, workspace for origin document
-> (run query with scope to this workspace)

query examples:

  • notes referencing this document (or sharing location with specific link target)

  • notes under specific glob:

    .ul-links/glob :/posts/*

  • notes with specific metadata (check with janet? idk)

because quering can be happen in multiple way, we can create a table for queries (queries written in janet script)

CustomQuery
| id | query    | origin                         |
| 1  | (if ...) | /path/to/file/using/this/query |

| id | query_id | match_file (hash) | match_range |
| 1  | 1        | /path/to/file     | 0..0        |
| 2  | 1        | /path/to/file     | 32..34      |

So we will have two ways to query notes

  • using standard metadata scheme

  • using dynamic janet query

first one will be used for fast indexing e.g. search filtering in mobile app and so. second one will be used for general macros querying other notes