Diagrammi (Mermaid)

Come funziona

Diagrammi Mermaid. Un recinto ```mermaid con un diagramma di flusso (flowchart/graph, nelle quattro direzioni), un diagramma di sequenza (sequenceDiagram) o un grafico a torta (pie) viene disegnato come diagramma nella modalità di lettura, nel file esportato e nelle risposte di Chiedi alle note — da dove arrivano quasi sempre i diagrammi. Il disegno segue il tema della nota (inchiostro, carta e accento), quindi si accorda con il testo intorno in entrambi i temi. Nella modifica formattata — la modalità predefinita — il diagramma viene disegnato anche lì, con la barra del blocco sopra (copia, modifica, elimina). Modifica apre in basso una barra con il sorgente: la nota resta bloccata finché è aperta e il disegno si rifà mentre scrivi; chiudere applica (non c’è né salva né annulla), Ctrl+Z annulla l’intera modifica in un passo e svuotare il campo rimuove il blocco. Nella modalità divisa, fare clic sul diagramma porta il cursore fino al recinto nel testo grezzo. Nell’editor di testo tutto resta testo: usa Ctrl+E per vedere il diagramma. Dentro un elemento di elenco, il diagramma — e anche la struttura SMILES, la formula in blocco, [files] e ![[nota]] — resta testo nella modifica formattata e appare disegnato nel modo lettura: lì il marcatore dell’elemento non avrebbe modo di tornare nel file.

I sottografi (subgraph … end, anche annidati) diventano riquadri con titolo, e gli archi attraversano il bordo partendo dal nodo vero; l’id di un sottografo può anche essere estremo di un arco (sub --> X). Valgono i colori dichiarati dall’autore: classDef, class, :::classe e style (riempimento, bordo, spessore, tratteggio e colore del testo). Per iniziare, usa Inserisci → Diagramma (Mermaid) nella barra della nota: entra con uno scheletro pronto del tipo scelto. Il menu offre i sei più usati direttamente; Tutti i diagrammi… apre un selettore con tutti e 33, raggruppati per scopo, con ricerca (per nome o per ciò che il diagramma mostra) e l'anteprima disegnata di ciascuno — sono 33 disegni, e vedere il disegno decide più in fretta che leggere il nome. Anche il frontmatter del diagramma — il blocco tra --- prima della prima riga — viene letto: il title diventa il titolo disegnato sopra il disegno (un title nel corpo vince) e le chiavi di config che LightNote conosce arrivano al diagramma (gitGraph.mainBranchName, gantt.displayMode e quelle di packet: bitsPerRow, bitOrder: descending — che specchia la fila — e showBits: false); ciò che non conosce viene ignorato, senza rifiutare la nota.

Sequenza, entità, classi e stati

Nel diagramma di sequenza valgono participant/actor (con as), le forme di freccia (->>, -->>, -x, -)), l’attivazione (+/- e activate/deactivate), le note (Note left of/right of/over), i blocchi loop/alt/else/opt/par e autonumber. Ciò che non viene ancora disegnato — altri tipi di diagramma — continua a comparire come blocco di codice; direction dentro un sottografo e linkStyle vengono ignorati. Anche la sintassi di nodo di Mermaid v11 (A@{ shape: rounded, label: "testo" }) viene letta, e il catalogo di forme della v11 viene disegnato: doc, lin-doc, docs, tag-rect, win-pane, hourglass, bolt, flag, das… — ognuna è il simbolo che il nome dice, e nessuna diventa un rettangolo, perché un rettangolo al posto di un documento sarebbe un altro diagramma. Un nome che Mermaid non ha riporta il diagramma a blocco di codice, indicando la riga. L’id di arco (A e1@--> B) e e1@{ animate: true } sono accettati e ignorati: l’animazione non viene disegnata. Il partecipante tipizzato (participant DB@{ "type": "database" }) disegna il simbolo UML sopra la corsia — boundary, control, entity, database, queue e collections —, e l’"alias" dichiarato lì vale come as.

Anche il erDiagram viene disegnato: ogni entità diventa una casella con i suoi attributi e la cardinalità appare a entrambe le estremità della relazione (||--o{, }o--||, |o, |{); -- è una relazione identificante e .. non identificante. L'alias p[Persona] nomina la casella senza cambiare l'id citato dalle relazioni. Anche il subgraph … end vale qui: le entità all’interno ottengono un riquadro con titolo, i sottografi si annidano e l’id del riquadro può essere un’estremità di relazione (CLIENTE ||--o{ Vendite : effettua), agganciandosi al confine invece che a un’entità con quel nome.

Anche il classDiagram: casella a tre scomparti (nome, attributi e metodi, separati dalle parentesi del metodo), <<interface>> su una riga propria, namespace come casella e le sei relazioni (<|--, *--, o--, -->, ..>, ..|>). Attenzione al verso: in A <|-- B il triangolo sta su A — chi eredita è B. La cardinalità tra virgolette appare a entrambe le estremità ("1" --> "*"). I generici Lista~T~ appaiono come Lista<T>, anche nei membri. L’interfaccia lollipop (bar ()-- foo) disegna il cerchio in cima al riquadro dal lato in cui sta il () — e solo lì —, con la relazione che tocca il cerchio; anche i namespace si annidano, e dopo la } interna una classe torna al namespace esterno.

Il stateDiagram-v2 disegna la macchina a stati: [*] è l'inizio (disco pieno) e la fine (disco con anello), state X { … } diventa una casella, <<fork>>/<<join>> una barra e <<choice>> un rombo. Un -- dentro uno stato composito separa le regioni concorrenti, segnate da una linea tratteggiata.

Linea del tempo, percorso, quadranti e Gantt

Anche la timeline viene disegnata: ogni periodo diventa una colonna della linea temporale, con i suoi eventi impilati sotto, e section raggruppa le ere in fasce colorate. Valgono entrambe le grafie per più eventi — due punti sulla stessa riga (2004 : Facebook : Google) e continuazione sulla riga successiva (: altro evento) —, e qui ogni riga che non sia title, section o direction è testo libero. direction TD (linea temporale verticale) non è ancora disegnato e mantiene il blocco di codice.

Il journey (percorso dell'utente) viene disegnato anch'esso: ogni attività diventa una casella sull'asse del percorso, e il punteggio da 1 a 5 sposta il suo volto in alto o in basso — è il profilo che formano ciò che il diagramma esiste per mostrare. section raggruppa le fasi e gli attori diventano marcatori colorati sull'attività, con la legenda a sinistra. Qui la grammatica è rigida (Attività: punteggio: Attore, Attore), a differenza di quella del timeline: senza la coppia nome/punteggio non c'è dove mettere il volto, quindi una riga malformata — o un punteggio fuori da 1 a 5 — rifiuta il diagramma indicando la riga.

E il quadrantChart disegna il piano dei quattro quadranti: x-axis e y-axis danno il nome agli estremi di ciascun asse (il lato destro di --> è facoltativo), da quadrant-1 a quadrant-4 etichettano le regioni e ogni punto entra come Nome: [x, y], con x e y da 0 a 1. Attenzione alla numerazione: è quella del piano cartesiano, non quella di lettura — quadrant-1 è quello in alto a destra, e da lì si procede in senso antiorario; y = 1 sta in alto. Colore e raggio di un punto possono arrivare diretti (P: [0.5, 0.5] radius: 10, color: #109060) o da una classe (P:::classe più classDef), e lo stile diretto batte la classe. Una coordinata fuori da 0 a 1 rifiuta il diagramma indicando la riga invece di essere tagliata — è la posizione nel piano, e tagliarla metterebbe il punto in un quadrante che non hai scritto.

Il gantt disegna il cronoprogramma: dateFormat dichiara il formato delle date che scrivi (predefinito YYYY-MM-DD) e axisFormat quello delle etichette dell’asse (%d/%m); section raggruppa le attività in fasce. Ogni attività si scrive Testo : marcatori, id, inizio, fine — i marcatori done, active, crit e milestone vengono per primi e si possono combinare, l’inizio è una data o after altroId, e la fine è una data, una durata (5d, 2w, 3h, 45m) oppure until altroId. Con un solo campo l’attività comincia dove è finita la precedente.

L’after può citare un’attività dichiarata più avanti nella nota; invece un id che non esiste da nessuna parte — o una dipendenza circolare — rifiuta il diagramma indicando la riga, invece di mettere la barra sulla data di oggi. L’excludes weekends (oppure excludes monday, o una data) sposta la fine di ogni attività oltre i giorni esclusi, e per questo cambia la lunghezza delle barre; includes 2026-03-07 batte il fine settimana, per dire che quel sabato si lavora. La milestone appare come un rombo, e todayMarker off toglie la linea di oggi. Il displayMode compact impila più attività sulla stessa riga, e qui un’attività condivide la riga solo quando nulla di ciò che occupa tocca ciò che c’è già — etichetta compresa. Il marcatore vert (Apertura : vert, v1, 20:15, 0m) disegna l’istante come una linea verticale che attraversa tutto il grafico, senza occupare alcuna riga, e la sua etichetta finisce sotto l’asse. Il dateFormat X (o x) legge la data come tempo Unix in secondi (o millisecondi), e sull’asse %s/%Q la riscrive. Un tickInterval che Mermaid non conosce (1decade) viene ignorato in silenzio, come lì, e l’asse torna automatico.

Mappa mentale, requisiti, Git e C4

Nella mindmap la gerarchia viene dall’indentazione: il livello di una voce è la colonna in cui inizia il suo testo, senza parentesi né frecce (una tabulazione vale fino alla fermata successiva di 4, come in un editor). La prima voce è la radice — una seconda voce nella sua colonna sarebbe una seconda radice, e allora il diagramma viene rifiutato indicando la riga. Ogni voce può dichiarare la forma: [quadrato], (arrotondato), ((cerchio)), {{esagono}}, ))esplosione(( e )nuvola(; senza delimitatore esce arrotondata. ::icon(...) e :::classe sono riconosciuti e ignorati (non distribuiamo il font delle icone, e la classe rimanda a un CSS esterno che qui non esiste). Il disegno è a due lati — la radice al centro, i rami distribuiti a sinistra e a destra —, ogni ramo con un colore proprio che i discendenti ereditano, e il ramoscello si assottiglia con la profondità.

È un albero, non una simulazione di forze come in mermaid: in una mappa mentale la gerarchia è il contenuto, quindi deve leggersi dalla posizione — e, dato che il disegno viene rifatto al cambio di tema, una disposizione che converge da posizioni casuali riorganizzerebbe l’intera mappa ogni volta.

Il treeView (treeView-beta) disegna l’albero delle cartelle di un progetto e accetta entrambe le grafie: il rientro (quello che si digita) e i caratteri stessi del comando tree (├──, │, └──), che è ciò che permette di incollare l’output del terminale direttamente nella nota — lì il rientro non basta, perché │ e uno spazio occupano la stessa colonna e solo il primo dice che il ramo continua. La barra finale segna la cartella (src/), un nome con spazi va tra virgolette, ## testo appende un commento a fine riga e :::highlight evidenzia il nome. icon(...) viene riconosciuto e ignorato, come l’::icon() della mappa mentale: i pacchetti di icone arrivano da Iconify via JavaScript, e nemmeno Mermaid li disegna per impostazione predefinita.

L’ishikawa (ishikawa-beta) disegna il diagramma a lisca di pesce di un’analisi delle cause: il primo elemento è l’EFFETTO (la testa, a destra), il livello successivo sono le categorie (le lische) e i due interni sono le cause e le sotto-cause. Sono tre livelli, e un quarto rifiuta il diagramma indicando la riga — in Mermaid non esiste. Le lische si alternano sopra e sotto la spina, il che permette a due categorie vicine di stare senza che il testo dell’una finisca su quello dell’altra, e l’ordine in cui scrivi le cause si legge dall’alto in basso da entrambi i lati.

Il venn (venn-beta) disegna insiemi che si incrociano: set A["Desiderabile"] ne dichiara uno, union A,B["Realizzabile"] dà il nome alla regione comune (un’unione si chiama con gli insiemi che attraversa) e text A1["React"], subito sotto a uno di essi, mette un elemento dentro quella regione. Sono fino a tre insiemi, e il quarto rifiuta il diagramma indicando la riga: con quattro cerchi non esiste disposizione che produca tutte le regioni, e disegnarne uno "quasi giusto" nasconderebbe una regione che hai dichiarato. Il :numero dopo l’etichetta (set A["Alpha"]:20) scala il cerchio — l’area segue il numero — e non le intersezioni: un Venn con intersezioni proporzionali è un altro diagramma (Euler), che richiede ottimizzazione numerica. style A fill:#ff6b6b colora un insieme, e con la virgola (style A,B color:#333) vale per l’unione di quegli insiemi.

Il cynefin (cynefin-beta) disegna il quadro di Snowden per classificare le decisioni: i cinque domini hanno nome fisso — complex, complicated, chaotic, clear e confusion — e posizione fissa (i quattro quadranti, con la confusione al centro); quello che scegli è ciò che va dentro a ciascuno. Ogni voce va tra virgolette, una per riga, e complex --> complicated : "Schema identificato" disegna la transizione fra due domini. Un nome fuori dai cinque rifiuta il diagramma indicando la riga e dicendo quali esistono. Il confine fra clear e chaotic esce ondulato: nel modello è un precipizio, e la forma lo dice — qui l’onda è sempre la stessa, perché la nota non cambi disegno a ogni apertura.

Lo swimlane (swimlane-beta) disegna un processo a corsie, una per responsabile: la sintassi è quella del diagramma di flusso (stesse forme, frecce, etichette e classDef), e ogni subgraph smette di essere un riquadro e diventa una corsia. Ogni nodo deve stare dentro una — un nodo sciolto rifiuta il diagramma, perché non ci sarebbe modo di dire di chi è il compito — e una corsia dentro una corsia rifiuta ugualmente. Con LR le corsie sono righe e il flusso va a destra; con TB sono colonne e il flusso scende. La posizione lungo il flusso viene dal cammino più lungo fino a ogni compito, e la fascia è quella del proprietario: un compito non esce mai dalla sua corsia, nemmeno se il disegno ne uscisse più compatto.

L’agentflow (agentflow-beta) disegna un flusso con agenti di IA ed è un altro vocabolario per il diagramma di flusso: le frecce sono le stesse, flow id["Nome"] … end fa la parte del subgraph (e si annida), global … end tiene ciò che tutti gli agenti consultano e connector id["Nome"] dichiara un sistema esterno. Ciò che cambia davvero è la forma, che dice il ruolo di ogni passo: @{ shape: input }, task, tool (chiamata a uno strumento), decision, refdoc (documento di riferimento) e action (azione finale). Collega il documento con -.-, senza freccia: viene consultato, non è un passo del flusso. Le chiavi che descrivono l’agente a parole (instruction, params, returns, connectorRef, protocol, endpoint) vengono lette e ignorate nel disegno. Questi nomi di forma valgono solo qui: in un flowchart rifiutano, perché nemmeno Mermaid li ha lì.

L’usecase (usecase-beta) disegna il diagramma dei casi d’uso UML: ciò che si dichiara con actor diventa l’omino, e tutto il resto è un caso d’uso, disegnato come ellisse — è la distinzione che questo tipo esiste per mostrare. Il caso d’uso può essere Id("Etichetta"), Id[Etichetta], solo Id o solo il testo tra virgolette; systemBoundary "Nome" … end è il confine del sistema e note for X "testo" appende una nota. Le relazioni sono quelle UML: --> associa, --|> è la generalizzazione (il triangolo vuoto sta dalla parte del generale) e A ..> : include B — con il bersaglio dopo i due punti — disegna l’« include » punteggiato, e lo stesso vale per extend. Ciò che descrive l’attore senza cambiare il disegno (type, business, icon) viene letto e ignorato, e lo <<Stereotipo>> entra nell’etichetta. Il nodo json non viene ancora disegnato e mantiene il blocco di codice: è un blocco su più righe con l’albero del dato dentro, e lì il JSON resta leggibile come testo.

Il wardley (wardley-beta) disegna una mappa di Wardley: un piano in cui l’asse verticale è la visibilità per l’utente (in alto c’è ciò che vede) e quello orizzontale è l’evoluzione, da Genesis a Commodity.

Attenzione all’ordine della coppia: component Tè [0.63, 0.81] è [visibilità, evoluzione] — il primo numero è l’asse verticale, e letto al contrario la mappa continua a disegnarsi e inizia a dire un’altra strategia. L’anchor è l’utente in alto, A -> B collega la catena (il nome può avere spazi, con o senza virgolette), A +> B è flusso (più spesso; +<> nei due sensi e +'testo'> con etichetta) ed evolve Bollitore 0.62 disegna la freccia tratteggiata fin dove il pezzo deve arrivare. Valgono anche evolution (cambia le tappe dell’asse), size, (build)/(buy)/(outsource)/(market), (inertia) (la barra di resistenza), label [dx, dy], pipeline X { … }, note, accelerator/deaccelerator e le annotation numerate con la legenda di annotations.

L’eventmodeling disegna un event modeling: una linea del tempo su tre corsie — lo schermo in alto, il comando (e il modello di lettura) in mezzo, l’evento in basso. Ogni riga è tf 02 cmd AggiungiArticolo: il numero è l’istante (la colonna) e la parola di mezzo è il tipo, che sceglie la corsia — ui, cmd/command, pcr/processor, rmo/readmodel, view ed evt/event (le forme lunghe valgono uguale). La corsia non si dichiara: è il metodo. Il rf (resetframe) apre una nuova fetta, con un divisore tratteggiato — è dove la storia ricomincia. Lo schema del riquadro va tra graffe ({ descrizione: string }) o per riferimento ([[Dati]]) a un blocco data Dati { … }, che può venire dopo; e ->> 02 ->> 03 collega il riquadro agli istanti che lo alimentano, citando il numero.

Il railroad (railroad-ebnf-beta, -abnf-beta, -peg-beta o railroad-beta) disegna una grammatica come binari: ogni regola diventa un percorso che si segue col dito, e ciò che si può scrivere è ciò che si può percorrere. La regola è nome = espressione ; (o nome <- … ; in PEG) e può occupare più righe: si chiude al ;. Il testo tra virgolette è un terminale (disegnato a capsula) e un nome da solo è un’altra regola (rettangolo); | (o /) è scelta, ? opzionale, + uno o più, * zero o più, e ( ), [ ] e { } raggruppano, rendono opzionale e ripetono. L’ABNF mette la ripetizione prima (1*( ALPHA / "-" ), *DIGIT), il PEG accetta i predicati !x e &x — che finiscono nell’etichetta, perché non consumano input — e railroad-beta accetta la grafia a funzioni (sequence(choice(terminal("+"), …))). Tutti e quattro arrivano allo stesso disegno: la deviazione sopra è l’opzionale e il cappio sotto, con la freccia all’indietro, è la ripetizione.

Il requirementDiagram disegna requisiti ed elementi come riquadri a scomparti: il tipo dichiarato (requirement, functionalRequirement, performanceRequirement, interfaceRequirement, physicalRequirement, designConstraint) compare fra virgolette a caporale sopra il nome, e i campi id, text, risk e verifymethod diventano righe — in un element, type e docref. Le relazioni (satisfies, traces, derives, verifies, refines, copies, contains) si scrivono a - satisfies -> b oppure nella forma speculare b <- satisfies - a, e in questa il primo nome è la destinazione. Solo contains è una linea piena, con il simbolo dal lato di chi contiene; le altre sono tratteggiate con la freccia sulla destinazione. Un nome con spazio va fra virgolette.

Il gitGraph disegna la cronologia di un repository: ogni commit avanza nel tempo, branch nome apre una corsia nuova e ci si sposta subito dentro (come git switch -c), checkout torna a un'altra e merge unisce le due. Gli attributi vogliono i due punti: commit id: "testo" tag: "v1" type: HIGHLIGHT (anche REVERSE), e branch nome order: 2 cambia l'ordine delle corsie; cherry-pick id: "…" richiede l'id di un commit che esista. La forma dice il tipo — disco pieno nel commit comune, quadrato in quello evidenziato, cerchio con la X in quello annullato, doppio anello nel merge e cerchio tagliato nel cherry-pick —, perché in un tema dove due tonalità della tavolozza si somigliano solo la forma li separa. LR: (predefinito), TB: e BT: ruotano l'asse del tempo. Un checkout/merge su un ramo che non esiste rifiuta il diagramma indicando la riga, invece di creare una corsia che non hai chiesto.

Anche la famiglia C4 (C4Context, C4Container, C4Component, C4Dynamic e C4Deployment) viene disegnata, e lì tutto è macro: nella sintassi non c'è nessuna freccia. Ogni elemento diventa un riquadro con il tipo fra virgolette a caporale, il nome in grassetto e la descrizione sotto: Person(alias, "Nome", "Descrizione"), System, Container, Component e le varianti Db, Queue e _Ext. In Container e Component il terzo argomento è la TECNOLOGIA (Container(app, "App", "C++/Qt", "che cosa fa")); negli altri è già la descrizione. I confini (Boundary, Enterprise_Boundary, System_Boundary, Container_Boundary e il Node di C4Deployment) aprono una graffa e diventano un riquadro con titolo, anche annidati. Il collegamento è Rel(a, b, "etichetta", "tecnologia"); BiRel mette la freccia a entrambe le estremità e Rel_Back punta all'indietro. Il C4Dynamic numera le relazioni nell'ordine in cui compaiono. Le indicazioni di posizione (Rel_U, Rel_D, Rel_L, Rel_R) e gli Update…Style sono accettati e ignorati: la disposizione viene dallo stesso layout degli altri diagrammi e il colore dal tema della nota. Una relazione che cita un alias mai dichiarato rifiuta il diagramma indicando la riga, invece di inventare un riquadro che non hai scritto.

Bacheca, grafici e pacchetto

Nel kanban l'indentazione è la sintassi, su due livelli: quello esterno è la corsia e quello interno è la carta (id[Etichetta], oppure solo il testo). Il @{ ticket: LN-9, assigned: 'ana', priority: 'High' } dopo una carta non entra nel suo testo: ticket e responsabile finiscono in un piè di pagina proprio, e la priorità (Very High, High, Low, Very Low) diventa il colore della banda sul bordo sinistro, su una scala dal caldo al freddo. Tutte le corsie finiscono sulla stessa riga, e una corsia senza carte resta visibile — è lei a mostrare la colonna vuota. Questa è una bacheca disegnata, per spiegare un flusso dentro una nota; la bacheca su cui si lavora, con le carte da trascinare, è il pannello Attività dell'app stessa.

Il xychart (xychart-beta) disegna barre e linee su due assi: x-axis "Titolo" [gen, feb, mar] dà le categorie — un nome con spazio o virgola va tra virgolette —, y-axis "Titolo" 0 --> 100 fissa la scala e ogni bar [10, 40, 90] o line [20, 30, 80] aggiunge una serie, con un valore per categoria, nell'ordine in cui sono state dichiarate. Una serie con più o meno valori rifiuta il diagramma indicando la riga: le barre scivolerebbero su altre categorie e il grafico affermerebbe un'altra cosa. Senza y-axis la scala esce dai dati e parte da zero finché questi non scendono sotto — partire dal valore più piccolo esagera la differenza fra le barre, e nessuno l'ha scelto; con l'intervallo dichiarato, un valore fuori da esso viene rifiutato invece di sfondare il piano.

x-axis accetta anche un intervallo continuo (0 --> 100), e senza di esso le categorie sono gli indici. Due serie di barre compaiono affiancate, non sovrapposte come nel mermaid — sovrapposte, quella dietro sparisce. xychart-beta horizontal non è ancora disegnato e mantiene il blocco di codice, perché disegnarlo in verticale consegnerebbe il grafico trasposto. Una serie può avere un nome (bar "Aperti" [10, 40], line "Chiusi" [20, 30]): i nomi formano una legenda sopra il piano, ciascuno con la forma della propria serie — barra piena, linea con punto —, perché il solo colore non le distingue. E in una serie a linea un valore può portare un’etichetta ([540 "PaLM", 65]), disegnata sopra il punto; sulle barre l’etichetta viene ignorata, come in Mermaid.

Il radar (radar-beta) disegna il profilo di una o più curve su assi che partono dal centro: axis a["Etichetta"], b, c dichiara gli assi — la riga può ripetersi — e curve x["Nome"]{80, 60, 90} dà un valore per asse, nell'ordine in cui sono stati dichiarati; vale anche la forma con nome ({a: 80, c: 90, b: 60}). Attenzione al verso: il primo asse punta in alto e il giro è orario. max e min fissano la scala — senza max esce dal valore più grande letto — e un valore fuori scala rifiuta il diagramma indicando la riga, invece di essere troncato; ticks cambia il numero di anelli, graticule circle li rende tondi e showLegend false toglie la legenda. Anche una curva con più o meno valori degli assi viene rifiutata: non sarebbe un disegno incompleto, ma un altro disegno.

Il packet (packet-beta) disegna la mappa dei bit di un pacchetto: ogni campo è 0-15: "Etichetta", e l'intervallo è chiuso a entrambi gli estremi — 0-15 sono sedici bit. Un solo bit si scrive 4: "Etichetta", e la forma relativa +16: "Etichetta" prende i sedici successivi, per non dover ricontare tutto quando si inserisce un campo in mezzo. I campi devono essere contigui: un vuoto o una sovrapposizione rifiuta il diagramma indicando la riga, perché entrambi sposterebbero in silenzio tutto ciò che viene dopo. La riga contiene 32 bit, e un campo che supera il cambio di riga compare su entrambe, con l'etichetta nella parte più larga; i numeri sopra la griglia segnano dove inizia ogni campo, più l'ultimo bit di ogni riga.

Griglia, aree, architettura, flusso e ZenUML

Il block (block-beta) disegna una griglia di riquadri, e lì la posizione è l'ordine in cui li hai scritti: columns 3 fissa quante colonne ha la griglia — senza, tutto sta su una riga sola —, ogni riquadro accetta le forme del diagramma di flusso (a["Etichetta"], b(("cerchio")), c{"rombo"}), a:2 gli fa occupare due colonne e space (o space:2) lascia un vuoto. block:id … end annida una griglia dentro l'altra, con il proprio columns, e diventa un riquadro attorno. Le frecce sono quelle del diagramma di flusso (a --> b, con etichetta in a -- "testo" --> b), ma qui citano soltanto blocchi già dichiarati: una freccia verso un nome che non esiste rifiuta il diagramma indicando la riga, invece di inventare un riquadro in una cella che non hai scritto. Lo spazio fra le colonne cresce finché l'etichetta della freccia non ci sta, così non tocca il riquadro vicino. La freccia di blocco (a<["Andata"]>(right)) è un riquadro a forma di freccia: le direzioni vanno tra parentesi (right, left, up, down, oppure x per le due orizzontali e y per le due verticali) e si combinano ((x, down)); una direzione inventata rifiuta il diagramma indicando la riga, invece di diventare una freccia qualsiasi.

Il treemap (treemap-beta) disegna una mappa di aree: ogni rettangolo ha area proporzionale al valore, e l'indentazione annida, a profondità libera. La foglia dichiara il valore ("Nome": 12) e la sezione non dichiara nulla — il suo è la somma dei figli, e un totale proprio permetterebbe un rettangolo che mente sulle proprie parti, quindi viene rifiutato indicando la riga. Un nome con spazio o due punti va tra virgolette; classDef e :::classe danno il colore. La disposizione è lo squarified, che tiene i rettangoli vicini al quadrato: tagliare sempre sullo stesso asse produrrebbe strisce che non si confrontano a occhio, e confrontare aree è l'unica cosa che questo tipo fa. Etichetta e valore compaiono solo quando ci stanno per intero dentro il rettangolo: tagliati dal bordo non direbbero nulla.

L'architecture (architecture-beta) disegna servizi e i collegamenti fra loro: service api(server)[API] dichiara un componente, group nuvola(cloud)[Nuvola] apre un confine, il suffisso in nuvola mette il servizio dentro (i gruppi si annidano) e junction j crea un angolo per piegare un collegamento.

È il lato del collegamento a decidere la posizione: a:R -- L:b appoggia la destra di a alla sinistra di b, cioè mette b a destra di a; valgono L, R, T e B, e la punta compare dal lato del < o del > (-->, <-->, oppure -- senza punta). Il suffisso {group} su un estremo manda la linea al confine del gruppo invece che al riquadro interno. Le icone sono le cinque che Mermaid porta con sé — cloud, database, disk, internet e server — e qualsiasi altro nome rifiuta il diagramma indicando la riga e dicendo quali esistono. Le altre (logos:aws-lambda e simili) vengono da Iconify e compaiono solo dove chi pubblica la pagina registra il pacchetto via JavaScript, cosa che nemmeno GitHub fa: accettarle qui consegnerebbe un disegno che non si ripete da nessun'altra parte. L’align row a b c (o align column) mette i membri citati sulla stessa fila — o nella stessa colonna —, e un nome che non esiste rifiuta il diagramma indicando la riga, invece di lasciare la disposizione com’era senza dire perché.

Il sankey (sankey-beta) disegna un diagramma di flusso in cui lo spessore del nastro è il valore: il corpo non ha alcuna freccia — è un CSV a tre colonne (origine,destinazione,valore), un collegamento per riga, ed è ripetere un nome ai due estremi che concatena il flusso. Un'etichetta con la virgola va tra virgolette, e una virgoletta al suo interno si scrive raddoppiata ("Costo ""fisso"""); la stessa coppia origine/destinazione ripetuta si somma. La barra di un nodo è alta quanto il maggiore fra ciò che entra e ciò che esce, perché i nastri in uscita di un nodo che distribuisce più di quanto riceve non escano dal bordo. Le colonne derivano dal cammino più lungo fino a ciascun nodo, e ciò che non ha uscite va nell'ultima colonna. Un valore minore o uguale a zero, un collegamento di un nodo verso sé stesso e un ciclo rifiutano il diagramma indicando la riga — in un ciclo non esiste un cammino più lungo, e tagliare un collegamento per poter disegnare mostrerebbe un flusso che non hai scritto. Qui non c'è title: il corpo è CSV puro, e accettarlo disegnerebbe bene in LightNote e sarebbe un errore di sintassi in Mermaid.

Lo zenuml è un'altra sintassi per lo stesso disegno — un diagramma di sequenza —, scritta come codice invece che con frecce. La chiamata sincrona nomina solo la destinazione (Negozio.registra(articolo)) e il mittente è il blocco che la racchiude: dentro Negozio.registra() { Magazzino.riserva() }, chi chiama il Magazzino è il Negozio. Al livello esterno chi chiama è l'avviatore — @Starter(Ana) lo nomina, e senza di esso entra un User con l'omino, che compare solo se qualche chiamata ne ha bisogno. Il messaggio asincrono è A->B: testo (punta aperta, nessuno aspetta) e A->B.metodo() è la chiamata sincrona con il mittente scritto a mano. {} annida, return x torna a chi ha fatto la chiamata che lo racchiude (un if in mezzo non cambia nulla), x = A.m() è l'altra grafia della stessa risposta, new A(args) crea e // commento diventa una nota sopra il messaggio successivo. I blocchi sono if/else if/else, while/for/forEach/loop, opt, par e try/catch/finally — e } else { continua lo stesso riquadro, con un divisore, invece di aprirne un altro. @Actor disegna l'omino; gli altri annotatori (@Database, @Boundary…) diventano stereotipo nell'etichetta («Database» Magazzino), perché le loro icone qui non sono disegnate — il nome continua a comparire, ed è ciò che conta. Un nome con lo spazio va tra virgolette.

Attenzione a dove finisce questo blocco: in Mermaid lo zenuml è un diagramma esterno che la pagina deve registrare via JavaScript — GitHub non lo fa, quindi la stessa nota che qui si disegna lì appare come blocco di codice.

E quando LightNote non riesce a leggere un diagramma, dice perché e a quale riga, subito sotto il blocco — un tipo che non disegniamo ancora non produce avvisi, perché lì non c'è nulla di sbagliato.