Diagramme (Mermaid)

Wie es funktioniert

Mermaid-Diagramme. Ein ```mermaid-Zaun mit einem Flussdiagramm (flowchart/graph, in allen vier Richtungen), einem Sequenzdiagramm (sequenceDiagram) oder einem Kreisdiagramm (pie) wird im Lesemodus, in der exportierten Datei und in den Antworten von Notizen fragen als Diagramm gezeichnet — und von dort kommen die meisten Diagramme. Die Zeichnung folgt dem Thema der Notiz (Tinte, Papier und Akzent) und passt so in beiden Themes zum umgebenden Text. In der formatierten Bearbeitung — dem Standardmodus — wird das Diagramm ebenfalls gezeichnet, mit der Blockleiste darüber (kopieren, bearbeiten, löschen). Bearbeiten öffnet unten eine Leiste mit dem Quelltext: die Notiz ist gesperrt, solange sie offen ist, und die Zeichnung wird beim Tippen neu gezeichnet; Schließen übernimmt (es gibt kein Speichern und kein Abbrechen), Strg+Z macht die ganze Änderung in einem Schritt rückgängig, und ein leeres Feld entfernt den Block. Im geteilten Modus setzt ein Klick auf das Diagramm den Cursor auf den Zaun im Rohtext. Im Texteditor bleibt alles Text: Strg+E zeigt das Diagramm. In einem Listeneintrag bleibt das Diagramm — ebenso die SMILES-Struktur, die Blockformel, [files] und ![[Notiz]] — in der formatierten Bearbeitung Text und erscheint im Lesemodus gezeichnet: Dort hätte das Aufzählungszeichen des Eintrags keinen Weg zurück in die Datei.

Subgraphen (subgraph … end, auch verschachtelt) werden zu Kästen mit Titel, und Kanten überqueren den Rand ausgehend vom echten Knoten; die id eines Subgraphen kann ebenfalls Endpunkt einer Kante sein (sub --> X). Die vom Autor deklarierten Farben gelten: classDef, class, :::klasse und style (Füllung, Rand, Breite, Strichelung und Textfarbe). Zum Anfangen: Einfügen → Diagramm (Mermaid) in der Notizleiste — es fügt ein fertiges Gerüst für den gewählten Typ ein. Das Menü bietet die sechs meistgenutzten direkt an; Alle Diagramme… öffnet eine Auswahl mit allen 33, gruppiert nach Zweck, mit Suche (nach Name oder nach dem, was das Diagramm zeigt) und einer gezeichneten Vorschau von jedem — es sind 33 Zeichnungen, und die Zeichnung zu sehen entscheidet schneller als den Namen zu lesen. Auch das Frontmatter des Diagramms — der Block zwischen --- vor der ersten Zeile — wird gelesen: title wird zum Titel über der Zeichnung (ein title im Rumpf gewinnt), und die config-Schlüssel, die LightNote kennt, erreichen das Diagramm (gitGraph.mainBranchName, gantt.displayMode und die von packet: bitsPerRow, bitOrder: descending — das die Zeile spiegelt — und showBits: false); was es nicht kennt, wird ignoriert, ohne die Notiz abzulehnen.

Sequenz, Entitäten, Klassen und Zustände

Im Sequenzdiagramm gelten participant/actor (mit as), die Pfeilformen (->>, -->>, -x, -)), die Aktivierung (+/- und activate/deactivate), Notizen (Note left of/right of/over), die Blöcke loop/alt/else/opt/par und autonumber. Was noch nicht gezeichnet wird — andere Diagrammtypen —, erscheint weiterhin als Codeblock; direction innerhalb eines Subgraphen und linkStyle werden ignoriert. Die Knoten-Syntax von Mermaid v11 (A@{ shape: rounded, label: "Text" }) wird gelesen, und der Formen-Katalog von v11 wird gezeichnet: doc, lin-doc, docs, tag-rect, win-pane, hourglass, bolt, flag, das… — jede ist das Symbol, das ihr Name nennt, und keine wird zum Rechteck, denn ein Rechteck anstelle eines Dokuments wäre ein anderes Diagramm. Ein Name, den Mermaid nicht hat, lässt das Diagramm wieder zum Codeblock werden, mit Angabe der Zeile. Die Kanten-ID (A e1@--> B) und e1@{ animate: true } werden akzeptiert und ignoriert: Die Animation wird nicht gezeichnet. Ein typisierter Teilnehmer (participant DB@{ "type": "database" }) zeichnet das UML-Symbol über der Spur — boundary, control, entity, database, queue und collections —, und der dort deklarierte "alias" wirkt wie as.

Das erDiagram wird ebenfalls gezeichnet: Jede Entität wird zu einem Kasten mit ihren Attributen, und die Kardinalität steht an beiden Enden der Beziehung (||--o{, }o--||, |o, |{); -- ist eine identifizierende, .. eine nicht identifizierende Beziehung. Der Alias p[Person] benennt den Kasten, ohne die id zu ändern, auf die sich die Beziehungen beziehen. subgraph … end gilt auch hier: Die Entitäten darin bekommen einen Kasten mit Titel, Subgraphen verschachteln sich, und die ID des Kastens kann ein Ende einer Beziehung sein (KUNDE ||--o{ Verkauf : tätigt) — sie trifft dann die Grenze und nicht eine Entität dieses Namens.

Das classDiagram ebenso: ein Kasten mit drei Abschnitten (Name, Attribute und Methoden, getrennt durch die Methodenklammern), <<interface>> in eigener Zeile, namespace als Kasten und die sechs Beziehungen (<|--, *--, o--, -->, ..>, ..|>). Achtung auf die Richtung: in A <|-- B steht das Dreieck an A — es erbt B. Die Kardinalität in Anführungszeichen steht an beiden Enden ("1" --> "*"). Generics Liste~T~ erscheinen als Liste<T>, auch in den Mitgliedern. Die Lollipop-Schnittstelle (bar ()-- foo) zeichnet den Kreis oben auf dem Kasten der Seite, auf der das () steht — und nur dort —, wobei die Beziehung den Kreis berührt; namespace kann ebenfalls verschachtelt werden, und nach der inneren } gehört eine Klasse wieder zum äußeren Namensraum.

Das stateDiagram-v2 zeichnet den Zustandsautomaten: [*] ist Start (gefüllte Scheibe) und Ende (Scheibe mit Ring), state X { … } wird zum Kasten, <<fork>>/<<join>> zum Balken und <<choice>> zur Raute. Ein -- in einem zusammengesetzten Zustand trennt die nebenläufigen Regionen, die eine gestrichelte Linie markiert.

Zeitstrahl, Nutzerreise, Quadranten und Gantt

Auch die timeline wird gezeichnet: Jede Periode wird zu einer Spalte der Zeitleiste, mit den Ereignissen darunter gestapelt, und section fasst die Epochen zu farbigen Bändern zusammen. Beide Schreibweisen für mehrere Ereignisse gelten — Doppelpunkte in derselben Zeile (2004 : Facebook : Google) und Fortsetzung in der nächsten (: weiteres Ereignis) —, und hier ist jede Zeile, die nicht title, section oder direction ist, freier Text. direction TD (senkrechte Zeitleiste) wird noch nicht gezeichnet und behält den Codeblock.

Das journey (Nutzerreise) wird ebenfalls gezeichnet: Jede Aufgabe wird zu einem Kasten auf der Reiseachse, und die Bewertung von 1 bis 5 verschiebt ihr Gesicht nach oben oder unten — es ist das Profil, das sie bilden, weswegen es das Diagramm gibt. section fasst die Phasen zusammen, und die Akteure werden zu farbigen Markern auf der Aufgabe, mit Legende links. Hier ist die Grammatik streng (Aufgabe: Bewertung: Akteur, Akteur), anders als beim timeline: ohne das Paar Name/Bewertung gibt es keinen Ort für das Gesicht, also lehnt eine fehlerhafte Zeile — oder eine Bewertung außerhalb von 1 bis 5 — das Diagramm ab und nennt die Zeile.

Und das quadrantChart zeichnet die Ebene der vier Quadranten: x-axis und y-axis benennen die Enden jeder Achse (die rechte Seite von --> ist optional), quadrant-1 bis quadrant-4 beschriften die Bereiche, und jeder Punkt kommt als Name: [x, y] hinein, mit x und y von 0 bis 1. Achtung bei der Nummerierung: Sie ist die der kartesischen Ebene, nicht die der Leserichtung — quadrant-1 ist der oben rechts, und von dort geht es gegen den Uhrzeigersinn weiter; y = 1 liegt oben. Farbe und Radius eines Punktes können direkt kommen (P: [0.5, 0.5] radius: 10, color: #109060) oder über eine Klasse (P:::klasse plus classDef), und der direkte Stil schlägt die Klasse. Eine Koordinate außerhalb von 0 bis 1 lehnt das Diagramm ab und nennt die Zeile, statt beschnitten zu werden — sie ist die Position in der Ebene, und Beschneiden würde den Punkt in einen Quadranten setzen, den Sie nicht geschrieben haben.

Das gantt zeichnet den Zeitplan: dateFormat gibt das Format der Datumsangaben an, die Sie schreiben (Vorgabe YYYY-MM-DD), und axisFormat das der Achsenbeschriftungen (%d.%m); section fasst die Aufgaben zu Bändern zusammen. Jede Aufgabe lautet Text : Marker, id, Anfang, Ende — die Marker done, active, crit und milestone stehen vorn und lassen sich kombinieren, der Anfang ist ein Datum oder after andereId, und das Ende ist ein Datum, eine Dauer (5d, 2w, 3h, 45m) oder until andereId. Mit nur einem Feld beginnt die Aufgabe dort, wo die vorherige endete.

after darf eine Aufgabe nennen, die weiter unten in der Notiz steht; eine id, die es nirgends gibt — oder eine zirkuläre Abhängigkeit — lehnt das Diagramm ab und nennt die Zeile, statt den Balken auf den heutigen Tag zu setzen. excludes weekends (oder excludes monday, oder ein Datum) schiebt das Ende jeder Aufgabe um die ausgeschlossenen Tage weiter und ändert damit die Länge der Balken; includes 2026-03-07 schlägt das Wochenende, um zu sagen, dass an diesem Samstag gearbeitet wird. Der Meilenstein erscheint als Raute, und todayMarker off entfernt die Linie des heutigen Tages. displayMode compact stapelt mehrere Aufgaben in dieselbe Zeile, und hier teilt sich eine Aufgabe die Zeile nur, wenn nichts von dem, was sie belegt, an das Vorhandene stoßt — die Beschriftung eingeschlossen. Der Marker vert (Eröffnung : vert, v1, 20:15, 0m) zeichnet den Zeitpunkt als senkrechte Linie durch das ganze Diagramm, ohne eine eigene Zeile zu belegen, und seine Beschriftung steht unter der Achse. dateFormat X (oder x) liest das Datum als Unix-Zeit in Sekunden (oder Millisekunden), und auf der Achse schreibt %s/%Q sie zurück. Ein tickInterval, das Mermaid nicht kennt (1decade), wird stillschweigend ignoriert — wie dort —, und die Achse fällt auf automatisch zurück.

Mindmap, Anforderungen, Git und C4

Bei der mindmap kommt die Hierarchie aus der Einrückung: die Ebene eines Eintrags ist die Spalte, in der sein Text beginnt — ohne Klammern und ohne Pfeile (ein Tabulator zählt bis zum nächsten Stopp von 4, wie in einem Editor). Der erste Eintrag ist die Wurzel; ein zweiter Eintrag in ihrer Spalte wäre eine zweite Wurzel, und dann wird das Diagramm mit Angabe der Zeile abgelehnt. Jeder Eintrag darf seine Form angeben: [Quadrat], (abgerundet), ((Kreis)), {{Sechseck}}, ))Explosion(( und )Wolke(; ohne Begrenzer kommt er abgerundet heraus. ::icon(...) und :::klasse werden erkannt und ignoriert (wir liefern die Icon-Schrift nicht mit, und die Klasse verweist auf externes CSS, das es hier nicht gibt). Die Zeichnung hat zwei Seiten — die Wurzel in der Mitte, die Äste auf links und rechts verteilt —, jeder Ast mit eigener Farbe, die die Nachkommen erben, und der Zweig wird mit der Tiefe dünner.

Es ist ein Baum, keine Kräftesimulation wie im mermaid: in einer Mindmap ist die Hierarchie der Inhalt, sie muss sich also aus der Position lesen lassen — und da die Zeichnung beim Themenwechsel neu entsteht, würde ein Layout, das aus zufälligen Startpunkten konvergiert, die ganze Karte jedes Mal umordnen.

treeView (treeView-beta) zeichnet den Ordnerbaum eines Projekts und akzeptiert beide Schreibweisen: die Einrückung (was man tippt) und die Zeichen des Befehls tree selbst (├──, │, └──) — das ist es, was das Einfügen der Terminalausgabe direkt in die Notiz erlaubt; dort genügt die Einrückung nicht, denn │ und ein Leerzeichen belegen dieselbe Spalte, und nur das erste sagt, dass der Zweig weitergeht. Der Schrägstrich am Ende markiert den Ordner (src/), ein Name mit Leerzeichen steht in Anführungszeichen, ## Text hängt einen Kommentar ans Zeilenende und :::highlight hebt den Namen hervor. icon(...) wird erkannt und ignoriert, wie das ::icon() der Mindmap: Icon-Pakete kommen per JavaScript von Iconify, und nicht einmal Mermaid selbst zeichnet sie standardmäßig.

ishikawa (ishikawa-beta) zeichnet das Fischgräten-Diagramm einer Ursachenanalyse: Der erste Eintrag ist die WIRKUNG (der Kopf, rechts), die nächste Ebene sind die Kategorien (die Gräten) und die beiden inneren die Ursachen und Unterursachen. Es sind drei Ebenen — eine vierte lehnt das Diagramm mit Angabe der Zeile ab, denn in Mermaid gibt es sie nicht. Die Gräten wechseln ober- und unterhalb der Mittellinie, was zwei benachbarten Kategorien Platz gibt, ohne dass der Text der einen auf dem der anderen landet, und die Reihenfolge, in der Sie die Ursachen schreiben, liest sich auf beiden Seiten von oben nach unten.

venn (venn-beta) zeichnet sich überschneidende Mengen: set A["Wünschenswert"] deklariert eine, union A,B["Machbar"] benennt die gemeinsame Region (eine Vereinigung heißt nach den Mengen, die sie kreuzt) und text A1["React"], direkt darunter, setzt einen Eintrag in diese Region. Es sind bis zu drei Mengen; die vierte lehnt das Diagramm mit Angabe der Zeile ab: Mit vier Kreisen gibt es keine Anordnung, die alle Regionen erzeugt, und ein "fast richtiges" Bild würde eine von Ihnen deklarierte Region verstecken. Die :Zahl nach der Beschriftung (set A["Alpha"]:20) skaliert den Kreis — die Fläche folgt der Zahl — und nicht die Schnittmengen: Ein Venn mit proportionalen Schnittmengen ist ein anderes Diagramm (Euler) und verlangt numerische Optimierung. style A fill:#ff6b6b färbt eine Menge, und mit Komma (style A,B color:#333) gilt es für die Vereinigung dieser Mengen.

cynefin (cynefin-beta) zeichnet Snowdens Rahmen zum Einordnen von Entscheidungen: Die fünf Domänen haben feste Namen — complex, complicated, chaotic, clear und confusion — und feste Positionen (die vier Quadranten, die Verwirrung in der Mitte); Sie wählen, was hinein kommt. Jeder Eintrag steht in Anführungszeichen, einer pro Zeile, und complex --> complicated : "Muster erkannt" zeichnet den Übergang zwischen zwei Domänen. Ein Name außerhalb der fünf lehnt das Diagramm mit Angabe der Zeile ab und nennt die vorhandenen. Die Grenze zwischen clear und chaotic wird gewellt gezeichnet: Im Modell ist sie eine Klippe, und die Form sagt das — hier ist die Welle immer dieselbe, damit die Notiz nicht bei jedem Öffnen anders aussieht.

swimlane (swimlane-beta) zeichnet einen Prozess in Bahnen, eine je Verantwortlichem: Die Syntax ist die des Flussdiagramms (dieselben Formen, Pfeile, Beschriftungen und classDef), und jeder subgraph ist keine Box mehr, sondern eine Bahn. Jeder Knoten muss in einer liegen — ein loser Knoten lehnt das Diagramm ab, weil sich sonst nicht sagen ließe, wem die Aufgabe gehört — und eine Bahn in einer Bahn lehnt ebenfalls ab. Mit LR sind die Bahnen Zeilen und der Fluss läuft nach rechts; mit TB sind sie Spalten und der Fluss läuft nach unten. Die Position entlang des Flusses kommt vom längsten Pfad zu jeder Aufgabe, und das Band ist das des Eigentümers: Eine Aufgabe verlässt ihre Bahn nie, auch wenn die Zeichnung dadurch kompakter würde.

agentflow (agentflow-beta) zeichnet einen Ablauf mit KI-Agenten und ist ein anderes Vokabular für das Flussdiagramm: Die Pfeile sind dieselben, flow id["Name"] … end übernimmt die Rolle von subgraph (und verschachtelt), global … end enthält, was alle Agenten heranziehen, und connector id["Name"] deklariert ein System von außen. Was wirklich wechselt, ist die Form, die die Rolle jedes Schritts nennt: @{ shape: input }, task, tool (Werkzeugaufruf), decision, refdoc (Referenzdokument) und action (Endaktion). Das Dokument wird mit -.- angebunden, ohne Pfeil: Es wird herangezogen, es ist kein Schritt. Die Schlüssel, die den Agenten in Worten beschreiben (instruction, params, returns, connectorRef, protocol, endpoint), werden gelesen und beim Zeichnen ignoriert. Diese Formnamen gelten nur hier — in einem flowchart lehnen sie ab, denn dort hat Mermaid sie ebenfalls nicht.

usecase (usecase-beta) zeichnet das Anwendungsfall-Diagramm der UML: Was mit actor deklariert wird, ist das Strichmännchen, alles andere ist ein Anwendungsfall und wird als Ellipse gezeichnet — genau diese Unterscheidung soll der Typ zeigen. Ein Anwendungsfall steht als Id("Beschriftung"), Id[Beschriftung], bloß Id oder bloß der Text in Anführungszeichen; systemBoundary "Name" … end ist die Systemgrenze und note for X "Text" hängt eine Notiz an. Die Beziehungen sind die der UML: --> assoziiert, --|> ist Generalisierung (das hohle Dreieck sitzt beim Allgemeinen) und A ..> : include B — mit dem Ziel nach dem Doppelpunkt — zeichnet das gepunktete « include », ebenso für extend. Was den Akteur beschreibt, ohne die Zeichnung zu ändern (type, business, icon), wird gelesen und ignoriert, und <<Stereotyp>> wandert in die Beschriftung. Der json-Knoten wird noch nicht gezeichnet und behält den Codeblock: Er ist ein mehrzeiliger Block mit dem Datenbaum darin, und dort bleibt das JSON als Text lesbar.

wardley (wardley-beta) zeichnet eine Wardley-Karte: eine Fläche, deren senkrechte Achse die Sichtbarkeit für den Nutzer ist (oben steht, was er sieht) und deren waagerechte Achse die Evolution ist, von Genesis bis Commodity.

Achtung auf die Reihenfolge des Paares: component Tee [0.63, 0.81] ist [Sichtbarkeit, Evolution] — die erste Zahl ist die senkrechte Achse, und andersherum gelesen zeichnet die Karte weiter und erzählt eine andere Strategie. anchor ist der Nutzer oben, A -> B verbindet die Kette (ein Name darf Leerzeichen haben, mit oder ohne Anführungszeichen), A +> B ist Fluss (dicker; +<> in beide Richtungen und +'Text'> mit Beschriftung) und evolve Wasserkocher 0.62 zeichnet den gestrichelten Pfeil dorthin, wo das Stück hin soll. Ebenfalls möglich: evolution (benennt die Achsenstufen um), size, (build)/(buy)/(outsource)/(market), (inertia) (der Widerstandsbalken), label [dx, dy], pipeline X { … }, note, accelerator/deaccelerator und nummerierte annotations mit der annotations-Legende.

eventmodeling zeichnet ein Event Model: eine Zeitleiste in drei Bahnen — der Bildschirm oben, das Kommando (und das Lesemodell) in der Mitte, das Ereignis unten. Jede Zeile lautet tf 02 cmd ArtikelHinzufuegen: Die Zahl ist der Zeitpunkt (die Spalte) und das mittlere Wort der Typ, der die Bahn wählt — ui, cmd/command, pcr/processor, rmo/readmodel, view und evt/event (die langen Formen gelten gleich). Die Bahn wird nicht deklariert: Sie ist die Methode. rf (resetframe) öffnet eine neue Scheibe mit gestricheltem Trenner — dort beginnt die Geschichte neu. Das Schema eines Rahmens steht in geschweiften Klammern ({ beschreibung: string }) oder per Verweis ([[Daten]]) auf einen data Daten { … }-Block, der auch später kommen darf; und ->> 02 ->> 03 verbindet den Rahmen mit den Zeitpunkten, die ihn speisen — über die Nummer.

railroad (railroad-ebnf-beta, -abnf-beta, -peg-beta oder railroad-beta) zeichnet eine Grammatik als Eisenbahngleise: Jede Regel wird zu einem Weg, dem man mit dem Finger folgen kann — was man schreiben darf, ist das, was man ablaufen kann. Eine Regel lautet name = ausdruck ; (oder name <- … ; in PEG) und darf mehrere Zeilen umfassen; sie schließt beim ;. Text in Anführungszeichen ist ein Terminal (als Kapsel gezeichnet), ein bloßer Name eine andere Regel (Rechteck); | (oder /) ist Auswahl, ? optional, + ein oder mehr, * null oder mehr, und ( ), [ ] sowie { } gruppieren, machen optional und wiederholen. ABNF setzt die Wiederholung davor (1*( ALPHA / "-" ), *DIGIT), PEG nimmt die Prädikate !x und &x — die in die Beschriftung wandern, weil sie keine Eingabe verbrauchen — und railroad-beta die Funktionsschreibweise (sequence(choice(terminal("+"), …))). Alle vier landen in derselben Zeichnung: Der Bogen oben ist das Optionale, die Schleife unten mit dem Rückwärtspfeil die Wiederholung.

Das requirementDiagram zeichnet Anforderungen und Elemente als Kästen mit Abschnitten: der deklarierte Typ (requirement, functionalRequirement, performanceRequirement, interfaceRequirement, physicalRequirement, designConstraint) erscheint in Guillemets über dem Namen, und die Felder id, text, risk und verifymethod werden zu Zeilen — beim element sind es type und docref. Die Beziehungen (satisfies, traces, derives, verifies, refines, copies, contains) schreibt man a - satisfies -> b oder gespiegelt b <- satisfies - a, und in der gespiegelten Form ist der erste Name das Ziel. Nur contains ist eine durchgezogene Linie, mit dem Symbol auf der Seite dessen, der enthält; die übrigen sind gestrichelt mit dem Pfeil am Ziel. Ein Name mit Leerzeichen kommt in Anführungszeichen.

Der gitGraph zeichnet den Verlauf eines Repositorys: jeder commit rückt in der Zeit vor, branch Name öffnet eine neue Spur und arbeitet ab da darin (wie git switch -c), checkout wechselt zurück und merge führt beide zusammen. Attribute stehen nach einem Doppelpunkt: commit id: "Text" tag: "v1" type: HIGHLIGHT (auch REVERSE), und branch Name order: 2 ändert die Reihenfolge der Spuren; cherry-pick id: "…" verlangt die id eines Commits, den es gibt. Die Form sagt den Typ — voller Punkt beim normalen Commit, Quadrat beim hervorgehobenen, Kreis mit X beim zurückgenommenen, Doppelring beim Merge und geschnittener Kreis beim Cherry-Pick —, denn in einem Thema, in dem zwei Töne der Palette ähnlich wirken, trennt sie nur die Form. LR: (Standard), TB: und BT: drehen die Zeitachse. Ein checkout/merge auf einen Branch, den es nicht gibt, lehnt das Diagramm mit Zeilenangabe ab, statt eine Spur zu erzeugen, die Sie nicht wollten.

Die C4-Familie (C4Context, C4Container, C4Component, C4Dynamic und C4Deployment) wird ebenfalls gezeichnet, und dort ist alles ein Makro — in der Syntax gibt es keinen einzigen Pfeil. Jedes Element wird zu einem Kasten mit dem Typ in Guillemets, dem Namen in Fett und der Beschreibung darunter: Person(alias, "Name", "Beschreibung"), System, Container, Component sowie die Varianten Db, Queue und _Ext. Bei Container und Component ist das dritte Argument die TECHNOLOGIE (Container(app, "App", "C++/Qt", "was er tut")), bei den übrigen ist es bereits die Beschreibung. Die Grenzen (Boundary, Enterprise_Boundary, System_Boundary, Container_Boundary und der Node aus C4Deployment) öffnen eine Klammer und werden zu einem Kasten mit Titel, verschachtelt eingeschlossen. Die Verbindung ist Rel(a, b, "Beschriftung", "Technologie"); BiRel setzt an beiden Enden einen Pfeil und Rel_Back zeigt zurück. C4Dynamic nummeriert die Beziehungen in der Reihenfolge ihres Auftretens. Die Platzierungshinweise (Rel_U, Rel_D, Rel_L, Rel_R) und die Update…Style-Aufrufe werden angenommen und ignoriert — die Anordnung kommt aus demselben Layout wie bei den anderen Diagrammen, und die Farbe kommt aus dem Thema der Notiz. Eine Beziehung mit einem nie deklarierten Alias lehnt das Diagramm mit Zeilenangabe ab, statt einen Kasten zu erfinden, den Sie nicht geschrieben haben.

Board, Diagramme und Paket

Beim kanban ist die Einrückung die Syntax, mit zwei Ebenen: die äußere ist die Spur, die innere die Karte (id[Beschriftung] oder nur der Text). Das @{ ticket: LN-9, assigned: 'ana', priority: 'High' } hinter einer Karte gehört nicht zu ihrem Text: Ticket und Zuständige kommen in eine eigene Fußzeile, und die Priorität (Very High, High, Low, Very Low) wird zur Farbe des Streifens am linken Rand, auf einer Skala von warm nach kalt. Alle Spuren enden auf derselben Linie, und eine Spur ohne Karte bleibt sichtbar — sie zeigt genau die leere Spalte. Dies ist ein gezeichnetes Board, um einen Ablauf in einer Notiz zu erklären; das Board, auf dem man wirklich arbeitet, mit Karten zum Ziehen, ist das Aufgaben-Panel der App selbst.

Das xychart (xychart-beta) zeichnet Balken und Linien über zwei Achsen: x-axis "Titel" [Jan, Feb, Mär] gibt die Kategorien an — ein Name mit Leerzeichen oder Komma kommt in Anführungszeichen —, y-axis "Titel" 0 --> 100 legt die Skala fest, und jedes bar [10, 40, 90] oder line [20, 30, 80] fügt eine Reihe hinzu, mit einem Wert pro Kategorie, in der Reihenfolge der Deklaration. Eine Reihe mit mehr oder weniger Werten lehnt das Diagramm mit Zeilenangabe ab: die Balken würden auf andere Kategorien rutschen, und das Diagramm würde etwas anderes behaupten. Ohne y-axis ergibt sich die Skala aus den Daten und beginnt bei null, solange diese nicht darunter gehen — beim kleinsten Wert zu beginnen übertreibt den Unterschied zwischen den Balken, und das hat niemand gewählt; bei deklariertem Bereich wird ein Wert außerhalb abgelehnt, statt aus dem Diagramm zu laufen.

x-axis nimmt auch einen kontinuierlichen Bereich (0 --> 100), und ohne ihn sind die Kategorien die Indizes. Zwei Balkenreihen stehen nebeneinander und nicht übereinander wie im mermaid — übereinander verschwindet die hintere. xychart-beta horizontal wird noch nicht gezeichnet und behält den Codeblock, denn senkrecht gezeichnet käme das Diagramm transponiert heraus. Eine Reihe kann einen Namen haben (bar "Offen" [10, 40], line "Geschlossen" [20, 30]): Die Namen bilden eine Legende über der Fläche, jeweils in der Form ihrer Reihe — gefüllter Balken, Linie mit Punkt —, denn die Farbe allein trennt sie nicht. Und in einer Linien-Reihe darf ein Wert eine Beschriftung tragen ([540 "PaLM", 65]), gezeichnet über dem Punkt; bei Balken wird sie ignoriert, wie in Mermaid.

Das radar (radar-beta) zeichnet das Profil einer oder mehrerer Kurven über Achsen, die vom Mittelpunkt ausgehen: axis a["Beschriftung"], b, c deklariert die Achsen — die Zeile darf sich wiederholen —, und curve x["Name"]{80, 60, 90} gibt einen Wert pro Achse an, in der Reihenfolge der Deklaration; die benannte Schreibweise ({a: 80, c: 90, b: 60}) gilt ebenso. Achtung auf die Richtung: die erste Achse zeigt nach oben, und die Drehung ist im Uhrzeigersinn. max und min legen die Skala fest — ohne max ergibt sie sich aus dem größten gelesenen Wert —, und ein Wert außerhalb davon lehnt das Diagramm mit Zeilenangabe ab, statt beschnitten zu werden; ticks ändert die Anzahl der Ringe, graticule circle macht sie rund und showLegend false entfernt die Legende. Eine Kurve mit mehr oder weniger Werten als Achsen wird ebenfalls abgelehnt: sie wäre keine unvollständige Zeichnung, sondern eine andere.

Das packet (packet-beta) zeichnet die Bitbelegung eines Pakets: jedes Feld ist 0-15: "Beschriftung", und der Bereich ist an beiden Enden geschlossen — 0-15 sind sechzehn Bits. Ein einzelnes Bit schreibt man 4: "Beschriftung", und die relative Form +16: "Beschriftung" nimmt die nächsten sechzehn, damit Sie beim Einfügen eines Feldes in der Mitte nicht alles neu zählen müssen. Die Felder müssen lückenlos aufeinanderfolgen: eine Lücke oder eine Überlappung lehnt das Diagramm mit Zeilenangabe ab, denn beides würde alles Folgende stillschweigend verschieben. Eine Zeile fasst 32 Bit, und ein Feld über den Umbruch hinweg erscheint in beiden, mit der Beschriftung im breiteren Teil; die Zahlen über dem Raster markieren, wo jedes Feld beginnt, dazu das letzte Bit jeder Zeile.

Raster, Flächen, Architektur, Fluss und ZenUML

Das block (block-beta) zeichnet ein Raster aus Kästen, und darin ist die Position die Reihenfolge, in der Sie sie geschrieben haben: columns 3 legt die Spaltenzahl fest — ohne das steht alles in einer einzigen Zeile —, jeder Kasten nimmt die Formen des Flussdiagramms (a["Beschriftung"], b(("Kreis")), c{"Raute"}), a:2 lässt einen Kasten zwei Spalten belegen und space (oder space:2) lässt eine Lücke. block:id … end verschachtelt ein Raster im anderen, mit eigenem columns, und wird zum Kasten darum herum. Die Pfeile sind die des Flussdiagramms (a --> b, beschriftet als a -- "Text" --> b), aber hier verweisen sie nur auf bereits deklarierte Blöcke: ein Pfeil auf einen Namen, den es nicht gibt, lehnt das Diagramm mit Zeilenangabe ab, statt einen Kasten in einer Zelle zu erfinden, die Sie nicht geschrieben haben. Der Abstand zwischen den Spalten wächst, bis die Pfeilbeschriftung passt, damit sie den Nachbarkasten nicht berührt. Der Blockpfeil (a<["Hin"]>(right)) ist ein Kasten in Pfeilform: Die Richtungen stehen in Klammern (right, left, up, down, oder x für beide waagerechten und y für beide senkrechten) und lassen sich kombinieren ((x, down)); eine erfundene Richtung lehnt das Diagramm mit Angabe der Zeile ab, statt zu irgendeinem Pfeil zu werden.

Das treemap (treemap-beta) zeichnet eine Flächenkarte: die Fläche jedes Rechtecks ist proportional zu seinem Wert, und die Einrückung verschachtelt, in freier Tiefe. Das Blatt deklariert den Wert ("Name": 12), der Abschnitt deklariert nichts — seiner ist die Summe der Kinder, und ein eigener Gesamtwert erlaubte ein Rechteck, das über die eigenen Teile lügt; deshalb wird das mit Zeilenangabe abgelehnt. Ein Name mit Leerzeichen oder Doppelpunkt kommt in Anführungszeichen; classDef und :::klasse geben Farbe. Die Anordnung ist squarified und hält die Rechtecke nahe am Quadrat — immer entlang derselben Achse zu schneiden ergäbe Streifen, die sich nicht mit dem Auge vergleichen lassen, und Flächen zu vergleichen ist das Einzige, was dieser Typ tut. Beschriftung und Wert erscheinen nur, wenn sie ganz in das Rechteck passen: am Rand abgeschnitten sagten sie nichts.

Das architecture (architecture-beta) zeichnet Dienste und die Verbindungen zwischen ihnen: service api(server)[API] deklariert eine Komponente, group wolke(cloud)[Cloud] öffnet eine Grenze, das Suffix in wolke setzt den Dienst hinein (Gruppen verschachteln sich) und junction j erzeugt eine Ecke, um eine Verbindung zu knicken.

Die Seite der Verbindung entscheidet über die Position: a:R -- L:b legt die rechte Seite von a an die linke von b, setzt b also rechts von a; es gelten L, R, T und B, und die Spitze erscheint auf der Seite des < oder des > (-->, <--> oder -- ganz ohne Spitze). Das Suffix {group} an einem Ende schickt die Linie an die Grenze der Gruppe statt an den Kasten darin. Die Symbole sind die fünf, die Mermaid mitbringt — cloud, database, disk, internet und server —, und jeder andere Name lehnt das Diagramm mit Zeilenangabe ab und nennt die vorhandenen. Alle übrigen (logos:aws-lambda und ähnliche) stammen aus Iconify und erscheinen nur dort, wo der Herausgeber der Seite das Paket per JavaScript registriert, was nicht einmal GitHub tut: sie hier anzunehmen ergäbe eine Zeichnung, die sich nirgendwo sonst wiederholt. align row a b c (oder align column) setzt die genannten Mitglieder in dieselbe Zeile — oder dieselbe Spalte —, und ein nicht vorhandener Name lehnt das Diagramm mit Angabe der Zeile ab, statt die Anordnung stillschweigend so zu lassen, wie sie war.

Das sankey (sankey-beta) zeichnet ein Flussdiagramm, in dem die Dicke des Bandes der Wert ist: der Rumpf enthält überhaupt keine Pfeile — er ist eine CSV mit drei Spalten (Quelle,Ziel,Wert), eine Verbindung pro Zeile, und erst das Wiederholen eines Namens an beiden Enden verkettet den Fluss. Eine Beschriftung mit Komma steht in Anführungszeichen, und ein Anführungszeichen darin wird verdoppelt geschrieben ("Feste ""Kosten"""); dasselbe Paar aus Quelle und Ziel wird bei Wiederholung addiert. Der Balken eines Knotens ist so hoch wie der größere Wert von Zufluss und Abfluss, damit die abgehenden Bänder eines Knotens, der mehr verteilt als er empfängt, nicht über den Rand laufen. Die Spalten ergeben sich aus dem längsten Weg zu jedem Knoten, und was keinen Abfluss hat, kommt in die letzte Spalte. Ein Wert kleiner oder gleich null, eine Verbindung eines Knotens zu sich selbst und ein Zyklus lehnen das Diagramm mit Angabe der Zeile ab — in einem Zyklus gibt es keinen längsten Weg, und eine Verbindung zu kappen, um zeichnen zu können, zeigte einen Fluss, den Sie nicht geschrieben haben. Ein title gibt es hier nicht: der Rumpf ist reines CSV, und ihn anzunehmen zeichnete in LightNote sauber und wäre in Mermaid ein Syntaxfehler.

Das zenuml ist eine andere Syntax für dieselbe Zeichnung — ein Sequenzdiagramm —, als Code statt als Pfeile geschrieben. Der synchrone Aufruf nennt nur das Ziel (Laden.erfassen(artikel)), und der Absender ist der Block, der ihn umschließt: innerhalb von Laden.erfassen() { Lager.reservieren() } ruft der Laden das Lager auf. Auf der äußeren Ebene ruft der Starter auf — @Starter(Ana) benennt ihn, und ohne ihn kommt ein User als Strichmännchen, das nur erscheint, wenn ein Aufruf es braucht. Die asynchrone Nachricht ist A->B: Text (offene Spitze, niemand wartet), und A->B.methode() ist der synchrone Aufruf mit ausgeschriebenem Absender. {} verschachtelt, return x geht zurück an den, der den umschließenden Aufruf gemacht hat (ein if dazwischen ändert das nicht), x = A.m() ist die andere Schreibweise derselben Antwort, new A(args) erzeugt, und // Kommentar wird zu einer Notiz über der nächsten Nachricht. Die Blöcke sind if/else if/else, while/for/forEach/loop, opt, par und try/catch/finally — und } else { setzt denselben Rahmen mit einem Trenner fort, statt einen neuen zu öffnen. @Actor zeichnet das Strichmännchen; die übrigen Annotatoren (@Database, @Boundary…) werden zum Stereotyp in der Beschriftung («Database» Lager), weil ihre Symbole hier nicht gezeichnet werden — der Name bleibt sichtbar, und darauf kommt es an. Ein Name mit Leerzeichen steht in Anführungszeichen.

Achtung, wo dieser Block landet: in Mermaid ist zenuml ein externes Diagramm, das die Seite per JavaScript registrieren muss — GitHub tut das nicht, also erscheint dieselbe Notiz dort als Codeblock.

Und wenn LightNote ein Diagramm nicht lesen kann, sagt es warum und in welcher Zeile, direkt unter dem Block — ein noch nicht gezeichneter Typ erzeugt keinen Hinweis, denn daran ist nichts falsch.