* always convert vscode.Uri to foam.URI
* Improve handling on Windows paths in URI
- convert to upper case drive letter
- normalize use of Windows conversion in URI
- added more test cases
* Fixed tests
* added support for target date variables in daily note template
* added FOAM_DATE_* variables to resolver
* Document `FOAM_DATE_*` template variables
* Add CHANGELOG entry
Co-authored-by: Michael Overmeyer <michael.overmeyer@shopify.com>
* moved `foam-core` inside `foam-vscode`
* updated contribution guide to reflect new modules setup
* improved testing
* consolidate to root yarn.lock files
* tweaking CI workflow && using github secrets to force cache refresh
* improved linting configuration. `core` module cannot depend on other parts of the `foam-vscode` package
* Add the functionality to include notes in a note
* Add proposal of embedding
* Add tests for including notes
* Add documentation for inclusion feature
* Removes escape character of an alias when setting WikiLink target
* Alter tearDown of document-link-provider test
* Disable link reference defintion generation for all tests
* be more conservative in removing link definitions
* Update packages/foam-vscode/src/features/preview-navigation.ts
Co-authored-by: Riccardo <code@riccardoferretti.com>
Co-authored-by: Riccardo <code@riccardoferretti.com>
* Add docs to `createDailyNoteDirectoryIfNotExists`
* Add docs to `createDailyNoteIfNotExists`
* Capitalize doc strings
* Add docs to `getDailyNoteFileName`
* Update the @configuration parameter docs
* Add docs to `getDailyNotePath`
* Add docs to `openDailyNoteFor`
* Update packages/foam-vscode/src/dated-notes.ts
Co-authored-by: Michael Overmeyer <michael.overmeyer@shopify.com>
* Update packages/foam-vscode/src/dated-notes.ts
Co-authored-by: Michael Overmeyer <michael.overmeyer@shopify.com>
* Polish some of the comments
Co-authored-by: José Duarte <jmg.duarte@campus.fct.unl.pt!>
Co-authored-by: Michael Overmeyer <michael.overmeyer@shopify.com>
* Add support for basic link aliases
* Refactor to future link model
* Refactor preview behavior for aliases
* Refactore use of NoteSource
* Remove references from ref block before processing links
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
* Add a frontmatter metadata parser
* Use the template metadata to determine the filepath to use
* Document template metadata
* Add name and description template metadata attributes
These are displayed in the template picker
* Document name and description template metadata attributes
* Fix snake_case to camelCase
* Always ask for the note title when creating from the default template
In the future, we'll make this conditional on whether the template provides the filepath to use in its metadata block
we wait to create the graph, as changes to the workspace will cause it to be recomputed.
so, first load all resources from the initial providers, then compute the graph.
* Add new `Create New Note` command
It is the streamlined counterpart to `Create New Note From Template`
* Simplify the variable Regex
\W is equivalent to [^A-Za-z0-9_]
* extracted graph from workspace
* refactored datastore
* dataviz to use URI for placeholder detection
* graph uses uris, not resources
* adding placeholder in graph
* link completion to use graph
* API v1 - Resource refactoring (#595)
* aside: tweaked jest extension configuration
* added provider for markdown
* removed file check in URI
the problem is that it makes the URI dependent on the disk, which makes testing harder.
The change was originally introduced to prevent Foam from treating directories ending in .md as markdown files, but the check needs to probably happen somewhere else, e.g. in `FileDataStore.list` - or directories should be expressed with a trailing slash (to check whether that breaks the URI convention)
* Various changes
- `resolveLink` now delegates to providers
- added `read` method in providers and `FoamWorkspace`
- improved `Matcher` API
- updated tests to use workspace with providers
- delegating more to workspace now it can read files (simplifies wiring and exposed API surface)
- provider init returns a promise, so it can be awaited on
- `IDataStore` now has `list` method, to encapsulate all access to FS
* improved windows support in URI and matcher
* improved grouped resources interface
* added readAsMarkdown in provider, useful for tooltip generation with preview in vscode
* Fix: Right links and formatting
* Docs: Run markdownlint to automatically fix minor formatting errors
* Style: Format with markdownlint and not prettier
* when calling URI.file more than two time on windows
* a extra slash('/') at path's beginning may cause some problems
* so add a condition to solve it
* placeholders are updated when creating connection, not when resolving link
* feature: link completion
* added tests
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
* refactored URI to be less dependent on VS Code implementation
* moved uri tests in own file, and added test case from #507
* added license info for VS Code inspired code
* moved URI utility methods in abstract class for namespacing
* better names for some methods
Co-authored-by: Jonathan <jonny@mondago.com>
* added uri utility method, and exposing uri module
* added utility methods
* renamed and enhanced open-placeholder-note command to support all resources
* support for links via document link provider and decorator
* use open resource command in tree data provider
* make open resource command unavailable in command palette
* using snippet for better UX when creating note from placeholder
* exposing parser as a Foam service
* consolidated "open resource" command code
* added tests for document links provider
* added caching of VS Code also for lint
Even if linting doesn't require the vscode part of the cache, we are not separating the two cases so that we only have one cache to maintain, and linting being a faster task (and a task that should fail less than tests) will update the cache more often, speeding up the run of the tests afterwards
* `FoamWorkspace.find` to return `null` when no reference is provided for relative path
* turning wikilinks into browsable links in markdown preview
* moved preview styles in css file and reorganized code in static folder
Static was previous used only for the dataviz graph. Now we have 2 subdirectories: dataviz for the graph, and preview for the markdown preview.
For now the css style is a bit of an overkill, but sets up the right foundation for further customization down the line.
* chore: explicitly disabling gitdoc extension, removing unnecessary async keyword
* fix: fixed test utility fn (and linter warning)
* test: added tests for preview link generation
* changed launch configuration to support both foam-core and foam-vscode packages
* Use URI throughout dated-notes
* Fix typos in comments
* Allow absolute paths in `openDailyNote.directory`
This allows users to press the `alt-d` shortcut to open the daily note
from any instance of VSCode, not just within the `foam-template` repo.
The even listener is called with `this` bound to undefined, which causes the refresh function in fail when it accesses the object methods/fields. wrapping it into an arrow function avoids the problem
* Create Blank Note Explorer View
Creates a new "Blank Note" explorer view which displays all notes that
contain only a title. When note.source.text.trim().split('\n').length
is equal to 1, a note is considered blank. This should mean that the
note contains only a title.
The UX experience is identical to that of the Orphan view. A user can
toggle between both the flat view and a nested view grouped by
directory.
* Cleaned up views and made them much more dynamic.
Instead of just copy and pasting the orphans view into blank notes,
I created a filtered notes provider, which behaves identically to the
old orphan/blank notes providers, but allows the caller to pass in the
"filter function" which will narrow down the list of notes in the view.
This also allows us to more easily unit test the filtering logic, and
only test the flatten / nested logic in one place. It also makes it so
that when we refactor the way one of these views works (e.g. adding the
markdown preview), we don't have to make changes to the other view.
* Fixed unit test that was failing in Windows.
* Combined placeholders and blank notes.
* Removed workspacesFsPaths and replaced with workspacesURIs
Co-authored-by: J.T. James <joel.james@myfuelmaster.com>
* improved resolution for direct links and wikilink with definition
* if the definition of a wikilink points to a non-existing file, create a placeholder for the full path instead
* if a link doesn't point to a valid resource, create a placeholder for the full path instead
* commented out test-data.js import in dataviz.html
* moved test to more appropriate group
* Combine steps
* Cancel if escape pressed in any step
* New template command
* Execute "create new template" when no templates found
* Provide inline documentation
* Add tests
* Add docs for the feature
Co-authored-by: Jonathan <jonny@mondago.com>
* improved delta logic in graph.js
fixes a bug that was due to using object.splice inside a forEach loop (sometimes stackoverflow is wrong - removing the element inside the loop will actually reduce the iterations and not all elements in the array will be visited!)
* various fixes to live update of workspace model + tests
* added tab size option in settings.json
* added workspace WIP
* workspace supports resources
* uri check more lenient (was causing bug by not recognizing some objects)
* added placeholder resource type
* consolidated code in FoamWorkspace and added more tests
* updated all modules to use FoamWorkspace
* fixed FoamWorkspace.getConnections function
when links or backlinks are not present it no longer adds `undefined` to the connection list
* fix in workspace handling of direct links
* consolidated id/name generation functions
* added test for wikilink resolution when several notes have same filename
* removed reference to graphMiddleware in foam-local-plugins doc
graph middleware won't be supported with the `FoamWorkspace`. Support for the markdown provider remains
* removed support for graph middleware, graphlib dependency, and old note-graph implementation
Running the tests with vscode 1.53.0 is causing issues in `suite.ts:23`, which is causing a stack overflow, possibly due to a recursive callback. Also see https://github.com/foambubble/foam/pull/479#issuecomment-774167127 .
It's unclear what's causing the issue, but forcing the version to 1.52.0 solves the problem.
To review, further investigate, and roll back this workaround.
* fix#442 - link to known-issues replaced
* formatted settings + enable format on save + improved jest config
* removed editorconfig in foam-cli
* formatted foam-vscode
* removed author in package.json files
* minor changes to readme files
* fixed husky pre-commit hook
* Add graph style to VSCode settings
* Update default to an empty object
* Add function to retrieve the graph style from the settings
* Implement the graph custom styling setting
The implementation makes use of the webview communication mechanism to
switch messages between the webview and the graph.
It works as follows:
- When the webview is loaded, it now sends a single request to VSCode,
the request asks VSCode for the graph style
- When VSCode answers with the style, the graph style is updated and
the webview loading process continues as normal.
The style change does not modify the API, in fact it makes use of the
shadiest programming tatic ever, *global variables* to remain
compatible.
The style object *currently* supports four base fields:
- background: string
- fontSize: int
- highlightedForeground: string
- node: object
- note: string
- nonExistingNote: string
- unknown: string
* Simplify null handling logic
* Remove debug logs
* Rename style setting
* Rename message style type
* Remove forgotten debug log
* Refactor the code to match model & action
* Add missing break
* Allow for dynamic style updates
* Fix the window loading bug
* Implement a permanent fix to the bug
* Replace `nonExistingNote` with `placeholder`
* Include the new graph style feature in the docs
* Remove unnecessary async
* Remove unused case
* support direct links
* added support for labels with formatting
* added documentation and removed lint warning
* ignore external links
* improved uri parsing
* filter links pointing to same note (e.g. sections within the note)
* check that note exists before navigating to it
* fixed compilation error
* added support for e2e vscode tests
* using github action that supports headless test run
* loading vscode test instance in empty dir to speed up bootstrap
* add windows-2019 to CI os matrix
* use actual URI object instead of strings to represent paths/uris
* added datastore tests
* chore: make Foam IDisposable
* fix(graph): Don't delete node for note on update
Doing so causes graphlib to delete the inbound links from other nodes so when this node is re-created it will be adrift by itself.
* Clear graph node's forward links on note update so they can be accurately rebuilt
* test(dataviz): Ensure updating a note does not clear its backlinks (tests #393)
* fix(dataviz): On note delete, set node to "no file" state if it is referenced by other notes
* test(dataviz): Ensure graph updates properly from note deletions
* reorganized and updated foam docs
* minor changes to vscode extension readme
* added 404 page and minor changes
Co-authored-by: Joe Previte <jjprevite@gmail.com>
Added API and events around note deletion
Improved github workflows, added logic to avoid duplicate runs in CI and merged build + test jobs
Added support for running workflows in multiple environments, commented window-2019 as test don't pass, but they will be fixed in another PR to avoid scope creep here.
* Improved logging
- using classes instead of functions (feels like it fits better the use case)
- using singleton global to not pass logging service around
* Added vscode logger, command to change level, and settings
* improved bootstrap logging
* build foam-core before running tests in github workflows
* added common code from vscode repo
lots of good utility functions and objects, especially around lifecycle and event management
* added datastore and logger services
* refactored bootstrap to consolidate behavior in foam-core
* tags treeview now updates when files are saved
* updated node engine version to match vscode's
* using new event model for foam graph events
* Initial work to create new note from template
* Treat template as snippet string
* Small refactor
* Improve semantics of focusNote
* Ask for filename, not title
Authored-by: Jonathan Ingall <jonny@mondago.com>
* Add documentation to the settings getters
* Reduce code noise in the bootstrap method
Files are now all processed in one method,
without `filter`s or `map`s to avoid reallocating arrays.
`addFile` is now inlined, as its function was mostly noise and became
unused.
`isLocalMarkdown` is now done right after listing all workspace files,
before applying the ignore globs.
`registerFiles` merely deals with registering several files,
instead of requiring a loop each time several files are to be
registered.
* Add documentation and type annotations
* Rephrase filterAndRegister docstring
* added test with d3 and g6
* spiked on three graph libraries
* removed unnecessary deps
* small clean up
* picked implementation, cleaned code and added selection
* use title as graph node name instead of note basename
* reloading graph when adding/removing notes
* fixed graph construction to remove node duplicates
* using file name for notes that don't have an h1 title
* added utility functions
* fixed link highlighting bug
* fixed various checks and lint errors
* Start working on date snippets
* Refactor logic to share across date features
* Start providing computed values
This may need to be changed to a Thenable
* Make calculated snippets functional
* Add support for any number
* Comment the code
These comments should be removed later
* Make "+" in snippet work
* Refactor changes
* Remove unused imports
* Add days of week snippets
* Add a shortcut for yesterday's note
* Rename focusDailyNote function
* Move pathExists to utils
* Make navigation on snippet selection configurable
Co-authored-by: Jonathan Ingall <jonny@mondago.com>
* changed vscode setting to include extensions in link definition
* updated docs to include extension in wikilink definition
* updated readme to navigate to github pages instead of published site
* added support for graph middleware via local plugin
* added support for parsing extension points / plugins
* improved parser plugin and added docs
* improved name of parameter
* need to enable local plugins, and improved configuration system
For security reasons local plugins are off by default.
The feature can be enabled via a flag in the foam configuration, which has been expanded to support this case.
The configuration system now reads a `config.json` file inside the `.foam` directory as well as a `~/.foam/config.json` file to configure the system.
Only the user specific configuration file can be used to enable local plugins, as a security measure against malicious repos.
* added prettier configuration file
This ensures consistency across machines as well as an explicit source of truth
* Access correct property on error to display stack trace
* Fix crash when file contains only frontmatter
* Add test for generateHeadings when the file only contains frontmatter
Co-authored-by: Ankit Tiwari <ankitt255@gmail.com>
* Update math-support.md
Explains how this mechanism works and adds some ideas on alternatives.
* Improve document structure
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
After #208, id for each note in NoteGraph is hashed. However, in generateReferenceList in file wikilink-reference-generation.ts, the id is still given by the file path, which compromised the core functionality. This PR fixed this bug.
* decoupled ID from note slug
* added vscode debug configuration to work with vscode-jest extension
* made things prettier
* Add a test for parsing empty frontmatter
* Use astPositionToVsCodePosition util function
* fixed a TODOs around URIs and added tests
* added tests around notes querying
* removing unused imports
* Fix typo
* implemented PR feedback
* fixed lint warnings and renamed method for consistency
* removed unnecessary checks and fix compilation error in tests
Co-authored-by: Ankit Tiwari <ankitt255@gmail.com>
* Fill out Migrating from OneNote stub
* Update Summary and improve grammatic consistency
* Added terminal navigation instructions
* kebab-case and update roadmap links
* feat: setup jest for foam-vscode
* Add failing test (fails due to missing vscode dependency)
* feat: add vscode mock
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
* Add frontmatter data to NoteGraph node
* Store document start position inside NoteGraph node
* Add heading below the frontmatter
* Show a progress bar while running Janitor
* Fix tests
* Update note start position to make it 1-indexed
* Initialize frontmatter by an empty object instead of null
* Remove console logs
* Add how to update pushed Azure Wiki
Add the way to push to GitHub and Azure with one command.
* Update docs/azure-devops-wiki.md
Co-authored-by: Joe Previte <jjprevite@gmail.com>
* Update azure-devops-wiki.md
Add suggested changes
* Update docs/azure-devops-wiki.md
Co-authored-by: Joe Previte <jjprevite@gmail.com>
Co-authored-by: Joe Previte <jjprevite@gmail.com>
* revise vscode task and launch configs
- Removed commands from sub-package:
same can be achieved from the root
- Added build and no-build variants.
In case separate watcher is already running,
no need to build.
- Changed watch to build (no hot-reload in vscode by default)
- Show the build in console
Didn't update yarn.lock, seems to want to add
foam-core@0.3.0-alpha.0, but not really
related to this change
Note: the extension tests are failing due to
`Cannot find module '...foam-vscode/out/test/suite/index'`.
However that shouldn't be related to this change either.
* Simplify VS Code launch tasks (shift work to typescript compiler)
* Fix circular dependency index->janitor/index->index
* Use --build flag to use TSC in Build Mode
https://www.typescriptlang.org/docs/handbook/project-references.html#build-mode-for-typescript
This configures tsc to use multiple project roots (vscode, core) and run incremental builds on
changes to each projects. This will necessitate us running the core in commonjs build mode,
which is fine for testing and deployment to node environments, but won't work in the browser,
so foam-core will need a separate build config for UMD builds
* Build foam-core in commonjs mode by default (+cleanup unnecessary config)
* Create ES6 build config for distribution builds
* Cleanup yarn.lock
* Build package before running
* Fix missing lint paths and fix lint error
* Remove redundant .vscode settings files from foam-vscode project
* Add core test launch task
Co-authored-by: jojanaho <janne.ojanaho@iki.fi>
* Update creating-new-notes.md
Added a non-intuitive hotkey for entering notes.
* Add instructions on how to remap the key binding
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
* Move applyTextEdit to core
* WIP: Add janitor command in foam-vscode
* basic janitor command done
* unsaved markdown janitor solved
* export bootstrap getConfig functions
* fixed multi unsaved files text edits
* Move applyTextEdit to core
* WIP: Add janitor command in foam-vscode
* basic janitor command done
* unsaved markdown janitor solved
* export bootstrap getConfig functions
* fixed multi unsaved files text edits
* Be less greedy about definitions, only include defs at end of file
* Use link reference definitions in janitor
* Add headers/footers to tests
* Ensure janitor doesn't touch unrelated reference definitions
* Format document, convert promise trampoline to async/await for readability
* Add error handling and friendly output
* Use workspace settings for extension
* Add flag to janitor
* Use note.eol
* Fix tests
Co-authored-by: Ankit Tiwari <ankitt255@gmail.com>
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
* adding recipe for migrating from Onenote
* Update docs/roadmap.md
Co-authored-by: Joe Previte <jjprevite@gmail.com>
Co-authored-by: Joe Previte <jjprevite@gmail.com>
* Add notes to NoteGraph when they are created
* Add experimental events to foam-core to notify listeners about added/updated notes
* Update reference definitions in active editor when new note is added
* Update document in note graph before updating references
* Move cursor to end of file when opening daily note
* always move cursor to end of the file
* Only move cursor focus when file is newly created
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
* Add Note.definitions and Note.end
* Use stringifyMarkdownLinkReferenceDefinition in foam-vscode
This commit also applies prettier to previously badly formatted files, so the diff is larger than necessary
* Add Note.end and Note.definitions to foam-core tests
* Export stringifyMarkdownLinkReferenceDefinition from foam-core
* Implement first version of generateLinkReferenceDefinitions janitor method
* Add partial tests for generateLinkReferenceDefinitions
* Setup Jest
* Add remove link definitions test to generateLinkReferences janitor method
* Add update link definitions test to generateLinkReferences janitor method
* export TextEdit interface
* Implement first version of applyText method
* Add no change in link definitions test to generateLinkReferences janitor method
* Add partial tests for writeFileToDisk method
* Implement generateHeading janitor method
Co-authored-by: CHIRAG SINGHAL <csinghal208@gmail.com>
* Move noteGraph scaffolding to utils
* Implement basic foam-cli janitor command
* kebab case file names while running janitor
* added generate Heading function to janitor
* added tests for generateHeading in janitor
* PR changes
* Add ora spinner
* Store endOfLine inside Note
* Use note.eol to append line endings
* check if given path is valid directory
* minor fixes
* added glob as dependency
* ignore link refrences with no file
* added tests files for migration
* Solves issue with roam migration
* fixed core tests
* Replace dashify by github-slugger
* used github slagger instead of dashify
* Add foam-core as dependency
* added foam migrate command
* updated foam janitor command
* minor fixes
* removed extra test files
* removed excess white space
* Refactor (PR changes)
1. Renamed initializeNoteGraph.ts to initialize-note-graph.ts to be consistent with naming
2. Refactored code in janitor and migrate commands
* Mock fs for tests
* Use Promise.resolve(null)
* Make fs tests no blocking by using promises
* Refactor renameFile to use path module
* Propagate the error from writeFileToDisk method
* Remove posttest command
* Run prettier before merge to get a cleaner diff
* Fix typo in variable name
* yarn lint --fix
* Update markdown-provider tests to support new API
* Add missing includeExtension argument
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
Co-authored-by: chirag-singhal <csinghal208@gmail.com>
* Add .md extension when generating link definition section
The change in the definition allows links to be navigated in github
The changes in the JS inside _layouts maintains the html navigation when publishing to github pages.
For more info see https://foambubble.github.io/foam/link-reference-definition-improvements
* Updated existing docs to new link definition section
* better md file detection and consolidated code in parent template
* added mdx extension to markdown file detection
* added note about shortcut taken
* added configuration to toggle extensions in wikilinks + tests
* Revert "Updated existing docs to new link definition section"
This reverts commit 50e4a527e0.
We'll do this change once the version has been released
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
* Add dateformat package dependency
* Implement Open Daily Note feature
- Activate command
- Add default keybindings for the command
- Use settings to configure the filename format, the file extension,
the title format and the directory where the note should be created
* Clarify how the repository should be opened in VS Code
* Change formatting and wording slightly
Co-authored-by: Jani Eväkallio <jani.evakallio@gmail.com>
This repository is a [monorepo](https://en.wikipedia.org/wiki/Monorepo) managed by [Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/).
- The [packages](packages/) directory contains all Foam core code packages
- The [docs](docs/) directory contains a Foam workspace that hosts the official [documentation site](https://foambubble.github.io/foam)
The foam starter template lives outside of this repository at [foambubble/foam-template](https://github.com/foambubble/foam-template).
See [Foam Contribution Guide](https://foambubble.github.io/foam/contribution-guide) on the rendered Foam workspace for more information on how to contribute to Foam.
Head over to the [[contribution-guide]]. `CONTRIBUTING.md` file name is blocklisted on GitHub pages, and doesn't appear in the [rendered output](https://foambubble.github.io/foam).
[//begin]: # "Autogenerated link references for markdown compatibility"
> [[todo]] [[good-first-task]] This contribution guide itself could be improved 😅
Foam is open to contributions of any kind, including but not limited to code, documentation, ideas, and feedback.
This guide aims to help guide new and seasoned contributors getting around the Foam codebase.
Foam is open to contributions of any kind, including but not limited to code, documentation, ideas and feedback. Here are some general tips on how to get started on contributing to Foam:
## Getting Up To Speed
- Use Foam for yourself, figure out what could be improved.
- Check out [[roadmap]] to see what's already in the plans. I have thoughts about how to implement some of these, but open to ideas and code contributions!
- Read about our [[principles]] to understand Foam's philosophy and direction
- Read and act in accordance of our [[code-of-conduct]].
- Feel free to open [GitHub issues](https://github.com/foambubble/foam/issues) to give me feedback and ideas for new features.
- Foam code and documentation live in the monorepo at [foambubble/foam](https://github.com/foambubble/foam/)
- [/docs](https://github.com/foambubble/foam/docs): documentation and [[recipes]]
- [/packages/foam-vscode](https://github.com/foambubble/foam/tree/master/packages/foam-vscode): the core VSCode plugin
- [/packages/foam-core](https://github.com/foambubble/foam/tree/master/packages/foam-core): powers the core functionality in Foam across all platforms
- Exceptions to the monorepo are:
- The starter template at [foambubble/foam-template](https://github.com/foambubble/)
- All other [[recommended-extensions]] live in their respective GitHub repos.
Before you start contributing we recommend that you read the following links:
## Contributing to the VS Code Extension
- [[principles]] - This document describes the guiding principles behind Foam.
- [[code-of-conduct]] - Rules we hope every contributor aims to follow, allowing everyone to participate in our community!
If you're interested in contributing to the VS Code extension (aka `foam-vscode`), this guide will help you get things set up locally.
## Diving In
We understand that diving in an unfamiliar codebase may seem scary,
to make it easier for new contributors we provide some resources:
You can also see [existing issues](https://github.com/foambubble/foam/issues) and help out!
Finally, the easiest way to help, is to use it and provide feedback by [submitting issues](https://github.com/foambubble/foam/issues/new/choose) or participating in the [Foam Community Discord](https://foambubble.github.io/join-discord/g)!
## Contributing
If you're interested in contributing, this short guide will help you get things set up locally.
1. Clone the repo locally:
@@ -29,25 +33,68 @@ If you're interested in contributing to the VS Code extension (aka `foam-vscode`
`yarn install`
3. This project uses [Yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/).`foam-vscode` relies on `foam-core`. This means we need to compile it before we do any extension development. From the root, run the command:
3. From the root, run the command:
`yarn workspace foam-core build`
`yarn build`
4. Now we'll use the launch configuration defined at [`.vscode/launch.json`](https://github.com/foambubble/foam/blob/master/.vscode/launch.json) to start a new extension host of VS Code. From the root, or the `foam-vscode` workspace, press f5.
5. In the new extension host of VS Code that launched, open a Foam workspace (e.g. your personal one, or a test-specific one created from foam-template). This is strictly not necessary, but the extension won't auto-run unless it's in a workspace with a `.vscode/foam.json` file.
6. Test a command to make sure it's working as expected. Open the Command Palette (Ctrl/Cmd + Shift + P) and select "Foam: Update Markdown Reference List". If you see no errors, it's good to go!
You should now be ready to start working!
For more resources related to the VS Code Extension, check out the links below:
Foam code and documentation live in the monorepo at [foambubble/foam](https://github.com/foambubble/foam/).
- [/docs](https://github.com/foambubble/foam/tree/master/docs): documentation and [[recipes]].
Exceptions to the monorepo are:
- The starter template at [foambubble/foam-template](https://github.com/foambubble/)
- All other [[recommended-extensions]] live in their respective GitHub repos
This project uses [Yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/).
Originally Foam had:
- [/packages/foam-core](https://github.com/foambubble/foam/tree/master/packages/foam-core) - Powers the core functionality in Foam across all platforms.
- [/packages/foam-vscode](https://github.com/foambubble/foam/tree/master/packages/foam-vscode) - The core VS Code plugin.
To improve DX we have moved the `foam-core` module into `packages/foam-vscode/src/core`, but from a development point of view it's useful to think of the `foam-vscode/src/core` "submodule" as something that might be extracted in the future.
For all intents and purposes this means two things:
1. nothing in `foam-vscode/src/core` should depend on files outside of this directory
2. code in `foam-vscode/src/core` should NOT depend on `vscode` library
We have kept the yarn workspace for the time being as we might use it to pull out `foam-core` in the future, or we might need it for other packages that the VS Code plugin could depend upon (e.g. currently the graph visualization is inside the module, but it might be pulled out if its complexity increases).
### Testing
Code needs to come with tests.
We use the following convention in Foam:
-`*.test.ts` are unit tests
-`*.spec.ts` are integration tests
Tests live alongside the code in `src`.
### The VS Code Extension
This guide assumes you read the previous instructions and you're set up to work on Foam.
1. Now we'll use the launch configuration defined at [`.vscode/launch.json`](https://github.com/foambubble/foam/blob/master/.vscode/launch.json) to start a new extension host of VS Code. Open the "Run and Debug" Activity (the icon with the bug on the far left) and select "Run VSCode Extension" in the pop-up menu. Now hit F5 or click the green arrow "play" button to fire up a new copy of VS Code with your extension installed.
2. In the new extension host of VS Code that launched, open a Foam workspace (e.g. your personal one, or a test-specific one created from [foam-template](https://github.com/foambubble/foam-template)). This is strictly not necessary, but the extension won't auto-run unless it's in a workspace with a `.vscode/foam.json` file.
3. Test a command to make sure it's working as expected. Open the Command Palette (Ctrl/Cmd + Shift + P) and select "Foam: Update Markdown Reference List". If you see no errors, it's good to go!
---
Feel free to modify and submit a PR if this guide is out-of-date or contains errors!
---
[//begin]: # "Autogenerated link references for markdown compatibility"
[todo]: todo "Todo"
[good-first-task]: good-first-task "Good First Task"
[roadmap]: roadmap "Roadmap"
[principles]: principles "Principles"
[code-of-conduct]: code-of-conduct "Code of Conduct"
[tutorial-adding-a-new-command-to-the-vs-code-extension]: tutorial-adding-a-new-command-to-the-vs-code-extension "Tutorial: Adding a New Command to the VS Code Extension"
[principles]: principles.md "Principles"
[code-of-conduct]: code-of-conduct.md "Code of Conduct"
- Write out a new `[[wiki-link]]` and `Cmd` + `Click` to create a new file.
-`Cmd` + `Shift` + `P` (`Ctrl` + `Shift` + `P` for Windows), execute `New Note` from [VS Code Markdown Notes](<(https://marketplace.visualstudio.com/items?itemName=kortina.vscode-markdown-notes)>) and enter a **Title Case Name** to create `title-case-name.md`
- Add a keyboard binding to make creating new notes easier.
- You shouldn't worry too much about categorising your notes. You can always [[search-for-notes]], and explore them using the [[graph-visualisation]].
[//begin]: # "Autogenerated link references for markdown compatibility"
[search-for-notes]: search-for-notes "Search for Notes"
Visual Studio Code allows you to use your own CSS in the Markdown preview tab.
## Instructions
Custom CSS for the Markdown preview can be implemented by using the `"markdown.styles": []` setting in `settings.json`. The stylesheets can either be https URLs or relative paths to local files in the current workspace.
For example, to load a stylesheet called `Style.css`, we can update `settings.json` with the following line:
@@ -10,7 +10,3 @@ But there's also a bunch of roadmap items that are hard to implement this way, a
Overall, we should strive to build big things from small things. Focused, interoperable modules are better, because they allow users to pick and mix which features work for them. A good example of why this matters is the Markdown All In One extension we rely on: While it provides many of the things we need, a few of its features are incompatible with how I would like to work, and therefore it becomes a limiter of how well I can improve my own workflow.
However, there becomes a point where we may benefit from implementing a centralised solution, e.g. a syntax, an extension or perhaps a VSCode language server. As much as possible, we should allow users to operate in a decentralised manner.
[//begin]: # "Autogenerated link references for markdown compatibility"
[referencing-notes-by-title]: referencing-notes-by-title "Referencing notes by title"
`foam-core`'s primary responsibility is to build an API on top of a workspace of markdown files, which allows us to:
- Treat files as a graph, based on links
- Can be either [[wiki-links]] or relative `[markdown](links.md)` style
- Can be either [[wikilinks]] or relative `[markdown](links.md)` style
- We need to know about the edges (connections) as well as nodes
- What link points to what other file, etc.
- Needs to have the exact link text, e.g. even if `[[some-page]]` or `[[some-page.md]]` or `[[Some Page]]` point to the same document (`./some-page.md`), we need to know which format was used, so linkreferencedefinitions can be generated correctly
- Needs to have the exact link text, e.g. even if `[[some-page]]` or `[[some-page.md]]` or `[[Some Page]]` point to the same document (`./some-page.md`), we need to know which format was used, so [[link-reference-definitions]] can be generated correctly
This file is an example of a valid Foam file. Essentially it's just a markdown file with a bit of additional support for MediaWiki-style `[[wikilinks]]`.
Here are a few specific constraints, mainly because our tooling is a bit fragmented. Most of these should be eventually lifted, and our requirement should just be "Markdown with `[[wikilinks]]`:
- **The first top level `# Heading` will be used as title for the note.**
- If not available, we will use the file name
- **File name should have extension `.md`**
- This is a temporary limitation and will be lifted in future versions.
- At least `.mdx` will be supported, but ideally we'll support any file that you can map to `Markdown` language mode in VS Code
- **In addition to normal Markdown Links syntax you can use `[[MediaWiki]]` links.** See [[wikilinks]] for more details.
[//begin]: # "Autogenerated link references for markdown compatibility"
For the time being, if you want to get [[wikilinks]] into all files within the workspace, you'll need to generate the link reference definitions yourself file-by-file (with the assistance of Foam).
### Wikilinks don't work on GitHub
> **TL;DR;** [workaround](#workaround) in the end of the chapter.
If you click any of the wikilinks on GitHub web UI (such as the `README.md` of a project), you'll notice that the links break with a 404 error.
At the time of writing (June 28 2020) this is a known, but unsolved error. To understand why this is the case, we need to understand what we are trading off.
So, why don't they work on GitHub?
The three components of [[link-reference-definitions]] are link label, link destination and Link Title.
The issue is the middle **link destination** component. It's configured to point to the file name **without file extension**, i.e. "file-name" instead of "file-name.md". This is to make the GitHub Pages rendering work, because if we generated the links to `file-name.md`, the links would point to the raw markdown files instead of their generated HTML versions.
So as you can see, we've prioritised GitHub Pages over GitHub Web UI for the time being.
Ideally, we'd like a solution that works with both, but it's not defined yet (see [[link-reference-definitions]] for more details)
#### Workaround
For the time being, you can use relative `[markdown links](markdown-link.md)` syntax.
**Pros:**
- This will work on all platforms.
**Cons:**
- It will break the Markdown Notes [[backlinking]] support
- Less convenient to write
### Finding certain words clutter the VS Code search results
Since link reference definitions have `[//begin]` and `[//end]` guards with explanatory text that use certain words, these words (like "generate") appear in VS Code search results if you happen to search matching strings from the workspace.
## Improvement Proposal
Problem space in essence:
- During edit-time (when modifying the markdown files in an editor)
- link reference definitions are needed if user uses editor extensions that don't understand wikilinks
- link reference definitions may be annoying since they
- add content to files that the user hasn't typed in by themselves
- get out of date if user uses a tool that doesn't autogenerate them
- may clutter the search results
- During build-time (when converting markdown to html for publishing purposes)
- link reference definitions are needed, if the files are published via such tools (or to such platforms) that don't understand wikilinks
- link reference definitions might have to be in different formats depending on the publish target (e.g. GitHub pages vs GitHub UI)
The potential solution:
- For edit-time
- Make edit-time link reference definition generation optional via user settings. They should be on by default, and generating valid markdown links with a relative path to a `.md` file.
- Make format of the link reference definition configurable (whether to include '.md' or not)
- Out of recommended extensions, currently only "markdown links" doesn't support them (?). However even its [code](https://github.com/tchayen/markdown-links/blob/master/src/parsing.ts#L25) seems to include wikilink parser, so it might just be a bug?
- For build-time
- To satisfy mutually incompatible constraints between GitHub UI, VSCode UI, and GitHub Pages, we should add a pre-processing/build step for pushing to GitHub Pages.
- This would be a GitHub action (or a local script, ran via foam-cli) that outputs publish-friendly markdown format for static site generators and other publishing tools
- This build step should be pluggable, so that other transformations could be ran during it
- Have publish targets defined in settings, that support both turning the link reference definitions on/off and defining their format (.md or not). Example draft (including also edit-time aspect):
```typescript
// settings json
// see enumerations below for explanations on values
{
"foam": {
"publish": [
{
"name": "Gitlab Mirror", // name of the publish target
"linkTranspilation": "Off",
"linkReferenceDefinitions": "withExtensions"
},
{
"name": "GitHub Pages",
"linkTranspilation": "Off",
"linkReferenceDefinitions": "withoutExtensions"
},
{
"name": "Blog",
"linkTranspilation": "Off",
"linkReferenceDefinitions": "Off"
},
{
"name": "My Amazing PDF book",
"linkTranspilation": "WikiLinksToMarkdown"
}
],
"edit": {
"linkReferenceDefinitions": "Off"
}
}
}
// Defines if and how links in markdown files are somehow converted (in-place) during build time
// Note that this enumeration is not valid edit-time, since we (probably) don't want to change text like this while user is editing it
enum LinkTranspilation {
Off, // links are not transpiled
WikiLinksToMarkdown, // links using wiki-format [[link]] are converted to normal md links: [link](./some/file.md)
// if this is set, not link reference definitions are generated (not needed)
}
// Defines if and how link reference definition section is generated
enum LinkReferenceDefinitions {
Off, // link reference definitions are not generated
WithoutExtensions // link reference definitions do not contain file extenions
}
```
- With Foam repo, just use edit-time link reference definitions with '.md' extension - this makes the links work in the GitHub UI
- Have publish target defined for GitHub pages, that doesn't use '.md' extension, but still has the link reference definitions. Generate the output into gh-pages branch (or separate repo) with automation.
- This naturally requires first removing the existing link reference definitions during the build
- Other
- To clean up the search results, remove link reference definition section guards (assuming that these are not defined by the markdown spec). Use unifiedjs parse trees to identify if there's missing (or surplus) definitions (check if they are identified properly by the library), and just add the needed definitions to the bottom of the file (without guards) AND remove them if they are not needed (anywhere from the file).
Note that the proposal above supports both (build-time) inline transpilation of wikilinks as well as creation reference definitions. Depending on the direction of Foam, also only one of them could be selected. In that case the other could be implemented at later point of time.
UI-wise, the publish targets could be picked in some similar fashion as the run/debug targets in vscode by implementing a separate panel, or maybe through command execution (CTRL+SHIFT+P) - not yet defined at this point.
## Links
- [tracking issue on GitHub](https://github.com/foambubble/foam/issues/16)
[//begin]: # "Autogenerated link references for markdown compatibility"
Items we plan on working next. Items in this stage don't need to have an owner, but before we start working on them should have enough specification that they can be picked up and worked on without having to seek consensus.
If you want to pick up work in this category, you should have a plan on how long the implementation will approximately take so we don't block progress by sitting on high priority issues.
- [[workspace-janitor]]
## Backlog
Everything else, categorised into themes. Just because something is on this list doesn't mean it'll get done. If you're interested in working on items in this category, check the [[contribution-guide]] for how to get started.
@@ -27,21 +23,24 @@ If a roadmap item is a stub, **consider** opening a [GitHub issue](https://githu
@@ -64,51 +63,42 @@ If a roadmap item is a stub, **consider** opening a [GitHub issue](https://githu
### Migration
The community is working on a number of automated scripts to help you migrate to Foam. The main work of developing such a method involves exporting your notes, converting them to the Markdown format, and then making sure that the links between notes (if you had those) still work.
**[[todo]] This [[roadmap]] item needs more specification work.**
**[[todo]] This [[roadmap]] item needs more specification work.**
If you're interested in working on it, please start a conversation in [GitHub issues](https://github.com/foambubble/foam/issues).
## Notes
One of Roam's big features is the ability to find all instances of a reference, create a page for it and update all the references to link to the new page.
One of Foam's big features is the ability to find all instances of a reference, create a page for it and update all the references to link to the new page.
Implementing this is on the [[roadmap]], but for the time being you can achieve similar things by:
- `Cmd` + `Shift` + `F` ( `Ctrl` + `Shift` + `F` on Windows ) to find all the references, e.g. "Cat food"
- `Cmd` + `Shift` + `H` ( `Ctrl` + `Shift` + `F` on Windows ) to replace them with [[cat-food]].
- `Cmd` + `Shift` + `H` ( `Ctrl` + `Shift` + `H` on Windows ) to replace them with [[cat-food]].
- Click any of the references to create a new note.
[//begin]: # "Autogenerated link references for markdown compatibility"
You can use VS Code plugins such as [Mermaid](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-mermaid) to draw and preview diagrams in your content.
⚠️ Be aware that Mermaid diagrams don't automatically get rendered in published Foams in [[github-pages]], and would require you to eject to another static site generation approach that supports Mermaid plugins.
---
[[todo]] [[good-first-task]] **Help improve this recipe!**
[[todo]] [[good-first-task]] Suggestions for alternative diagramming approaches welcome
[//begin]: # "Autogenerated link references for markdown compatibility"
[github-pages]: github-pages "Github Pages"
[good-first-task]: good-first-task "Good First Task"
When using [[wiki-links]], you can find all notes that link to a specific note in the [VS Code Markdown Notes](https://marketplace.visualstudio.com/items?itemName=kortina.vscode-markdown-notes) **Backlinks Explorer**
When using [[wikilinks]], you can find all notes that link to a specific note in the [VS Code Markdown Notes](https://marketplace.visualstudio.com/items?itemName=kortina.vscode-markdown-notes) **Backlinks Explorer**
- Run `Cmd` + `Shift` + `P` (`Ctrl` + `Shift` + `P` for Windows), type "backlinks" and run the **Explorer: Focus on Backlinks** view.
- Keep this pane always visible to discover relationships between your thoughts
@@ -8,7 +8,8 @@ When using [[wiki-links]], you can find all notes that link to a specific note i
- Finding backlinks in published Foam workspaces via [[materialized-backlinks]] is on the [[roadmap]] but not yet implemented.
[//begin]: # "Autogenerated link references for markdown compatibility"
- Write out a new `[[wikilink]]` and `Cmd` + `Click` to create a new file and enter it.
- For keyboard navigation, use the 'Follow Definition' key `F12` (or [remap key binding](https://code.visualstudio.com/docs/getstarted/keybindings) to something more ergonomic)
-`Cmd` + `Shift` + `P` (`Ctrl` + `Shift` + `P` for Windows), execute `Foam: Create New Note` and enter a **Title Case Name** to create `Title Case Name.md`
- Add a keyboard binding to make creating new notes easier.
- The [[note-templates]] used by this command can be customized.
- You shouldn't worry too much about categorizing your notes. You can always [[search-for-notes]], and explore them using the [[graph-visualisation]].
[//begin]: # "Autogenerated link references for markdown compatibility"
[note-templates]: note-templates "Note Templates"
[search-for-notes]: ../recipes/search-for-notes "Search for Notes"
Visual Studio Code allows you to use your own CSS in the Markdown preview tab.
## Instructions
Custom CSS for the Markdown preview can be implemented by using the `"markdown.styles": []` setting in `settings.json`. The stylesheets can either be https URLs or relative paths to local files in the current workspace.
For example, to load a stylesheet called `Style.css`, we can update `settings.json` with the following line:
```
{
"markdown.styles": ["Style.css"]
}
```
## Foam elements
### Foam note & placeholder links
It is possible to custom style the links to a note or placeholder. The links are an `<a>` tag. For notes use the class `foam-note-link`, for placeholders use `foam-placeholder-link`.
### Cyclic inclusion warnings
Foams offers the functionality to include other notes in your note. This will be displayed in the preview tab. Foam recognises a cyclic inclusion of notes and will display a warning when detected. The following html is used and can be custom styled using the class `foam-cyclic-link-warning`.
You can add custom snippets whilst the default set of snippets are decided by following the below steps:
1.`Cmd` + `Shift` + `P` (`Ctrl` + `Shift` + `P` for Windows), type `snippets` and select `Preferences: Configure User Snippets`.
2. The command palette will remain in focus. Search for `markdown` and select the entry entitled `markdown.json (Markdown)`.
3. A JSON file will open. You can author your own snippets using the [documentation](https://code.visualstudio.com/docs/editor/userdefinedsnippets#_create-your-own-snippets) to help you, or if you're using a snippet shared by another Foam user then you can copy and paste it in, as the below GIF demonstrates:

To get started, you might consider replacing the entire contents of the `markdown.json` file opened by the steps above with the JSON in [this comment](https://github.com/foambubble/foam/pull/192#issuecomment-666736270).
Automatically create a Daily Note by executing the "Foam: Open Daily Note" command. If a Daily Note for today's date already exists, the command opens the existing note.

## Keyboard shortcut
The default keyboard shortcut for "Open Daily Note" is `alt`+`d`. This can be overridden using the [VS Code Keybindings editor](https://code.visualstudio.com/docs/getstarted/keybindings).
## Configuration
By default, Daily Notes will be created in a file called `yyyy-mm-dd.md` in the workspace root, with a heading `yyyy-mm-dd`.
These settings can be overridden in your workspace or global `.vscode/settings.json` file, using the [**dateformat** date masking syntax](https://github.com/felixge/node-dateformat#mask-options):
```jsonc
"foam.openDailyNote.directory":"journal",// a relative directory path will get appended to the workspace root. An absolute directory path will be used unmodified.
The above configuration would create a file `journal/note-2020-07-25.mdx`, with the heading `Journal Entry, Sunday, July 25`.
## Daily Note Templates
Daily notes can also make use of [templates](note-templates.md), by defining a special `.foam/templates/daily-note.md` template.
See [Note Templates](note-templates.md) for details of the features available in templates.
## Roam-style Automatic Daily Notes
Foam provides an option for automatically opening your Daily Note when you open your Foam workspace. You can enable it by specifying the following configuration in your `.vscode/settings.json`:
There are (too) many ways to commit your changes to source control:
- Using VS Code's own git integration
- The quick and easy way is to use the `Git: Commit All` command after editing files. The default Foam workspace settings will stage & sync all of your changes to the remote:
- Using GitDoc for [[automatic-git-syncing]]
- Whatever way you like to do it (CLI?)
[//begin]: # "Autogenerated link references for markdown compatibility"
[automatic-git-syncing]: ../recipes/automatic-git-syncing.md "Automatically Sync with Git"
Foam comes with a graph visualisation of your notes. To see the graph execute the `Foam: Show Graph` command.
The graph will:
- allow you to highlight a node by hovering on it, to quickly see how it's connected to the rest of your notes
- allow you to select one or more (by keeping `SHIFT` pressed while selecting) nodes by clicking on them, to better understand the structure of your notes
- allow you to navigate to a note by clicking on it while pressing `CTRL` or `CMD`
- automatically center the graph on the currently edited note, to immediately see it's connections
## Custom Graph Styles
Currently, custom graph styles are supported through the `foam.graph.style` setting.
In some situations it might be useful to include the content of another note in your current note. Foam supports this displaying within the vscode environment. Note, this does not work out-of-the-box for your publishing solutions.
## Including a note
Including a note can be done by adding an `!` before a wikilink defintion. For example `![[wikilink]]`.
## Custom styling
Displaying the inclusion of notes allows for some custom styling, see [[custom-markdown-preview-styles]]
## Future possibilities
Work on this feature is evolving and progressing. See the [[inclusion-of-notes]] proposal for the current discussion.
[//begin]: # "Autogenerated link references for markdown compatibility"
When you use `[[wikilinks]]`, the [foam-vscode](https://github.com/foambubble/foam/tree/master/packages/foam-vscode) extension will automatically generate [Markdown Link Reference Definitions](https://spec.commonmark.org/0.29/#link-reference-definitions) at the bottom of the file. This is done to make the content of the file compatible with various Markdown tools (e.g. parsers, static site generators, VS code plugins etc), which don't support `[[wikilinks]]`.
## Example
The following example:
```md
- [[wikilinks]]
- [[github-pages]]
```
...generates the following link reference definitions to the bottom of the file:
```md
[wikilinks]: wikilinks "Wikilinks"
[github-pages]: github-pages "GitHub Pages"
```
You can open the [raw markdown](https://foambubble.github.io/foam/features/link-reference-definitions.md) to see them at the bottom of this file
## Specification
The three components of a link reference definition are `[link-label]: link-target "Link Title"`
- **link label:** The link text to match in the surrounding markdown document. This matches the inner bracket of the double-bracketed `[[wikilink]]` notation
- **link destination** The target of the matched link
- By default we generate links without extension. This can be overridden, see [Configuration](#configuration) below
- **"Link Title"** Optional title for link (The Foam template has a snippet of JavaScript to replace this on the website at runtime)
## Configuration
You can choose to generate link reference definitions with or without file extensions, depending on the target, or to disable the generation altogether. As a rule of thumb:
- Links with file extensions work better with standard markdown-based tools, such as GitHub web UI.
- Links without file extensions work better with certain web publishing tools that treat links as literal urls and don't transform them automatically, such as the standard GitHub pages installation.
By default, Foam generates links without file extensions for legacy reasons, but this may change in future versions.
You can override this setting in your Foam workspace's `settings.json`:
Sometimes, you may want to ignore certain files or folders, so that Foam doesn't generate link reference definitions to them.
For instance, if you're using a local instance of [Jekyll](https://jekyllrb.com/), you may find that it writes copies of each `.md` file into a `_site` directory, which may lead to Foam generating references to them instead of the original source notes.
You can ignore the `_site` directory by adding the following to your `.vscode/settings.json`:
```json
"files.exclude": {
"**/_site": true
},
"files.watcherExclude": {
"**/_site": true
},
```
After changing the setting in your workspace, you can run the [[workspace-janitor]] command to convert all existing definitions.
[[todo]] _Implement a `foam.eclude
## Future improvements
See [[link-reference-definition-improvements]] for further discussion on current problems and potential solutions.
[//begin]: # "Autogenerated link references for markdown compatibility"
Foam supports note templates. Templates are a way to customize the starting content for your notes (instead of always starting from an empty note).
Note templates are files located in the special `.foam/templates` directory.
## Quickstart
Create a template:
* Run the `Foam: Create New Template` command from the command palette
* OR manually create a regular `.md` file in the `.foam/templates` directory

_Theme: Ayu Light_
To create a note from a template:
* Run the `Foam: Create New Note From Template` command and follow the instructions. Don't worry if you've not created a template yet! You'll be prompted to create a new template if none exist.
* OR run the `Foam: Create New Note` command, which uses the special default template (`.foam/templates/new-note.md`, if it exists)

_Theme: Ayu Light_
## Special templates
### Default template
The `.foam/templates/new-note.md` template is special in that it is the template that will be used by the `Foam: Create New Note` command.
Customize this template to contain content that you want included every time you create a note.
### Default daily note template
The `.foam/templates/daily-note.md` template is special in that it is the template that will be used when creating daily notes (e.g. by using `Foam: Open Daily Note`).
Customize this template to contain content that you want included every time you create a daily note.
## Variables
Templates can use all the variables available in [VS Code Snippets](https://code.visualstudio.com/docs/editor/userdefinedsnippets#_variables).
In addition, you can also use variables provided by Foam:
| `FOAM_SELECTED_TEXT` | Foam will fill it with selected text when creating a new note, if any text is selected. Selected text will be replaced with a wikilink to the new note. |
| `FOAM_TITLE` | The title of the note. If used, Foam will prompt you to enter a title for the note. |
| `FOAM_DATE_*` | `FOAM_DATE_YEAR`, `FOAM_DATE_MONTH`, etc. Foam-specific versions of [VS Code's datetime snippet variables](https://code.visualstudio.com/docs/editor/userdefinedsnippets#_variables). Prefer these versions over VS Code's. |
**Note:** neither the defaulting feature (eg. `${variable:default}`) nor the format feature (eg. `${variable/(.*)/${1:/upcase}/}`) (available to other variables) are available for these Foam-provided variables. See [#693](https://github.com/foambubble/foam/issues/693).
### `FOAM_DATE_*` variables
Foam defines its own set of datetime variables that have a similar behaviour as [VS Code's datetime snippet variables](https://code.visualstudio.com/docs/editor/userdefinedsnippets#_variables).
For example, `FOAM_DATE_YEAR` has the same behaviour as VS Code's `CURRENT_YEAR`, `FOAM_DATE_SECONDS_UNIX` has the same behaviour as `CURRENT_SECONDS_UNIX`, etc.
By default, prefer using the `FOAM_DATE_` versions. The datetime used to compute the values will be the same for both `FOAM_DATE_` and VS Code's variables, with the exception of the creation notes using the daily note template.
#### Relative daily notes
When referring to daily notes, you can use the relative snippets (`/+1d`, `/tomorrow`, etc.). In these cases, the new notes will be created with the daily note template, but the datetime used should be the relative datetime, not the current datetime.
By using the `FOAM_DATE_` versions of the variables, the correct relative date will populate the variables, instead of the current datetime.
For example, given this daily note template (`.foam/templates/daily-note.md`):
When the `/tomorrow` snippet is used, `FOAM_DATE_` variables will be populated with tomorrow's date, as expected.
If instead you were to use the VS Code versions of these variables, they would be populated with today's date, not tomorrow's, causing unexpected behaviour.
When creating notes in any other scenario, the `FOAM_DATE_` values are computed using the same datetime as the VS Code ones, so the `FOAM_DATE_` versions can be used in all scenarios by default.
## Metadata
Templates can also contain metadata about the templates themselves. The metadata is defined in YAML "Frontmatter" blocks within the templates.
| `filepath` | The filepath to use when creating the new note. If the filepath is a relative filepath, it is relative to the current workspace. |
| `name` | A human readable name to show in the template picker. |
| `description` | A human readable description to show in the template picker. |
Foam-specific variables (e.g. `$FOAM_TITLE`) can be used within template metadata. However, VS Code snippet variables are ([currently](https://github.com/foambubble/foam/pull/655)) not supported.
### `filepath` attribute
The `filepath` metadata attribute allows you to define a relative or absolute filepath to use when creating a note using the template.
If the filepath is a relative filepath, it is relative to the current workspace.
**Note:** While you can make use of the `filepath` attribute in [daily note](daily-notes.md) templates (`.foam/templates/daily-note.md`), there is currently no way to have `filepath` vary based on the date. This will be improved in the future. For now, you can customize the location of daily notes using the [`foam.openDailyNote` settings](daily-notes.md).
#### Example of relative `filepath`
For example, `filepath` can be used to customize `.foam/templates/new-note.md`, overriding the default `Foam: Create New Note` behaviour of opening the file in the same directory as the active file:
```yaml
---
# This will create the note in the "journal" subdirectory of the current workspace,
# regardless of which file is the active file.
foam_template:
filepath:'journal/$FOAM_TITLE.md'
---
```
#### Example of absolute `filepath`
`filepath` can be an absolute filepath, so that the notes get created in the same location, regardless of which file or workspace the editor currently has open.
The format of an absolute filepath may vary depending on the filesystem used.
These attributes provide a human readable name and description to be shown in the template picker (e.g. When a user uses the `Foam: Create New Note From Template` command):

### Adding template metadata to an existing YAML Frontmatter block
If your template already has a YAML Frontmatter block, you can add the Foam template metadata to it.
#### Limitations
Foam only supports adding the template metadata to *YAML* Frontmatter blocks. If the existing Frontmatter block uses some other format (e.g. JSON), you will have to add the template metadata to its own YAML Frontmatter block.
Further, the template metadata must be provided as a [YAML block mapping](https://yaml.org/spec/1.2/spec.html#id2798057), with the attributes placed on the lines immediately following the `foam_template` line:
```yaml
---
existing_frontmatter:"Existing Frontmatter block"
foam_template:# this is a YAML "Block" mapping ("Flow" mappings aren't supported)
name:My Note Template# Attributes must be on the lines immediately following `foam_template`
description:This is my note template
filepath:`journal/$FOAM_TITLE.md`
---
This is the rest of the template
```
Due to the technical limitations of parsing the complex YAML format, unless the metadata is provided this specific form, Foam is unable to correctly remove the template metadata before creating the resulting note.
If this limitation proves inconvenient to you, please let us know. We may be able to extend our parsing capabilities to cover your use case. In the meantime, you can add the template metadata without this limitation by providing it in its own YAML Frontmatter block.
### Adding template metadata to its own YAML Frontmatter block
You can add the template metadata to its own YAML Frontmatter block at the start of the template:
```yaml
---
foam_template:
name:My Note Template
description:This is my note template
filepath:`journal/$FOAM_TITLE.md`
---
This is the rest of the template
```
If the note already has a Frontmatter block, a Foam-specific Frontmatter block can be added to the start of the template. The Foam-specific Frontmatter block must always be placed at the very beginning of the file, and only whitespace can separate the two Frontmatter blocks.
Foam helps you to find orphans: notes that have neither forward links nor backlinks.
Orphans can be found in the Orphans panel.
Two settings allows you to control the behaviour of the Orphans panel:
-`foam.orphans.exclude`: list of glob patterns that will be used to exclude directories. For example, a value of `["journal/**/*"]` would exclude your daily notes.
-`foam.orphans.groupBy`: sets the default view mode of the Orphans panel: either groups by folder (by default), or lists all orphans. The view can be toggled on the fly from the panel, but it won't overwrite the setting.
To store your personal knowledge graph in markdown files instead of a database, we need some additional tooling to create and maintain relationships with notes.
**Foam Janitor** (inspired by Andy Matuschak's [note-link-janitor](https://github.com/andymatuschak/note-link-janitor)) helps you migrate existing notes to Foam, and maintain your Foam's health over time.
Currently, Foam's Janitor helps you to:
- Ensure your [[link-reference-definitions]] are up to date
- Ensure every document has a well-formatted title (required for Markdown Links, Markdown Notes, and Foam Gatsby Template compatibility)
In the future, Janitor can help you with
- Updating [[materialized-backlinks]]
- Lint, format and structure notes
- Rename and move notes around while keeping their references up to date.
## Using Janitor from VS Code (Experimental)
Execute the "Foam: Run Janitor" command from the command palette.
> ⚠️ Improvements to this documentation are welcome!
The Janitor can be installed from [NPM](https://www.npmjs.com/) and executed as a standalone CLI tool:
```sh
> npm install -g foam-cli
> foam janitor path/to/workspace
```
You can run the Janitor as a git hook on every commit to ensure your workspace links are up to date. This can be especially helpful if you edit your markdown documents from other apps.
You can also run the Janitor from a GitHub action to ensure that all changes coming to your workspace are up to date. This can be useful when editing your Foam notes from mobile (i.e. via [GitJournal](https://gitjournal.io)), or your Foam has multiple contributors and you want to ensure that all changes are correctly integrated.
[//begin]: # "Autogenerated link references for markdown compatibility"
This file is an example of a valid Foam file. Essentially it's just a markdown file with a bit of additional support for mediawiki-style `[[wiki-links]]`.
Here are a few specific constraints, mainly because our tooling is a bit fragmented. Most of these should be eventually lifted, and our requirement should just be "Markdown with `[[wiki-links]]`:
- **It needs to have a single top level `# Heading`.**
- This will be used as document title.
- [[decision-needed]] Do we need it?
- [[decision-needed]] How much to deviate from just markdown
- **File name should not contain spaces,** e.g. `foam-file-format.md` is a valid name, but `Foam File Format.md` is not.
- This is a temporary limitation and will be lifted in future versions.
- Technically this actually works already, but may have some edge cases you don't want to deal with if you can avoid it.
- **File name should have extension `.md` or `.markdown`**
- This is a temporary limitation and will be lifted in future versions.
- At least `.mdx` will be supported, but ideally we'll support any file that you can map to `Markdown` language mode in VS Code
- **In addition to normal Markdown Links syntax you can use `[[media-wiki]]` links.**
- When you do, the [foam-vscode](https://github.com/foambubble/foam/tree/master/packages/foam-vscode) extension will automatically generate [Markdown Link Reference Definitions](https://spec.commonmark.org/0.29/#link-reference-definitions) at the bottom of the file.
- Here's an example:
- [[wiki-links]]
- [[github-pages]]
- This will generate the following references:
```md
[wiki-links]: wiki-links "Wiki Links"
[github-pages]: github-pages "Github Pages"
```
- The three components are `[link-label]: link-target "Link Title"
- **link label:** The link text to match in the surrounding markdown document. This matches the inner bracket of the double-bracketed `[[wiki-link]]` notation
- **link destination** The target of the matched link
- Right now we generate link destinations without file extension. This is a choice, see [discussion here](https://foambubble.github.io/foam/wiki-links#why-dont-wiki-links-work-on-github).
- **"Link Title"** Optional title for link (The Foam template has a snippet of JavaScript to replace this on the website at runtime)
- Open the [raw markdown](https://raw.githubusercontent.com/foambubble/foam/master/foam-file-format.md) to see them at the bottom of this file
- In the near future, these can be batch generated for all workspace files (WIP)
- For the time being, if you want to get [[wiki-links]] support across all files, you'll need to generate the link reference definitions yourself.
- If you end up writing a batch job for this, please share your solution, as this is something we'll need to implement soon!
[//begin]: # "Autogenerated link references for markdown compatibility"
- [Links/Graphs/BackLinks don't work. How do I enable them?](#linksgraphsbacklinks-dont-work-how-do-i-enable-them)
- [I don't want Foam enabled for all my workspaces](#i-dont-want-foam-enabled-for-all-my-workspaces)
## Links/Graphs/BackLinks don't work. How do I enable them?
- Ensure that you have all the [[recommended-extensions]] installed in Visual Studio Code
- Reload Visual Studio Code by running `Cmd` + `Shift` + `P` (`Ctrl` + `Shift` + `P` for Windows), type "reload" and run the **Developer: Reload Window** command to for the updated extensions take effect
- Check the formatting rules for links on [[foam-file-format]], [[wikilinks]] and [[link-formatting-and-autocompletion]]
## I don't want Foam enabled for all my workspaces
Any extension you install in Visual Studio Code is enabled by default. Give the philosophy of Foam it works out of the box without doing any configuration upfront. In case you want to disable Foam for a specific workspace, or disable Foam by default and enable it for specific workspaces, it is advised to follow the best practices as [documented by Visual Studio Code](https://code.visualstudio.com/docs/editor/extension-marketplace#_manage-extensions)
[//begin]: # "Autogenerated link references for markdown compatibility"
There are (too) many ways to commit your changes to source control:
- Using VS Code's own git integration
- Using GitLens (included in Foam for inline blame)
- Whatever way you like to do it (CLI?)
The quick and easy way is to use the Git: Commit All command after editing files. The default Foam workspace settings will stage & sync all of your changes to the remote:
- The [Foam template](https://github.com/foambubble/foam-template) is **GitHub Pages** ready, all you have to do is [turn it on in your repository settings](https://guides.github.com/features/pages/).
- The default GitHub Pages template is called [Primer](https://github.com/pages-themes/primer). See Primer docs for how to customise html layouts and templates.
- GitHub Pages is built on [Jekyll](https://jekyllrb.com/), so it supports things like permalinks, front matter metadata etc.
[[todo]] [[good-first-task]] Improve this documentation
[//begin]: # "Autogenerated link references for markdown compatibility"
[todo]: todo "Todo"
[good-first-task]: good-first-task "Good First Task"
**[[todo]] This [[roadmap]] item needs more specification work.**
If you're interested in working on it, please start a conversation in [GitHub issues](https://github.com/foambubble/foam/issues).
## Notes
- We should consider moving to gatsby, similar to [Foam Gatsby Template](https://mathieudutour.github.io/foam-gatsby-template/)
[//begin]: # "Autogenerated link references for markdown compatibility"
[todo]: todo "Todo"
[roadmap]: roadmap "Roadmap"
[//end]: # "Autogenerated link references"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.