much improved side-note referencing

7 files changed, 45 insertions, 41 deletions

diff --git a/root/articles/mmmfs/ba_log/2019-12-20/text$markdown+sidenotes.md b/root/articles/mmmfs/ba_log/2019-12-20/text$markdown+sidenotes.md
index 7d592a0..3de1a9c 100644
--- a/root/articles/mmmfs/ba_log/2019-12-20/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/ba_log/2019-12-20/text$markdown+sidenotes.md
@@ -25,7 +25,7 @@ For example the following BibTeX is rendered like this:
 
 <mmm-embed nolink path="../../references/inkandswitch" facet="markdown"></mmm-embed>
 
-> <mmm-embed raw path="../../references/inkandswitch"></mmm-embed>
+> <mmm-embed wrap="raw" path="../../references/inkandswitch"></mmm-embed>
 
 I also added a special override that links to 
 BibTeX files by placing the citation in a sidenote, and adding a footnote indicator in-text.
diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
index abde2fb..8c6404e 100644
--- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
@@ -13,7 +13,7 @@ context:
 The system has proven itself perfect for publishing small- and medium-size articles and blog posts, especially for its
 ability to flexibly transclude content from any source. This includes diagrams (such as in this thesis),
 videos (as in the documentation in the appendix), but also less conventional media such as
-interactive diagrams <mmm-link path="../references/aspect-ratios"></mmm-link> or twitter postings.
+interactive diagrams<mmm-embed path="../references/aspect-ratios" wrap="sidenote"></mmm-embed> or twitter postings.
 
 On the other hand, the development of the technical framework for this very thesis has posed greater challenges.
 In particular, the implementation of the reference and sidenote systems are brittle and uninspiring.
@@ -93,7 +93,7 @@ This way, *converts* can be added locally if they only make sense within a given
 Additionally it could be made possible to use this mechanism to locally override *converts* inherited from
 further up in the tree, for example to specialize types based on their context in the system.
 
-<div class="sidenote">see also <mmm-embed raw path="../references/alternatives-to-trees"></mmm-embed>
+<div class="sidenote">see also <mmm-embed wrap="raw" path="../references/alternatives-to-trees"></mmm-embed>
 </div>The biggest downside to this approach would be that it  presents another pressure factor for, while also
 reincforcing, the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
 
@@ -106,7 +106,7 @@ experience developed for them. All of the code that lives outside of the mmmfs t
 to them, actively limiting their understanding, and thereby the customizability, of the system.
 
 This weakness represents a failure to (fully) implement the quality of a "Living System" as proposed by
-*Ink and Switch*<mmm-link path="../references/inkandswitch"></mmm-link>.
+*Ink and Switch*<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>.
 
 In general however, some portion of code may always have to be left outside of the system.
 This also wouldn't necessarily represent a problem, but in this case it is particularily relevant
