Concepts

Markdown is a lightweight markup used to edit text.

Lookup

• Markdown

Details

The workspace is the top most folder you create when you run Dendron: Initialize Workspace. It is at the same level where the dendron.yml file is located.

A workspace contains one or more vaults, with a single vault being the most common (see when you might want multiple vaults for scenarios that might require additional vaults)

Concepts

Workspace Root

The folder that contains files like dendron.yml and dendron.code-workspace is the top-level directory of a workspace, known as the workspace root.

Code Workspace

A workspace that is created using dendron.code-workspace file.

Native Workspace

A workspace that is created with a dendron.yml file and lacking a dendron.code-workspace file.

Bare Workspace

A bare workspace is a workspace where all vaults inside are remote vaults (separate git repos). You can have a bare code workspace or a bare native workspace.

Commands

Workspace: Sync

... rest of your dendron.yml
workspaceVaultSync: noPush
vaults:
    -
        fsPath: my-website
        sync: noCommit
        remote:
            type: git
            url: 'git@github.com:my-username/my-website.git'
    -
        fsPath: my-notes
        sync: sync
        remote:
            type: git
            url: 'git@github.com:my-username/my-notes.git'

Workspace Types

Dendron recognizes two types of workspaces, Code and Native. When you initialize your workspace with the Initialize Workspace command, you get a Code workspace. Code workspaces include a dendron.code-workspace file which sets up vaults and recommends installing some useful extensions. Code workspaces are great when you are setting up a knowledge base.

Native workspaces on the other hand don't have a dendron.code-workspace file. They are useful when you are writing notes or documentation, and you want to keep your notes as part of a project rather than a separate knowledge base.

See Native Workspace Setup to see how you can start using a native workspace!

Cookbook

Version control your workspace using Git

Inside your workspace, run the following

1. Initialize a git repo

   git init
   git add .
   git commit -m "initial commit"
   

2. Add a remote
   • go to GitHub, and create a new workspace
   • follow instructions to add an existing git repo to the repository

Syncing your workspace with Git

Workspace Sync does not sync the workspace if all your vaults are separate git repos. In order to synchronize your workspace, you need to explicitly do a git pull from the workspace folder.

If you are inside VS Code, you should be able to run > Create Integrated Terminal..., choose the folder containing your workspace, and launch the terminal. After launching, run a git pull inside of it.

If you're familiar with git, it's just like a code repo. By default, Dendron creates a vaults folder when you first initialize a workspace. All your notes are stored on a per vault basis.

.
└── workspace
    ├── vault.main
    │   ├── foo.md
    │   ├── foo.one.md
    │   └── foo.two.md
    └── vault.secret (hypothetical)
        ├── secret.one.md
        └── secret.two.md

By default, when you look for notes in Dendron, it will search over all vaults.

Users of other note-taking tools often balk at Dendron's focus on hierarchies. The common counterpoint is that the real world is not constrained by hierarchy and that this approach isn’t flexible enough for what they want to do. These users argue for graphs and backlinks as a better primary model for managing knowledge.

A graph is indeed more flexible. If we were building a digital brain for computers to perfectly model the world, we would probably go with this approach. But we are not building a tool for computers to capture every facet of the world; we are building a tool to help humans make sense of it. The challenge we face as humans is information overload. There is too much of it and we need ways of constraining that complexity. Filtering large amounts of information into exponentially smaller subsets is what hierarchies are built for (and why they are used as the core primitive in every database ever created).

With a hierarchy, you have one source of truth where a note can be filed and a filtering process to help you find the right place to file. Note that this doesn't limit you to creating secondary associations using backlinks, tags, and keywords.

The traditional failings of past hierarchies were that they were too rigid. Most people’s experience with hierarchies are folder hierarchies that ossify from the moment that they are created. These hierarchies are hard to change and so people don’t change them, even as their underlying understanding of the domain changes. It is because of this friction that most new tools focus on note creation without any predefined structure. This approach makes creating notes easy but finding notes hard.

Dendron has flexible hierarchies. They provide a structure for your notes but these structures can be easily changed. In programming, developers can refactor code and change its structure — the IDE will make sure that all references pointing to the original code are updated. In Dendron, you can refactor notes and hierarchies and Dendron will make sure that your PKM is consistent throughout. This means that you have the best of both worlds: a basic structure for the organization but the flexibility to change it.

Dendron organizes your notes into hierarchies. These are . ("dot" or "period") delimited Markdown files.

Example

Below is a hypothetical hierarchy for a file tree:

.
└── project1/
    ├── designs/
    │   └── promotion.png
    ├── paperwork/
    │   └── legal.md
    └── tasks/
        ├── task1.md
        └── task2.md

The same hierarchy in Dendron would look like the following:

.
├── project1.md
├── project1.designs.md
├── project1.designs.promotion.md
├── project1.paperwork.md
├── project1.paperwork.legal.md
├── project1.tasks.md
├── project1.tasks.task1.md
└── project1.tasks.task2.md

Templates are notes whose content can be copied to other notes.

Templates can either be applied into an open note with the Apply Template, or automatically applied at note creation with Schemas.

Schema help you apply consistent structure to all your notes.

As you end up creating more notes, it can be hard to manage them at scale. Think of schemas as an optional type system for your notes that describe the hierarchy of your data and are represented as a hierarchy, themselves.

One of the primary capabilities for schema is to automatically insert templates into new notes.

We recommend using all lower kebab case when naming your files. For example, awesome apples would be awesome-apples. This would be stored in your file system as awesome-apples.md.

Dendron will auto-generate a human friendly title based on the last part of your hierarchy. By default, Dendron uses title.sh to generate titles based on your note name. Titles generated are consistent with the Chicago Manual of Style. Dendron will replace - with a  (space) when generating titles.

If you end up adding custom capitalization to your file name, Dendron will not attempt to generate a title but return the last part of your hierarchy as is.

Some examples below:

- awesome-apples.md -> title: Awesome Apples
- fruit.awesome-apples.md -> title: Awesome Apples
- fruit.Custom-Capitalization -> title: Custom-Capitalization