Markdown on Melabit

Fare una Maggie

Mon, 28 Jul 2025 06:00:00 +0000

L’ultimo articolo mi ha fatto letteralmente impazzire. Non per la lunghezza, anche se scrivere un testo di più di tremila parole e ventimila caratteri in due lingue diverse non è una sciocchezza.

Il vero problema è nato dal fatto che a un certo punto il file Markdown dell’articolo si è corrotto. Quando Hugo provava a convertirlo in HTML, il file generato conteneva, al posto delle lettere accentate italiane, il carattere di sostituzione �, quel rombo nero con dentro un punto interrogativo bianco che abbiamo visto in tante email e pagine web.

Ci ho perso ore prima di risolvere il problema.

Quando un file Markdown si corrompe

La prima ipotesi è stata che il file contenesse qualche carattere spurio, come uno spazio che non è davvero uno spazio, oppure una di quelle lettere strane che qualche anno fa hanno creato un certo scompiglio. Un bel problema cercarle nel testo, per cui ho fatto il contrario e ho scritto una espressione regolare che cercasse tutto ciò che non era normale, raffinandola via via che procedevo.

Alla fine l’espressione regolare è diventata questa.

[^a-zA-Z0-9àèéìòùÀÈÉÌÒÙ ,.;:`'"()\[\]\-^/_*#\n]

Una cosa molto terra-terra, ma l’importante è che funzionasse. Purtroppo non ha trovato niente di strano.

Per cercare di restringere il più possibile l’area che poteva contenere l’errore, ho iniziato a togliere parti di testo, prima poche righe e poi intere sezioni, ricompilando ogni volta il file tagliuzzato con Hugo. Niente, non c’era verso di togliere quegli stramaledetti rombi neri!

E qui ho fatto la cosa davvero decisiva: dopo aver provato e riprovato senza successo, ho lasciato perdere e sono andato a cena.

Sì, perché quando non si riesce a risolvere un problema – che sia risolvere un difficile esercizio di matematica, far funzionare un programma o scrivere l’attacco di quel post che ci frulla in testa da ore – la cosa migliore da fare è lasciare perdere e dedicarsi ad altro. Non so voi, ma con me funziona sempre alla grande.

E dopo cena mi è venuta l’idea: ho fatto una Maggie e tutto è andato a posto.

– Immagine generata da Google Gemini.

Fare una Maggie

Maggie è il diminutivo di Margaret Secara, diventata famosa per un trucco, semplice ma molto efficace, per recuperare un documento Word corrotto: cliccare sull’icona ¶ della Barra Multifunzione di Word per attivare la visualizzazione dei caratteri di formattazione (se la finestra di Word è stretta, l’icona potrebbe nascondersi all’interno della sezione dedicata ai paragrafi), poi selezionare tutto il testo tranne l’ultimo carattere di Invio (come mostrato in figura) e incollarlo in un nuovo documento vuoto.

Se non funziona, si può ripetere il procedimento copiando parti successive del testo in un nuovo documento, in modo da circoscrivere il più possibile la porzione corrotta.

La prima volta che ho usato questo trucco stavo lavorando su un documento di più di cento pagine, passato per parecchi colleghi e differenti versioni di Word, che era diventato ingestibile: ogni nuovo carattere impiegava secondi per comparire sullo schermo e Word andava continuamente in crash. Con la procedura descritta ho risolto il problema in un battibaleno.¹

Il trucco di Maggie funziona perché i file Word hanno una doppia struttura. La prima è quella che mostrata sullo schermo del computer, fatta di testo, immagini e tabelle, con divisioni in capitoli, sezioni e paragrafi, con grassetti, italici, sottolineature, con interruzioni di pagina, liste, rientri, tutte cose messe lì un po’ a casaccio dall’utente.

La seconda struttura è quella del file XML sottostante, che dopo un po’ di aggiunte, correzioni, cancellazioni, ripensamenti, diventa un fritto misto di tag XML innestati uno sull’altro, che rimangono però sempre invisibili all’utente e non vengono mai ripuliti e ristrutturati in modo coerente dal programma.

A meno di non farlo noi a mano, copiando tutto il testo in un nuovo documento, ma evitando come la peste l’ultimo carattere di Invio che, per qualche motivo arcano, contiene la chiave di accesso alle porcherie nascoste del documento Word.

Margaret Maggie Secara avrà scoperto questo trucco per caso, ma si è rivelato così utile da trasformare il suo soprannome in una parola vera e propria, come Kleenex, Band-Aid, Post-It, Tupperware o Google.

Ma sono documenti di testo!

Però i miei post li scrivo in Markdown, mica con Word. Ma anche così, ripartire da un documento fresco e copiarci dentro il contenuto di quello corrotto può rivelarsi il metodo più veloce per risolvere tanti problemi.

Ovviamente il trucco funziona con qualunque tipo di documento in testo puro, che sia scritto in Markdown, LaTeX, HTML, XML, JSON, Org mode… o in qualsiasi altro formato più o meno arcano che vi venga in mente.

Anzi, proprio perché, a differenza di Word, un documento di testo non nasconde nulla all’utente, non serve nemmeno evitare di copiare l’ultimo carattere di Invio; si può selezionare tranquillamente tutto il testo, copiarlo e incollarlo in un nuovo file vuoto.

Prima di farlo è sempre bene controllare che il testo non contenga dei caratteri spuri, utilizzando una espressione regolare simile a quella riportata più sopra.

E con questo l’articolo è finito. Le due sezioni qui sotto sono riservate solo ai più curiosi, che vogliono sapere cosa mi era successo davvero.

Solo per i più curiosi…

Perché il metodo funziona?

Una volta risolto il problema immediato, la curiosità ha avuto il sopravvento e mi sono chiesto perché il metodo descritto funziona con i documenti di testo. Come succede spesso, lavorare dal Terminale aiuta a risolvere i problemi più spinosi.

In un normale editor come BBedit o TextMate, il file corrotto appare perfettamente normale, ma se lo si visualizza nel Terminale con cat, si nota subito che tutti i caratteri accentati vengono sostituiti da dei ?, più o meno come succede convertendolo in HTML.

Il comando file dà poi la risposta definitiva. Se lo applico al file corrotto, file 2025-07-22-macos-tahoe-developer-beta-3.md, ottengo in risposta

Non-ISO extended-ASCII text, with very long lines (1264)

mentre con un qualunque altro file Markdown il risultato è (come è giusto che sia)

Unicode text, UTF-8 text, with very long lines (1264)

In altri termini, il file aveva perso la codifica UTF-8, trasformandosi in un generico file di testo non-standard.

Se me ne fossi accorto prima, avrei potuto usare iconv per correggere la codifica del file, ma in questo caso non c’è dubbio che il copia-e-incolla è molto più pratico.

Cos’è successo davvero?

Difficile a dirsi, ma ci sono degli indizi. Dato che l’articolo era molto lungo, l’ho scritto in più riprese un po’ sul Mac Mini e un po’ sull’Air.

In genere copio i file di lavoro in locale e li sincronizzo solo in un secondo momento. Ma questa volta cambiavo continuamente computer, per cui ho preferito lavorare direttamente sulla cartella sincronizzata (usando Syncthing, ma non credo che sia stato lui il responsabile; in quel caso avrei trovato dei file in conflitto, che invece non ci sono). Invece ci sono stati ogni tanto dei problemi di rete, e penso che sia stato proprio questo che ha finito per corrompere la codifica del file.

La morale? Lavorare in locale e sincronizzare solo quando si è finito. Oppure lavorare direttamente in rete solo quando il collegamento è stabile.

Ma quando non si può, meglio ricordarsi dei consigli della buona vecchia Maggie.

Pare che si possa recuperare un documento Word senza perdere traccia delle modifiche effettuate. La guida usa delle combinazioni di caratteri tipiche di Word per Windows, e quindi non è immediato applicarla alla versione per macOS. ↩︎

Modifiche a colpo d'occhio con SubEthaEdit

Mon, 27 Nov 2023 06:00:00 +0000

– Fonte: Possessed Photography su Unsplash.

SubEthaEdit (SEE per brevità) è un editor per macOS discreto, che fa più o meno tutto ciò che ci si aspetta da un editor moderno (con alcune mancanze significative), e che in più ha la particolarità di permettere a più utenti collegati di lavorare in modo collaborativo allo stesso documento.

Di queste caratteristiche generali ho già scritto nell’articolo precedente. In questo articolo, invece, voglio soffermarmi sulla funzione di SEE che mi ha colpito di più in assoluto, cioè la possibilità di mettere bene in evidenza tutte le modifiche effettuate su un documento di testo anche quando non si collabora con altri utenti, una funzione molto particolare ma che in certi casi può diventare davvero un toccasana.

Modifiche in evidenza

A che serve evidenziare le modifiche ad un testo? Serve tutte le volte in cui si debba mostrare in modo chiaro e tracciabile all’editore, al committente, al cliente, o semplicemente ai colleghi, cosa è stato cambiato in un dato documento, come succede molto spesso nell’editoria scientifica ma anche in tanti altri settori professionali.

Con un wordprocessor non è un problema, Word e i suoi cloni hanno uno strumento integrato di revisione del testo che, per quanto pesante e implementato in modo farraginoso, fa il suo lavoro. Ma come può fare chi preferisce scrivere in modalità solo testo, usando LaTeX o il sempre più popolare Markdown?

Questi due strumenti permettono di segnalare le modifiche inserendole all’interno di tag dedicati (\hl{testo modificato} per LaTeX e {==testo modificato==} per Markdown), ma è fastidioso dover aggiungere i tag mentre si procede alla revisione del testo, con il rischio di perdere il filo del discorso e di allungare i tempi di lavoro.

Come mi sono accorto da poco, SEE può essere un ottimo strumento per risolvere questo problema.

La funzione di evidenziazione del testo modificato di SubEthaEdit può essere attivata una volta per tutte selezionando l'opzione `Highlight Changes when not collaborating posta in cima al pannello `General` delle Preferenze, e sarà valida per tutti i nuovi documenti aperti nel programma.

Se vogliamo attivarla anche nel documento corrente, dobbiamo andare nel menu View e selezionare la voce Highlight Changes.

Da questo momento in poi, tutte le modifiche o le aggiunte al testo corrente verranno messe in evidenza da un fondo colorato in giallo (il colore si può cambiare nella sezione Collaboration delle solite Preferenze).

Un caso personale

Alcune settimane fa dovevo modificare un articolo scritto in LaTeX che richiedeva la riscrittura o l’aggiunta di grosse porzioni di testo, nonché la correzione di un bel po’ di errori di inglese, il tutto con la necessità di mettere bene in evidenza tutte le modifiche effettuate, anche al livello delle singole parole.

LaTeX ha una funzione specifica per mettere in evidenza il testo modificato (\hl, che sta per highlight), il problema è che, quando le modifiche sono tante, è difficile riuscire a ricordarsi di circondare anche il più piccolo pezzetto di testo modificato con \hl{...} senza perdere il filo del discorso e finire per dimenticare qualcosa di importante.¹

Ho provato i miei soliti editor,² per vedere se potevano offrire qualcosa che faceva al caso mio ma, a parte (ovviamente) Emacs,³ non ho trovato niente più del solito diff, uno strumento da Terminale molto usato dai programmatori che mette a confronto due file diversi e segnala quali righe sono state modificate.

Ma, appunto, con diff possiamo vedere quali righe sono cambiate, non cosa è cambiato in ciascuna riga! Per un programmatore non è un problema, perché le righe di codice sono brevi ed è facile notare le differenze, ma in un documento LaTeX una singola riga può corrispondere ad un lungo paragrafo di testo, ed è quindi molto più difficile notare a prima vista cosa è cambiato rispetto al testo originale.⁴

Ci sono altri strumenti a linea di comando che avrebbero potuto fare al caso mio, come wdiff, che bisogna installare con Homebrew, oppure git diff --word-diff, ma usarli avrebbe complicato ulteriormente un lavoro già di per sé piuttosto complesso.

Un po’ per caso un po’ per fortuna ho lanciato SEE, che avevo installato sul Mac senza usarlo mai più di tanto, e mi sono accorto che faceva perfettamente al caso mio.

Con questo editor il lavoro di revisione è stato semplicissimo: mi bastava prendere un blocco di testo dal file originale in LaTeX, copiarlo nella finestra di SEE e inserire via via le correzioni, vedendole tutte chiaramente e in tempo reale con il loro fondo giallo. Una volta finita la revisione di tutto il blocco, potevo circondare tutte le parti di testo evidenziate con hl{...}, per poi sostituire il testo rivisto a quello del file originale LaTeX.

Vi assicuro, descrivere la procedura è molto più complicato che realizzarla, tanto che sono riuscito a completare tutta la revisione in appena un paio di giorni, perché SEE mi permetteva di concentrarmi esclusivamente sulla riscrittura del testo, rimandando la gestione minuta delle modifiche solo alla fine della correzione dell’intero blocco.⁵

Perché tutta questa trafila di copia e incolla da LaTeX a SEE e viceversa? Non sarebbe stato più semplice lavorare solo in SEE? Certo, ma l’articolo originale era su Overleaf e volevo che i colleghi potessero continuare ad accedere all’ultima versione anche mentre io ci lavoravo. E poi SEE ha un grosso difetto, perché non conserva le evidenziazioni quando si salva un documento e lo si riapre una seconda volta. Sarebbe bastata quindi una distrazione, un blocco imprevisto del Mac o magari un banale calo di tensione per perdere di colpo traccia di tutte le modifiche più recenti. Non potevo permettermelo e non ho voluto rischiare.⁶

A questo proposito, ho chiesto agli sviluppatori di rendere permanenti le evidenziazioni del testo, ma dopo due mesi non ho avuto risposta e temo che la richiesta non sarà soddisfatta, almeno in tempi brevi.

Dal personale al generale

Ma questa funzione particolare di SEE serve solo a chi, come me, si muove nell’ambito dell’editoria scientifica? Non credo, in realtà mettere bene in evidenza le modifiche ad un documento è una funzione molto utile in svariati settori professionali, e spesso sono proprio i committenti o i clienti a richiedere esplicitamente che il documento contenga una visualizzazione chiara di tutti i cambiamenti subiti.

Non a caso la funzione di revisione con evidenziazione delle modifiche effettuate è molto usata da chi scrive in Word, sia quando lavora in collaborazione con altri che quando deve semplicemente correggere un documento altrui.

L’implementazione delle revisioni in Word è molto macchinosa (e come poteva essere diversamente?) e le modifiche possono essere visualizzate in molti modi diversi, una flessibilità che però tante volte genera solo confusione quando si aprono dei documenti altrui. Nella modalità di visualizzazione più dettagliata si arrivano a vedere le singole lettere aggiunte o cancellate, e il tutto diventa presto un guazzabuglio incomprensibile di testo barrato e testo colorato, con configurazioni e colori diversi per ciascun utente. Considerazioni analoghe si possono fare anche per altri sistemi di scrittura come LibreOffice Writer o Google Docs, che forse riescono a fare persino peggio di Word.

In ogni caso, Word sarà anche molto popolare ma tanti, come me, preferiscono usare sistemi di scrittura basati sul testo puro, come LaTeX o il popolarissimo Markdown, che ha parecchi segni speciali per gestire le evidenziazioni di un blocco di testo ({==testo evidenziato==}), così come le aggiunte ({++testo aggiunto++}), le ~~cancellazioni~~ ({--testo cancellato--}), e perfino le ~~modifiche~~ sostituzioni ({testo precedente>testo sostituito~}).

Quando le modifiche da fare sono tante, come ci si può concentrare sul testo da rivedere senza perdere il filo del discorso, quando bisogna inserire di continuo i tag, piuttosto complessi in verità, che indicano tutti i cambiamenti effettuati?

SubEthaEdit può essere un’ottima risposta a questo problema.

Una funzione analoga ce l’ha anche Markdown, che usa i tag {== e ==} per mettere in evidenza il testo compreso fra essi. Purtroppo non tutti gli interpreti Markdown supportano questi tag (fra cui, purtroppo, l’interprete usato da Wordpress.com), una particolarità che crea non poca confusione.
Per aggirare il problema, si può usare la coppia di tag standard HTML5 <mark>testo evidenziato</mark>, che di default produce un testo con uno sfondo giallo (ma si possono usare facilmente altri colori). ↩︎
Per i più curiosi, i miei editor sono, in ordine di preferenza, TextMate, BBEdit e Visual Studio Code, che ho dovuto adottare al posto del defunto Atom. Uso anche la versione per macOS di GNU Emacs, ma ammetto di farlo molto meno spesso di quanto vorrei. ↩︎
Emacs dispone dell’highlight-changes-mode che avrebbe fatto perfettamente al caso mio, ma c’erano dei motivi pratici che mi impedivano di usarlo. ↩︎
E comunque diff lavora su due file diversi, una cosa che nel mio caso particolare avrebbe aggiunto un ulteriore livello di complicazione. ↩︎
L’ho già detto ma è meglio ripetere: a differenza di altri strumenti che confrontano due file separati, uno contenente il testo originale e l’altro quello modificato, SEE opera in tempo reale e direttamente sul testo in lavorazione, semplificando parecchio il lavoro di revisione ↩︎
In effetti ci sarebbe un’altra opzione, usare Meld. Ma fino a poco tempo fa, per motivi che mi sfuggono, Meld si rifiutava di partire sul mio Mac con macOS Monterey, per cui non ho provato nemmeno ad usarlo per questo lavoro. Da un po’ però funziona, per cui potrebbe essere argomento per un prossimo articolo. ↩︎

Qual è la somma? Soluzioni

Mon, 14 Dec 2020 06:00:00 +0000

– Foto di NeONBRAND su Unsplash.

Ed ecco la soluzione promessa al problema di ieri. Anzi, LE soluzioni, perché ce ne sono parecchie, più o meno complicate o, meglio, più o meno adatte al modo di pensare di ciascuno.

Il problema era:

Ciascun termine di una serie geometrica è il doppio del precedente. In una certa serie geometrica, la somma del settimo, ottavo e nono termine fa 3. Qual’è la somma del quarto e quinto termine?

In un primo momento può sembrare un problema complicato, ma basta pensarci un po’ per accorgersi che in realtà la soluzione è abbastanza semplice.

Serie geometrica

Come spiega l’enunciato stesso del problema, una serie geometrica è composta da un numero in teoria infinito di termini, ciascuno dei quali è il doppio di quello precedente. Ad esempio, la serie geometrica più semplice che mi viene in mente è

1, 2, 4, 8, 16, 32, 64…

nella quale 1 è il primo termine della serie, 2 il secondo termine e così via, e ciascun termine (ad esempio 8) è il doppio di quello che lo precede (in questo caso 4). (Volendo ci sarebbe una serie geometrica ancora più semplice, composta tutta da zeri, 0, 0, 0, 0, …, ma è un caso particolare molto banale).

Ogni termine della serie può essere indicato con una variabile a cui viene associato un pedice (cioè un numero scritto più in basso rispetto al nome della variabile), che aiuta ad individuare più facilmente il termine della serie a cui ci stiamo riferendo. As esempio a₁, a₂, a₃, indicano rispettivamente il primo, secondo e terzo termine della serie. Per una serie geometrica, a₂ = 2 a₁, a₃ = 2 a₂ = 4 a₁, e così via.

Soluzione #1

In base a quanto appena detto, definiamo il settimo, ottavo e nono termine della serie come a₇, a₈ e a₉. Il problema ci dice che la somma di questi termini è uguale a 3,

a₇ + a₈ + a₉ = 3

Ma abbiamo anche altre informazioni, perché sappiamo che a₈ = 2 a₇ e a₉ = 2 a₈. Possiamo quindi scrivere un sistema di tre equazioni in tre incognite,

a₇ + a₈ + a₉ = 3 a₈ = 2 a₇ a₉ = 2 a₈

che può essere semplificato tenendo conto delle relazioni fra a₇, a₈ e a₉ e esprimendo le tre equazioni in funzione della sola a₇,

a₇ + (2 a₇) + (4 a₇) = 3 a₈ = 2 a₇ a₉ = 4 a₇

La prima delle tre equazioni del sistema diventa 7 a₇ = 3, cioè

a₇ = 3 ⁄ 7

A questo punto è facile, perché a₆ è la metà di a₇, a₅ un quarto di a₇ e a₄ un ottavo, sempre di a₇. Quindi

a₆ = 3 ⁄ 14 a₅ = 3 ⁄ 28 a₄ = 3 ⁄ 56

da cui si ottiene che

a₄ + a₅ = 3 ⁄ 28 + 3 ⁄ 56 = (2 × 3 + 3) ⁄ 56 = 9 ⁄ 56

che è la soluzione del problema.

Soluzione #2

In realtà non c’è bisogno di mettere su un rigoroso sistema di tre equazioni in tre incognite, perché dalla definizione di serie geometrica sappiamo immediatamente che

a₇ + a₈ + a₉ = a₇ + 2 a₇ + 4 a₇ = 3

da cui ricaviamo immediatamente che a₇ = 3, e tutto il resto è identico al caso precedente.

Soluzione #3

Questa soluzione funziona al contrario delle due precedenti, che partono dai termini di ordine maggiore per calcolare quelli di ordine inferiore. In base alla definizione di serie geometrica,

a₂ = 2 a₁, a₃ = 4 a₁, a₄ = 8 a₁, a₅ = 16 a₁, a₆ = 32 a₁, a₇ = 64 a₁, a₈ = 128 a₁, a₉ = 256 a₁

Di conseguenza,

a₄ + a₅ = 8 a₁ + 16 a₁ = 24 a₁

a₇ + a₈ + a₉ = 64 a₁ + 128 a₁ + 256 a₁ = 448 a₁ = 3

Da questa eguaglianza si ricava il primo termine della serie, a₁ = 3 ⁄ 448, e quindi

a₄ + a₅ = 24 a₁ = 24 × 3 ⁄ 448 = 72 ⁄ 448 = 9 ⁄ 56.

Soluzione #4, 5, …

Se qualcuno trova delle soluzioni diverse al problema, sarò ben felice di aggiungerle qui.

Markdown e LaTeX

Markdown mi piace moltissimo e infatti lo uso per scrivere tutti i miei post, così come tanti documenti di lavoro che non devono circolare oltre il circolo, purtroppo ristretto, di chi è in grado di scrollarsi di dosso Word. Purtroppo devo ammettere che il supporto a LaTeX è abbastanza inconsistente. Va benissimo finché si tratta di scrivere delle equazioni semplici, ma appena le cose si complicano, ad esempio quando si prova ad inserire un sistema di equazioni, sono dolori.

Ancora peggio è il fatto che la resa finale dipenda dal motore di conversione. Ad esempio, Marked converte quasi sempre perfettamente le equazioni fuori testo (quelle centrate in uno spazio apposito), sia quando si usano i simboli $$ prima e dopo l’equazione sia inserendole all’interno dell’ambiente \begin{equation} ... \end{equation}. Ma se l’equazione incapsulata fra $$ ... $$ contiene dei pedici (o degli apici) Marked dà un errore, che invece non compare se si usa l’ambiente \begin{equation} ... \end{equation} (meno usato perché molto più lungo da scrivere).

Ancora peggio è quello che succede con il motore LaTeX di Wordpress.com, che non supporta l’ambiente \begin{equation} ... \end{equation} e nemmeno la forma abbreviata $$ ... $$, ma che per integrare le equazioni nel testo in Markdown usa una sintassi non standard, $latex ... $ (dove il codice LaTeX va inserito al posto dei puntini).

D’altro canto Markdown nasce per essere uno strumento semplice per scrivere sul web, caricarlo di troppe opzioni (e di troppe responsabilità) sarebbe un controsenso. In casi come questi forse la cosa migliore è scrivere il testo direttamente in LaTeX, convertendolo poi in HTML puro tramite pandoc o simili.

Io avevo già scritto quasi tutto il testo quando mi sono accorto di questi problemi e per questa volta ho preferito eliminare il codice LaTeX ed usare solo il normale HTML per indicare i pedici o le frazioni, perché la resa grafica delle equazioni fuori testo era davvero pessima. Basta confrontare questa equazione scritta in LaTeX,

$latex \begin{array}{ll} a_7 + a_8 + a_9 = 3\ a_8 = 2 a_7\ a_9 = 2 a_8 \end{array}$

con questa in HTLM mescolato al normale codice Markdown,

a₇ + a₈ + a₉ = 3 a₈ = 2 a₇ a₉ = 2 a₈

per rendersene conto. Purtroppo l’HTML non riesce a gestire bene le frazioni (o forse sono io che non so come fare), prometto di far meglio la prossima volta.

Qual è la somma?

Sun, 13 Dec 2020 06:00:00 +0000

– Foto di Antoine Dautry su Unsplash.

È domenica, bisogna stare in casa (perché voi cercate di stare il più possibile in casa, vero?), perché non dedicarsi ad un piccolo problema di matematica? Il problema è:

Ciascun termine di una serie geometrica è il doppio del precedente. In una certa serie geometrica, la somma del settimo, ottavo e nono termine fa 3. Qual’è la somma del quarto e quinto termine?

La risposta richiede un po’ di matematica al livello della scuola superiore oppure una certa pratica con i rompicapi stile Settimana Enigmistica (“Giovanni ha la camicia verde ed è stempiato. Luca ha l’ombrello. … Di chi è il cane?”). E magari anche un po’ di attenzione nell’osservare certi dettagli…

Per chi non riuscisse a trovare la soluzione, appuntamento a domani. Sarà anche l’occasione per provare un po’ meglio come Markdown (con cui scrivo tutti i miei post) gestisce le equazioni scritte in LaTeX.

A proposito di Quick Look

Mon, 16 Mar 2020 06:00:00 +0000

– Fonte: Lucas Benjamin su Unsplash.

Come già visto nel post precedente, Quick Look permette di visualizzare l’anteprima di un gran numero di tipi di file direttamente nel Finder e nella maggior parte delle applicazioni integrate in macOS, nonché in applicazioni di terze parti che gestiscono i file come ForkLift o Cyberduck.

Per attivare Quick Look basta selezionare un file e premere la barra spaziatrice oppure ⌘-Y. Una volta attivato, se si seleziona un altro file con il mouse o i tasti freccia, Quick Look aggiorna automaticamente l’anteprima. A partire da macOS 10.14/Mojave, Quick Look ha acquisito delle ulteriori funzioni, che ne fanno in pratica un clone di Anteprima.

Quick Look è stata introdotto nell’ormai lontano 2009 con Leopard (cioè Mac OS X 10.5) ed è subito diventato uno dei miei strumenti preferiti di macOS, una di quelle cose che fanno la vera differenza rispetto agli altri sistemi operativi sulla piazza. Ed è rimasto tale anche quando, con macOS 10.11/El Capitan, Apple ha disgraziatamente disabilitato la funzione che permetteva di selezionare e copiare un brano di testo direttamente dall’anteprima di Quick Look.

Quick Look supporta nativamente un gran numero di tipi di file, ma ci sono alcune clamorose omissioni, come ad esempio la possibilità di visualizzare l’anteprima dei file Markdown.

Per fortuna esistono parecchi plugin di terze parti che permettono di estendere o migliorare le funzionalità di Quick Look. Il sito Quick Look Plugins List li raccoglieva tutti, ma non viene aggiornato da più di un anno. In alternativa si può consultare l’articolo Handy macOS QuickLook configurations, che contiene una lista di plugin utili per la maggior parte degli utenti, oppure il progetto ospitato sul solito GitHub, List of useful Quick Look plugins for developers, che elenca i plugin più interessanti per uno sviluppatore.

Per quanto mi riguarda, io non potrei fare a meno di questi plugin:

QuickLookCSV, che produce una anteprima dei file .csv decisamente migliore rispetto a quella ottenibile con gli strumenti nativi di Quick Look;
QLColorCode, che colora le parole chiave dei programmi scritti nei principali linguaggi di programmazione (funziona perfino con il venerando, e venerabile, Fortran);
QLStephen, che permette di visualizzare l’anteprima di un gran numero di file di testo non supportati da Apple;
QLMarkdown, che visualizza l’anteprima dei file Markdown. Volendo si può anche usare QLCommonMark, il cui sviluppo però è fermo da tre anni. Sono entrambi ottimi, scegliere uno o l’altro è solo una questione di gusti personali.

L’installazione di un plugin di Quick Look è piuttosto semplice. Basta scaricare il plugin che ci interessa, scompattare eventualmente il file .zip scaricato, e infine copiare il file .qlgenerator risultante

nella cartella ~/Libreria/QuickLook/, dove il simbolo ~ indica la cartella principale (la Home) dell’utente che sta usando il Mac (se la cartella in questione non esiste, createla voi stessi);
oppure nella cartella /Libreria/QuickLook/ contenuta nel disco di avvio, per rendere il plugin utilizzabile da tutti gli utenti del Mac.

Per chi usa Homebrew è ancora più semplice (e chi non usa ancora Homebrew dovrebbe decidersi a farlo, magari leggendo la serie di articoli che ho scritto qualche anno fa). Bisogna aprire il Terminale, aggiornare Homebrew,

$ brew update

e installare il plugin desiderato, ad esempio qlstephen , con il comando

$ brew cask install qlstephen

dove brew cask è una estensione di Homebrew che permette di installare un gran numero di applicazioni per macOS direttamente dalla linea di comando, fra cui un gran numero di plugin di Quick Look. Come sempre,

$ brew cask uninstall qlstephen

rimuove il plugin installato con Homebrew.

Come al solito, il $ iniziale non fa parte del comando ma serve solo ad indicare il prompt del Terminale, per cui va tralasciato quando si copiano i comandi di questo articolo.

Per attivare un nuovo plugin bisogna uscire e rientrare nel proprio account o almeno riavviare il Finder, cosa che si fa cliccando sull’icona del Finder nel Dock mentre si premono i tasti CTRL (⌃) e ALT (⌥) e scegliendo la voce di menu Riavvia. Dal Terminale è ancora più semplice, basta eseguire

$ qlmanage -r
qlmanage: resetting quicklookd

per ricaricare istantaneamente tutti i plugin di Quick Look installati. Altro comando piuttosto utile è

$ qlmanage -r cache

che cancella la cache delle anteprime generate da Quick Look. La presenza di una cache, infatti, ha serie implicazioni legate alla privacy, dato che permette a chiunque abbia l’accesso al Mac di ottenere informazioni importanti sui documenti esaminati nelle ultime settimane.

Markdown online

Tue, 31 Mar 2015 06:00:00 +0000

Markdown è uno strumento che permette di scrivere testi per il web utilizzando una sintassi semplificata rispetto a quella un po’ bizantina del linguaggio HTML e di convertire tali testi in codice HTML valido, pronto per essere incluso in una pagina web perfettamente funzionale.

Con il tempo, l’uso di Markdown si è esteso notevolmente ed ora è possibile usarlo per scrivere documenti di qualunque genere, convertendol in qualunque formato di testo significativo tramite Pandoc.

Io uso da tempo Markdown ogni giorno per scrivere di tutto, fra cui tutti i post di questo blog. Le uniche eccezioni sono gli articoli scientifici, per cui LaTeX è ancora insuperabile, e i documenti inviati dai colleghi, che mi obbligano ad usare l’odiato Word.

Quello che trovo però molto difficile è provare a spiegare l’utilità di Markdown a chi non l’ha mai usato. La risposta normale è “Perché mai imparare ad usare un altro strumento quando c’è già Word che va benissimo?”

Purtroppo in parte hanno ragione: finché non lo si prova è difficile rendersi conto dei vantaggi di Markdown e della sua estrema semplicità di uso.

Invece di provare a spiegare in teoria perché usare Markdown, non sarebbe meglio mostrare degli strumenti semplici semplici per iniziare ad usarlo senza troppi problemi?

E cosa c’è di meglio, oggi, che usare strumenti che funzionano direttemente nel browser, senza nulla da scaricare, installare o configurare?

Imparare Markdown

Per questo non c’è storia, il sito migliore è di sicuro This is Markdown, che insegna la sintassi di Markdown tramite una pagina web interattiva, che può essere modificata direttamente nel browser visualizzando immediatamente il risultato delle modifiche effettuate.

Strumenti di conversione

Anche qui non c’è molto da dire, lo strumento più interessante è Try pandoc!, che permette di usare Pandoc dal browser per convertire un documento scritto in Markdown (o in una dozzina di altri formati di testo) in formato HTML, RTF, LaTeX, oltre che in varie implementazioni di Markdown e in altri formati di testo meno noti.

Un altro strumento utile è Babelmark 2, che permette di valutare le differenze fra il codice HTML generato dalle varie implementazioni (dialetti?) di Markdown.

Detto fra parentesi, l’esistenza di svariate implementazioni di Markdown leggermente differenti l’una dall’altra è la vera debolezza di questo strumento di scrittura. Spero vivamente che prenda piede una implementazione standard come quella proposta da CommonMark (anche se criticata, a mio modesto parere un po’ scioccamente, da John Gruber, l’ideatore di Markdown).

Heck Yes Markdown fa il contrario: prende una pagina web e la converte in Markdown. Utilissimo per convertire in questo formato dei documenti scritti in passato in HTML, magari allo scopo di creare un archivio di pagine web in un formato uniforme o di riutilizzarli per un sito web statico. Ma forse altrettanto utile per implementare con il solo Markdown uno strumento simile a Readability. Da provare con i siti più pesanti e carichi di pubblicità e animazioni.

Editor online

In questo campo c’è solo da scegliere: gli editor online di Markdown sono fin troppi.

Per un uso occasionale consiglio, in ordine (molto) personale di preferenza, Dillinger, che permette di importare e salvare i documenti in Dropbox, Google Drive, One Drive e GitHub, StackEdit, il più completo e facile da usare, con sincronizzazione opzionale dei documenti con alcuni servizi cloud, Markdown Web Dingus di John Gruber, con una colonna con la sintassi di Markdown, Showdown, contenente una guida molto dettagliata alla sintassi di Markdown e Socrates, decisamente pulito e minimale. Tutti questi editor non richiedono registrazione e possono essere usati immediatamente, ma hanno lo svantaggio di non permettere il salvataggio dei documenti prodotti, a meno di non usare qualche servizio cloud come quelli citati sopra.

Per un uso più continuativo, oltre a Dillinger e StackEdit, consiglio di provare anche Beegit, che permette a più persone di collaborare alla stesura dello stesso documento, Draft, il più completo oltre che il più bello dal punto di vista grafico e Markable, che purtroppo, non so perché, mi fa pensare a un prodotto pensato per Windows.

Peccato solo per Editorially, un ottimo editor online che ha avuto però una vita molto breve.

La versione di Apple

Sun, 22 Dec 2013 06:00:00 +0000

Fra le funzioni più utili introdotte a partire da OS X 10.7/Lion c’è di sicuro Versions (in italiano Versioni, ma permettetemi di usare l’originale inglese).

Erano moltissimi anni che mancava un sistema di gestione delle diverse versioni dei file (quasi) integrato con il sistema operativo (il motivo del quasi lo si trova più sotto).

Da quanto ricordo, uno dei primi sistemi operativi che implementava un sistema rudimentale di gestione delle versioni dei file è stato il VMS della Digital Equipment Corporation (DEC) che negli anni ‘80 dominava, con i minicomputer della serie VAX, nei dipartimenti universitari scientifici di tutto il mondo.

Ad ogni salvataggio di un file, il sistema operativo creava una nuova versione, distinta dalle altre da un un numero progressivo. Era anche possibile cancellare le versioni salvate, singolarmente o a gruppi. Un po’ rozzo ma, per i tempi, efficace.

Chi ha usato il VAX in quegli anni ricorda ancora di essere stato istruito (o meglio, catechizzato!) a non usare mai, mai, mai il comando del _._;* con il quale si cancellavano tutte le versioni di tutti i file.

Io, purtroppo, l’ho fatto! Una sola volta, ma l’ho fatto.

L’errore mi ha obbligato a riscrivere da zero un programma quasi completo, ma da allora sono diventato un maniaco dei backup.

Torniamo ad oggi e a Versions. A che serve Versions? Non basta Time Machine?

In realtà sono due strumenti profondamente diversi. Time Machine effettua un backup di tutti i file modificati nell’ultima ora, mentre Versions salva automaticamente solo il file su cui si sta lavorando: ogni 5 minuti, ogni volta che si preme cmd + S, e anche ogni volta che si apre o si chiude il file.

Questo permette, in pratica, di recuperare le modifiche fatte ad un file nel corso del tempo: si può sia scegliere di ripristinare integralmente una versione precedente del file (esattamente come Time Machine) o di estrarre solo alcune parti dalle vecchie versioni del file per incollarle in quella corrente.

Appena si comincia a provarlo ci si chiede come si faceva… prima.

Facciamo un esempio pratico.

Ho appena salvato questo documento, che sto scrivendo in Markdown (ne riparleremo di sicuro). Rileggendolo, mi accorgo che alcune modifiche recenti non mi piacciono e decido di ripristinare le parti di testo corrispondenti scritte il giorno prima.

Nessun problema: sposto solo il mouse alla destra del nome del file, in cima alla finestra dell’applicazione. Nelle applicazioni supportate compare un triangolino grigio. Cliccandolo vengono mostrate alcune opzioni che permettono di bloccare o duplicare il file, di ripristinare l’ultima versione salvata o, infine, di scorrere tutte le versioni salvate.

Scelgo quest’ultima opzione. Lo schermo si trasforma in quello, sempre affascinante, di Time Machine, ma questa volta il file su cui sto lavorando viene affiancato da una sequenza di finestre contenenti le versioni precedenti del file, che posso scorrere esattamente come in Time Machine.

Torno quindi indietro nel tempo e scelgo una versione precedente del file, sostituendola al posto di quella corrente. Seleziono la porzione di testo da ripristinare, la copio e uso di nuovo Versions per tornare alla versione più recente del documento, incollandovi il testo appena copiato. Piuttosto complicato da descrivere, ma efficace.

Ma gli sviluppatori Apple sono grandiosi: posso anche copiare il testo da ripristinare dalla versione precedente del documento direttamente nell’interfaccia di Versions, tornare alla versione più recente del documento su cui sto lavorando (senza ripristinare nulla) ed incollare il testo appena copiato dal vecchio file.

Fantastico!

Versions però non è integrato con il sistema operativo ma funziona solo nelle applicazioni scritte appositamente per supportarlo. E in fondo non ha molto senso implementare questa funzionalità in tutte le applicazioni. Ma per quelle in cui serve veramente, è una funzione utilissima. Provare per credere.

Maggiori approfondimenti su Versions si possono trovare nella già mitica recensione di Lion di John Siracusa su ArsTechnica e anche nell’interessantissimo post Mac OS X Lion file versions pubblicato sul blog TeX, Tech and Theory. Fra parentesi, il blog è gestito da un economista: un teorico, un italiano che lavora negli USA, e un utente di LaTeX. Una combinazione straordinaria.