diff --git a/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md b/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md
index a427ae8..cce348c 100644
--- a/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md
@@ -42,7 +42,7 @@ type to convert to a full reference format (to `mmm/dom`) and to an inline side-
 (`mmm/dom+link`) that can be transcluded using the `<mmm-link>` pseudo-tag.
 
 For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`,
-which generates links to the ACM Digital Library<mmm-link path="../references/acm-dl"></mmm-link>
+which generates links to the ACM Digital Library<mmm-embed path="../references/acm-dl" wrap="sidenote"></mmm-embed>
 API for accessing BibTeX citations for documents in the library.
 This means that it is enough to store the link to the ACM DL entry in mmmfs,
 and the reference will automatically be fetched (and track potential remote corrections).
diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
index ec08ec4..0e4d9a3 100644
--- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
@@ -9,7 +9,7 @@ qualities
 ---------
 
 *Ink and Switch* suggest three qualities for tools striving to support
-end-user programming<mmm-link path="../references/inkandswitch"></mmm-link>:
+end-user programming<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>:
 
 - *Embodiment*, i.e. reifying central concepts of the programming model as more concrete, tangible objects
   in the digital space (for example through visual representation),
@@ -29,8 +29,8 @@ thoughts in.
 modularity
 ----------
 
-The *UNIX Philosophy* <mmm-link path="../references/unix"></mmm-link> describes the software design paradigm
-pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The
+The *UNIX Philosophy*<mmm-embed path="../references/unix" wrap="sidenote"></mmm-embed> describes the software design
+paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The
 concepts are considered quite influental and are still notably applied in the Linux community. Many attempts at
 summaries exist, but the following includes the pieces that are especially relevant even today:
 
@@ -58,7 +58,7 @@ If users are to store their information and customized behaviour in such an arch
 present in order to assemble more complex solutions out of such parts. Therefore static content should be able to be
 linked to (as envisioned for the *Memex*, see above), but also to be <span class="sidenote">The term <i>transclusion</i>
 refers to the concept of including content from a separate document, possibly stored remotely, by reference rather than
-by duplication. See also <mmm-embed raw path="../references/transclusion"></mmm-embed></span>*transcluded*,
+by duplication. See also <mmm-embed wrap="raw" path="../references/transclusion"></mmm-embed></span>*transcluded*,
 to facilitate the creation of flexible data formats and interactions, such that e.g. a slideshow slide can include
 content in a variety other formats (such as images and text) from anywhere else in the system. Behaviours also should be
 able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs. For
@@ -84,7 +84,7 @@ in other words: be able to program.
 
 While there is an ongoing area of research focusing on the development of new programming paradigms, 
 methodologies and tools that are more accessible and cater to the wide
-range of end-users<mmm-link path="../references/subtext"></mmm-link>,
+range of end-users<mmm-embed path="../references/subtext" wrap="sidenote"></mmm-embed>,
 in order to keep the scope of this work appropriate,
 conventional programming languages are used for the time being.
 Confidence is placed in the fact that eventually more user-friendly languages will be available and,
diff --git a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
index ebbe51c..62b21a0 100644
--- a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
@@ -9,7 +9,8 @@ other systems at the time, as well as the systems we use currently, is that the
 directly known to the system.
 
 In a retrospective analysis of the Xerox Star's impact on the computer
-industry<mmm-link path="../references/xerox-star" ></mmm-link>, the desktop metaphor is described as follows:
+industry<mmm-embed path="../references/xerox-star" wrap="sidenote"></mmm-embed>, the desktop metaphor is described as
+follows:
 
 > In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs.
 > They do not "invoke a text editor", they "open a document".
@@ -34,13 +35,13 @@ ordering or the defaut view mode of a folder for example.
 <p><i>How systems influenced later systems. This graph summarizes how various systems related to Star have influenced
 one another over the years. Time progresses downwards. Double arrows indicate direct successors (i.e.,
 follow-on versions). [...]</i></p>
-<mmm-embed raw path="../references/xerox-star"></mmm-embed></div>
+<mmm-embed wrap="raw" path="../references/xerox-star"></mmm-embed></div>
 <mmm-embed nolink path="star-graph"></mmm-embed>
 
 The earliest indirect influence for the Xerox Alto and many other systems of its time, was the *Memex*.
-The *Memex* is a hypothetical device and system for knowledge management. Proposed by Vannevar Bush in 1945<mmm-link
-path="../references/memex"></mmm-link>, the concept predates much of the technology that later was used to implement
-many parts of the vision.
+The *Memex* is a hypothetical device and system for knowledge management. Proposed by Vannevar Bush in 1945<mmm-embed
+path="../references/memex" wrap="sidenote"></mmm-embed>, the concept predates much of the technology that later was used
+to implement many parts of the vision.
 
 While the article extrapolates from existing technology at the time, describing at times
 very concrete machinery based on microfilm and mechanical contraptions, many of the conceptual predictions became
@@ -50,18 +51,19 @@ One of the most innovative elements of Bush's predictions is the idea of technol
 connected information, which would later be known and created as *hypertext*. While hypertext powers the majority of
 today's internet, many of the advantages that Bush imagined have not carried over into the personal use of computers.
 There are very few tools for creating personal, highly-interconnected knowledgebases, even though this is technically
-feasible, and a proven concept (exemplified for example by the massively successful online encyclopedia *Wikipedia*<mmm-link
-path="../references/wikipedia"></mmm-link>).
+feasible, and a proven concept (exemplified for example by the massively successful online encyclopedia
+*Wikipedia*<mmm-embed path="../references/wikipedia" wrap="sidenote"></mmm-embed>).
 
 While there are little such tools available today, one of the systems that could be said to have come closest to a
 practical implementation of such a Memex-inspired system for personal use might be Apple's *HyperCard*.
 
-In a live demonstration<mmm-link path="../references/hypercard"></mmm-link>, the creators of the software showcase
-a system of stacks of cards that together implement, amongst others, a calendar (with yearly and weekly views), a
-list of digital business cards for storing phone numbers and addresses, and a todo list. However these stacks of
-cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in meaningful ways,
-such as jumping to the card corresponding to a specific day from the yearly calendar view, or automatically looking
-up the card corresponding to a person's first name from a mention of the name in the text on a different card.
+In a live demonstration<mmm-embed path="../references/hypercard" wrap="sidenote"></mmm-embed>, the creators of the
+software showcase a system of stacks of cards that together implement, amongst others, a calendar (with yearly and
+weekly views), a list of digital business cards for storing phone numbers and addresses, and a todo list. However these
+stacks of cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in
+meaningful ways, such as jumping to the card corresponding to a specific day from the yearly calendar view, or
+automatically looking up the card corresponding to a person's first name from a mention of the name in the text on a
+different card.
 
 Alongside Spreadsheets, *HyperCard* remains one of the most successful implementations of end-user programming, even
 today. While it's technical abilities have been long matched and surpassed by other software (such as the ubiquitous
diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
index aa09173..9978fcf 100644
--- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
@@ -34,15 +34,16 @@ Some notable mechanism are:
 - Many file-formats specify a specific data-pattern either at the very beginning or very end of a given file.
   On unix systems the `libmagic` database and library of these so-called *magic constants* is commonly used to guess
   the file-type based on these fragments of data.
-- on UNIX systems, files to be executed are checked by a variety of methods<mmm-link path="../references/linux-exec">
-  </mmm-link> in order to determine which format would fit. For example, script files, the "shebang" symbol, `#!`, can
-  be used to specify the program that should parse this file in the first line of the file.
+- on UNIX systems, files to be executed are checked by a variety of methods<mmm-embed path="../references/linux-exec"
+  wrap="sidenote"></mmm-embed> in order to determine which format would fit. For example, script files, the "shebang"
+  symbol, `#!`, can be used to specify the program that should parse this file in the first line of the file.
  
 It should be clear already from this short list that to mainstream operating systems, as well as the applications
 running on them, the format of a file is almost completely unknown and at best educated guesses can be made.
 
 Because these various mechanisms are applied at different times by the operating system and applications,
