Overlay configuration proposal

[hi-learn-triz-and-usit]

I tried to follow the GHC proposal template, but I got a little burned out at the end.

Rendered

[srid]

There are a couple interesting things this proposal adds, or facilitate adding, on top, namely:

• Ability to compose notebooks automatically including their layers
• Ability to support "remote notebooks" (eg: github:srid/emanote-themes to pull in themes automatically, maybe via nix flakes or direct git clone, and then using its layers automatically).
  • I prefer Nix but something like .gitmodules would also work. Reproducibility is important.

---

Note also these related feature requests in neuron (which emanote's notebook layers feature automatically addresses):

• Multi site RFC neuron#339
• Using a subset as blog neuron#222 (comment)

---

Initial verdict on this RFC: CLI arguments (#35) are good enough for now. If/when I reach a stage where I am thinking to myself that "I cannot live without composable layer configuration feature" (and I do not think that at all right now) and/or users start asking for it (with individual examples/ rationale to boot) more, then I would consider adding some well thought-out implementation of this RFC in emanote. Until then, specify the multiple-notebooks manually in the CLI (#35) and let one's usage over time dictate any further inputs to this RFC. Besides, the "merge" semantics for individual files types when using multiple layers are in their proto form right now (yaml is json-merged, but .md is replaced), and not fully fleshed out yet (I'm thinking daily notes should be merged). So that's another reason to consider revisiting this RFC much later in time.

[srid]

the "merge" semantics for individual files types when using multiple layers [...] not fully fleshed out yet (I'm thinking daily notes should be merged)

That specific example of daily notes can be configured like this: take a list of pairs (FilePattern, MergeSemantic), i.e., [("Daily/**/*.md", Merge)] and apply those merge semantics overriding emanote defaults (thus, all Markdown files will use the "Replace" semantic, except for daily notes which get merged).

To support this in the CLI, we may imagine adding an option, eg: emanote --merge-semantics='Daily/**/*.md:merge' path1 path2 .... Alternatively -- and this certainly would be more "cleaner" (esp. as we are no longer specifying merely a list of paths) as @hi-learn-triz-and-usit argues -- they may be specified in the layer configuration file. Thus, the layer configuration file will contain not only a list of paths (local or remote), but also the configuration for how to merge individual file types (overriding emanote's default).

Open questions:

• are there any other kinds of things that can (only) be configured at the layer configuration level?
• Like the aforementioned daily notes example, what other relevant real-world use-cases exist? I guess we'll know over time.

[srid]

are there any other kinds of things that can (only) be configured at the layer configuration level?

Another thing that belongs in layer configuration:

• File ignore patterns
  • The default is to ignore all .* paths (dotfiles), but we might want to let the user customize that.
  • As an aside (and I haven't thought this in detail), this might be subsumed under the aforementioned 'merge semantics' (where the semantic here == "ignore")
    • That said, merge semantics are one level higher than layers, whereas ignore pattern could be configured at individual layer level (unless we enforce it at the global level, which however doesn't make much sense)

@hi-learn-triz-and-usit Okay, so I'm more convinced that your overlay configuration is a worthy concept to implement. But it should remain optional. And to be implemented on a 'as needed' basis.

[srid]

Since this is linked in #37 (and can be reviewed at any time latter), I'll close this PR for now, as it hasn't seen any recent activity.