Skip to content
This repository has been archived by the owner on Jul 6, 2021. It is now read-only.

RFC: Materialized links #4

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

jevakallio
Copy link
Contributor

@jevakallio jevakallio commented Jul 31, 2020

Rendered RFC

https://github.com/foambubble/rfcs/blob/rfc/materialized-backlinks/docs/0000-materialized-links.md

TL;DR;

This RFC describes a solution to much requested features:

It also describes a nice-to-have feature, which we'll get (almost for free) as a by-product:

  • Link lists

Feedback welcome! Discord user @BSPrick has indicated interest in implementing this feature, which is why I've written the RFC to guide implementation.


### Backlinks

You can already view backlinks inside the Markdown Notes backlinks explorer. Materializing backlinks adds the following benefits:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

@jsjoeio jsjoeio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great writeup @jevakallio !

Overall, I think this will be a nice improvement to Foam. I only had one concern (see comment).

Comment on lines +158 to +160
The extension will replace the entire immediate content of the section following the H2-heading, either until:

- Next scope (next H2 or H1 heading)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we go to implement this, I think we should be careful here. I don't know how I feel about it replacing everything until it hits the next scope. Rather than relying on something user-created (like the next H2 or H1), I would almost rather rely on something from Foam.

What if instead we put the list inside it's own fence using HTML comments similar to how [github-markdown-toc](https://github.com/ekalinin/github-markdown-toc) does it like so:

Table of contents
=================

<!--ts-->
   * [gh-md-toc](#gh-md-toc)
   * [Table of contents](#table-of-contents)
   * [Installation](#installation)
   * [Usage](#usage)
      * [STDIN](#stdin)
      * [Local files](#local-files)
      * [Remote files](#remote-files)
      * [Multiple files](#multiple-files)
      * [Combo](#combo)
      * [Auto insert and update TOC](#auto-insert-and-update-toc)
      * [GitHub token](#github-token)
   * [Tests](#tests)
   * [Dependency](#dependency)
<!--te-->

Notice the ts comment for table start and te for table end.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it that easy to have a comment in md?! 🤯
I am actually happy with either the section or comment approach, once we go for one we can use that approach across our generated code (e.g. also for link definitions)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right!?

I am actually happy with either the section or comment approach, once we go for one we can use that approach across our generated code (e.g. also for link definitions)

Agreed! Consistency is 🔑


Links are formatted as traditional Markdown links `[Title](target.md)`

- This prevents a materialized backlink being treated as a regular link, which would cause every linking relationship automatically becoming two-way

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I understand, does this means that it's not allowed for someone to use the [Title](path/to/doc.md) syntax for local files?

Comment on lines +158 to +160
The extension will replace the entire immediate content of the section following the H2-heading, either until:

- Next scope (next H2 or H1 heading)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it that easy to have a comment in md?! 🤯
I am actually happy with either the section or comment approach, once we go for one we can use that approach across our generated code (e.g. also for link definitions)


- Mucking about user files can be fickle
- Non-trivial effort to implement and test the feature.
- (Current implementation): Using headings as link section delimiters can lead to destructivev updates, if user writes any content inside a Foam-managed section

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- (Current implementation): Using headings as link section delimiters can lead to destructivev updates, if user writes any content inside a Foam-managed section
- (Current implementation): Using headings as link section delimiters can lead to destructive updates, if user writes any content inside a Foam-managed section

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants