Embedding One Note in Another

[RoyiAvital]

I think a killer feature would be able to have the option to embed a note in another.

Something like [[[embed: <ZettleID>]]] / [[embed: <ZettleID>]] or ![[[<ZettleID>]]] / ![[<ZettleID>]] (Embracing Julia's notation for inplace function).
Graph wise it will create a link by the link type.
For the web page it will embed the note as is into another.

An option to add one level to each header would be great as well.

The logic of that is we need self contained pages but sometimes 2 different notes (Think Math proofs or something) needs the same sub proof in them.

So just like we don't write code twice, it would be great to use notes as functions which spits out the text.
Lowering the header could be thought as name space.

[srid]

This was requested before and got rejected #184 - however I'd be open to accept a PR for this feature as a plugin implementation (not part of core neuron). It will require some architectural discussion first, however, as neuron's current plugin mechanism is pretty nascent and evolving.

[RoyiAvital]

I do think embedding is atomic operation.
The whole idea of the graph is connection and don't do the same twice.

Linking is great, but if it is something the text is based on it means you either get out of the scope by clicking it or have to remember it.

By the way, an intermediate solution could be based on your idea for Impulse.
If in the HTML website, clicking on a link will have an option to open to the right (Like in Andy Matuschak's Notes) then it would make connections while the reader stays in the scope of the current note.
Maybe in [[]] links there should be a small indicator to open thing next to instead of moving into that page?
Seems like elegant thing to have in the site generator.

[srid]

In regards to ![[...]] syntax, see #531 (comment)

[jaygray0919]

IMHO links should be explicit. My concern is that a zettel-in-zettel obscures the relationships. Let's look at two structures in the D3 world: flare.json and miserables.json. The links are explicit in both. In flare.json, the relationships are expressed as supertype and subtype. In miserables.json, relationships are ordered pairs. They are easy to see, to read, and to logical verify. D3 them makes it easier to understand with visualization. IMHO one should be able to export the structure of a Neuron instance and read the exported data from another processor (like D3). If the approach advocated above makes that export process difficult, it should not be done.