Foam
T

Foam Core 2020-07-11

Present: @jevakallio, @riccardoferretti

Tests

  • How do we know this approach works?
    • Supports renaming
    • Supports searching with (attribute-x)
    • Find dead links

Getting started

  • Land work to master

    • Create a foam-core package

Open questions

  • How should writing to files work
    • What if affected notes have unsaved changes

Graph methods

  • get all
  • search by
    • tag
    • free text
    • [[todo]]: how do vs code search editors work? are they pluggable? what do they need?
  • find dead links
    • for linters
  • serialize/toJSON (for visualizers)
  • subscribe to changes
  • find if a link exists (and which link) in a given row / column position + return it's start and end position - this would probably be needed e.g. to CTRL-hovering to work properly

Node methods

  • rename node and all links to that node
  • get links
    • forward links (for link lists)
    • backlinks (with surrounding context)

Node definition

What do we need the node (and edge metadata) to contain:

  • id: tbd
    • should be unique, needs some kind of unique gen function
    • should be reconstructable even if links are not updated every time
    • what happens during rename? is reparenting the graph going to be hard?
    • do id's need to be persistent, or can we create them per in-memory session, keep them stable despite renames, and then next session generate a new id?
    • Ideally should be a path to file, so it's easy to look up from the graph by id for renaming
  • type: Note | Image | etc
  • title: can be read from markdown title or frontmatter metadata
  • path: full path to file, relative to workspace (graph) root
  • links:
    • id: File to link to
    • text: The link label
    • type markdown | mediawiki | image | http
    • section: : Anchor link to a heading in target note, if we want to add support for linking to sections
    • block (ref)
    • Positional data from AST?
  • tags

Markdown layer

  • source: raw markdown (rename?)
  • ast: raw markdown ast
  • checksum: if we do caching

// some-file.md // # Some File

Write -> Store on disk [[Some File]] -> Some File

Editing Some File

On disk (could be solved by migration) [[some-file]] [[Some File]]

  • docs/index.md -> Index
  • notes/index.md -> Index

[[Index]] [[Index | notes/index.md]]

Index docs/index.md

[[Some File | path/to/some-file.md]]

Do we apply any constraints:

  • [[file-name-without-extension]]
  • [[file-name-with-extension.md]]
  • [[Title Cased File Name]]

Not supported by Markdown Notes:

  • [[path/to/file-name.md]] - Just use markdown links
  • [[Target Note Title]]

Issues:

  • Name clashes in directories

  • Name clashes between extensions

  • Renaming

    • Change filename/title needs to reflect everywhere
  • Orphaning

  • If we can't rely on in-memory process to rename things correctly while changes happen (e.g. file is renamed, moved, deleted, or titled)

Solving this issue is necessarily heuristic. We could try to write smart solutions, plus a linter for orphans

How others solve this:

  • Unique ids -- could support optionally as part of file name or front matter metadata. Should not be required.
Show Graph Visualisation