-it is possible for files to be labelled as or considered as being in different formats at the same time by different components of the system.
+it is possible for files to be labelled as or considered as being in different formats at the same time by different
+components of the system.
 <div class="sidenote" style="margin-top: -5rem;">
 The difference between changing a file extension and converting a file between two formats is commonly unclear to users,
 see for example <a href="https://askubuntu.com/questions/166602/why-is-it-possible-to-convert-a-file-just-by-renaming-its-extension">
@@ -52,7 +53,8 @@ Why is it possible to convert a file just by renaming it?</a>, https://askubuntu
 This leads to confusion about the factual format of data among users, but can also pose a serious security risk:
 Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable
 by one software component, while a security mechanism meant to detect such code determines the same file to be a
-legitimate image<mmm-link path="../references/poc-or-gtfo"></mmm-link> (the file may in fact be valid in both formats).
+legitimate image<mmm-embed path="../references/poc-or-gtfo" wrap="sidenote"></mmm-embed> (the file may in fact be valid
+in both formats).
 
 In mmmfs, the example above might look like this instead:  
 <mmm-embed path="tree_mmmfs">schematic view of an example mmmfs tree</mmm-embed>
diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
index 4bc9cd4..c3eb637 100644
--- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
@@ -19,9 +19,9 @@ This focus on applications as the primary unit of systems can be seen as the roo
 
 For one, since applications are the products companies produce, and software represents a market of users,
 developers compete on features integrated into their applications. To stay relevant, monlithic software or software
