# 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

### Link text

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

Write -> Store on disk
[[Some File]] -> [Some File](some-file.md)

Editing
[Some File](some-file.md)

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
[Index | notes/index.md]: notes/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) <ref id="1" />

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.

[//begin]: # "Autogenerated link references for markdown compatibility"
[todo]: ../dev/todo.md "Todo"
[Index]: ../index.md "Foam"
[//end]: # "Autogenerated link references"
