03: Inline: enfasi, link, escaping

← 02 - Blocchi - paragrafi, liste, codice · Indice · successivo → 04 - GitHub Flavored Markdown

3.1 Enfasi: perché a*b*c e a_b_c si comportano diversamente

✅ verificato:

ScriviOttieni
a*b*cabc, corsivo indesiderato
a_b_ca_b_c, intatto
5*6*785678
foo**bar**bazfoobarbaz
foo__bar__bazfoo__bar__baz, intatto

Non è un capriccio. La regola sta nella specifica e si chiama flanking.

Un gruppo di * (o _) è:

  • left-flanking se è “appiccicato al testo che segue” (non è seguito da uno spazio);
  • right-flanking se è “appiccicato al testo che precede”.

Un * apre l’enfasi se è left-flanking, la chiude se è right-flanking. Punto. Per questo in mezzo a una parola funziona.

Per _ c’è una regola in più: non può aprire se è anche right-flanking (cioè se è in mezzo a una parola), a meno che il carattere precedente sia punteggiatura. È una scelta deliberata della specifica per proteggere snake_case, nomi_di_variabili e file_name.txt.

Regole operative

  1. Per l’enfasi usa * e **: sono più prevedibili in mezzo alle parole.
  2. Per proteggere del testo che contiene * o _, mettilo in code span (`a*b*c`): dentro i backtick non succede nulla.
  3. Se davvero ti serve un asterisco letterale nel testo, escapalo: a\*b\*c.

Ci sono altre regole più esotiche (la “regola dei multipli di 3”, che spiega perché certi *** non si chiudono come pensi). Quando qualcosa non torna, non tirare a indovinare: incollalo nel Dingus.

3.2 Code span

`codice`
``codice con ` dentro``
``` codice con `` dentro ```

Regola: un code span si apre con N backtick e si chiude con esattamente N backtick. Per includere backtick nel codice, usane di più all’esterno.

Seconda regola, meno nota: se il contenuto inizia e finisce con uno spazio (ma non è tutto spazi), viene rimosso un spazio per lato. Serve proprio a scrivere ` `: ` produce un backtick solo.

I code span vincono su tutto il resto: dentro non c’è enfasi, non ci sono link, non ci sono escape. È il tuo posto sicuro.

Quattro forme:

[testo](https://esempio.it)                       inline
[testo](https://esempio.it "titolo")              inline con title
[testo][etichetta]                                reference
[etichetta][]                                     collapsed
[etichetta]                                       shortcut
 
[etichetta]: https://esempio.it "titolo"

Le definizioni possono stare ovunque nel documento (anche in fondo) e non vengono renderizzate. Per un documento lungo con molti link ripetuti, le reference tengono il testo leggibile: il paragrafo resta pulito e gli URL stanno tutti insieme.

Cose da sapere:

  • I link non si annidano: [testo [interno](url)](url2) non fa quello che speri.
  • Nelle destinazioni le parentesi vanno bilanciate o escapate. Un URL Wikipedia con (disambigua) va scritto fra <...>: [voce](<https://it.wikipedia.org/wiki/X_(Y)>).
  • Gli spazi negli URL vanno percent-encodati (%20).
  • Il matching delle etichette è case-insensitive e normalizza gli spazi: [Foo Bar] e [foo bar] sono la stessa etichetta.
  • Se due definizioni hanno la stessa etichetta, vince la prima del documento.

Immagini: identiche ai link, con ! davanti. ![descrizione](percorso.png). Il testo fra parentesi quadre è l’alt text: serve agli screen reader e a chi ha le immagini disattivate. Non è decorativo, e i linter lo controllano.

In CommonMark puro un URL nudo non è un link: serve <https://esempio.it>. È GFM ad aggiungere il riconoscimento automatico di https://…, www.… e delle email (04 - GitHub Flavored Markdown). Se scrivi per un contesto non-GFM, usa le parentesi angolari o la forma esplicita [testo](url).

3.5 A capo dentro un paragrafo

Tre modi, con esiti diversi:

riga uno
riga due

→ softbreak: il browser lo rende come spazio. Le due righe finiscono attaccate.

riga uno··
riga due

(due spazi in fondo alla prima riga) → <br>. ✅ verificato. Ma è invisibile nel sorgente, e molti editor cancellano gli spazi finali al salvataggio, quindi l’a capo sparisce senza che tu tocchi nulla.

riga uno\
riga due

→ <br>. ✅ verificato. La specifica stessa lo presenta come “un’alternativa più visibile”. Usa questo.

Obsidian si comporta diversamente

Di default Obsidian rende un singolo invio come un a capo vero. C’è un’opzione, “Strict line breaks”, che riporta il comportamento a quello standard. È il motivo per cui una nota “impaginata bene” in Obsidian diventa un muro di testo una volta pubblicata.

3.6 Escaping

Qualunque carattere di punteggiatura ASCII può essere preceduto da \ per renderlo letterale: \` \* \_ \{ \} \[ \] \( \) \# \+ \- \. \! \| \< \> \\ e gli altri.

Davanti a qualsiasi altro carattere, il backslash resta un backslash: \A è \A.

Gli escape non funzionano dentro i code span, i blocchi di codice e l’HTML grezzo: lì il testo è già letterale.

I casi in cui serve davvero, ogni giorno:

Vuoi scrivereScrivi
un asterisco letterale\*
un underscore in mezzo a parola in contesto ostile\_ o code span
una parentesi quadra che non apre un link\[
un # a inizio riga che non è un heading\#
una pipe dentro una cella di tabella|
un +, - o 1. a inizio riga che non è una lista\-

3.7 Entità HTML

&amp;, &copy;, &#8212; funzionano e vengono convertite. Con due limiti: non funzionano dentro il codice (giustamente), e non possono sostituire caratteri strutturali: &#42; non diventerà mai un delimitatore di enfasi né un bullet.

Esercizi

  1. Scrivi una frase che contenga nome_variabile, 2*3*4 e un percorso C:\temp\file. Rendila corretta senza usare i backtick, poi rifalla usando i backtick. Confronta la leggibilità del sorgente.
  2. Converti un documento con dieci link ripetuti dalla forma inline a quella reference.
  3. Prendi una nota Obsidian con molti a capo singoli e guarda cosa succede attivando “Strict line breaks”. È quello che vedranno gli altri.
  4. Prova a linkare https://it.wikipedia.org/wiki/Roma_(disambigua) e fallo funzionare.