-suites tend to accrete features rather then modularise and delegate to other software<mmm-link
-path="../references/appliances"></mmm-link>. This makes many software packages more complex and unintuitive than they
-need to be, and also cripples interoperability between applications and data formats.
+suites tend to accrete features rather then modularise and delegate to other software<mmm-embed wrap="sidenote"
+path="../references/appliances"></mmm-embed>. This makes many software packages more complex and unintuitive than
+they need to be, and also cripples interoperability between applications and data formats.
 
 Because applications are incentivised to keep customers, they make use of network effects to keep customers locked-in.
 This often means re-implementing services and functionality that is already available to users,
@@ -45,8 +45,8 @@ the paths and abilities that the developers anticipated and deemed useful.
 The application-centric computing metaphor treats applications as black boxes, and provides no means to understand,
 customize or modify the behaviour of apps, intentionally obscuring the inner-workings of applications and
 completely cutting users off from this type of ownership over their technology. While the trend seems to be to further
-hide the way desktop operating systems work <mmm-link path="../references/osx-files"></mmm-link>, mobile systems like
-Apple's *iOS* already started out as such so-called *walled gardens*.
+hide the way desktop operating systems work<mmm-embed path="../references/osx-files" wrap="sidenote"></mmm-embed>,
+mobile systems like Apple's *iOS* already started out as such so-called *walled gardens*.
 
 cloud computing
 ---------------
@@ -63,18 +63,18 @@ to license changes, updates modifiying, restricting or simply removing past func
 software solutions and ecosystems store the users' data in the cloud, often across national borders, where legal and
 privacy concerns are intransparently handled by the companies. If a company, for any reason, is unable or unwanting to
 continue servicing a customer, the users data may be irrecoverably lost (or access prevented). This can have serious
-consequences<mmm-link path="../references/adobe"></mmm-link>, especially for professional users, for whom an inability
-to access their tools or their cloud-stored data can pose an existential threat.
+consequences<mmm-embed path="../references/adobe" wrap="sidenote"></mmm-embed>, especially for professional users, for
+whom an inability to access their tools or their cloud-stored data can pose an existential threat.
 
 inert data (formats)
 --------------------
 
-Cragg coins the term "inert data"<mmm-link path="../references/super-powers"></mmm-link> for the data created, and
-left behind, by apps and applications in the computing model that is currently prevalent: Most data today is either
-intrinsically linked to one specific application, that controls and limits access to the actual information, or even
-worse, stored in the cloud where users have no direct access at all and depend soley on online tools that require a
-stable network connection and a modern browser, and that could be modified, removed or otherwise negatively impacted
-at any moment.
+Cragg coins the term "inert data"<mmm-embed path="../references/super-powers" wrap="sidenote"></mmm-embed> for the data
+created, and left behind, by apps and applications in the computing model that is currently prevalent: Most data today
+is either intrinsically linked to one specific application, that controls and limits access to the actual information,
+or even worse, stored in the cloud where users have no direct access at all and depend soley on online tools that
+require a stable network connection and a modern browser, and that could be modified, removed or otherwise negatively
+impacted at any moment.
 
 Aside from being inaccesible to users, the resulting complex proprietary formats are also opaque and useless to other
 applications and the operating system, which often is a huge missed opportunity: