Google Documents on Melabit

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. ↩︎

SubEthaEdit, scrivere insieme in tempo reale

Mon, 30 Oct 2023 06:00:00 +0000

– Fonte: Annie Spratt su Unsplash.

SubEthaEdit è in giro da un bel po’ di tempo, se la memoria non mi inganna più o meno dai tempi di Tiger.¹ Quando uscì fece scalpore, perché per la prima volta dava la possibilità a più utenti di lavorare contemporaneamente allo stesso documento, con il limite che tutti i Mac dovevano essere connessi alla stessa rete locale.

Oggi, fra Office 365, Teams, Google Documents (e naturalmente Overleaf), scrivere un testo in collaborazione fra vari utenti sparsi nel mondo sembra una cosa scontata,² ma 20 anni fa era una funzione mai vista prima su un computer personale.

Infatti, secondo uno degli autori, la scrittura collaborativa di un testo è stata inventata intorno alla metà degli anni ‘90 presso il solito Xerox PARC, ma fino a SubEthaEdit nessuno aveva pensato di applicarla ad un prodotto commerciale.

L’editor

SubEthaEdit (SEE per gli amici) è un editor di testo puro, proprio come TextMate, BBEdit, Sublime Text o il defunto Atom, ormai soppiantato da Visual Studio Code.³

SEE ha tutte le funzioni di base di un editor moderno, riconosce la sintassi dei principali linguaggi di programmazione (tranne R, accidenti!), così come di Markdown e di LaTeX, e può essere configurato in modo abbastanza dettagliato, per adattarsi al meglio ai gusti personali.

A questo proposito, io preferisco visualizzare i caratteri nascosti (Show: Invisible Characters) e sostituire i tab con gli spazi (una abitudine da programmatore). Entrambe le modifiche si fanno nel pannelo Editing delle Preferenze di SEE. Mi piace anche ingrandire leggermente il font di default a 12 punti e aumentare la spaziatura fra le linee al 110% per rendere il testo più leggibile e più consistente con gli altri editor che uso (pannello Styles).

Rispetto ai mostri sacri citati prima, SEE manca di parecchie funzioni, fra cui alcune che ormai fanno parte del normale corredo di un editor moderno, come la possibilità di commentare rapidamente un blocco di codice, di aggiungere delle parentesi aperte e chiuse oppure dei simboli attorno ad un blocco di testo selezionato,⁴ oppure di effettuare una selezione per colonne, utile in particolare quando si lavora con le tabelle.⁵

SEE non ha nemmeno il completamento automatico del codice ma insomma, questa è una funzione supportata solo dagli editor più avanzati, quindi è un peccato veniale. Anche gli stili, i temi, o come volete chiamarli, sono pochi, ma almeno per me, che uso quasi sempre lo stile di default, questo è un non-problema.

Peccato anche che non metta in evidenza automaticamente gli errori ortografici, ma che io sappia questo lo fa nativamente solo BBEdit ed è uno dei motivi per usarlo per scrivere dei testi in Markdowno o LaTeX.

Molto utile, invece, la possibilità di avere visualizzazioni diverse dello stesso documento sia nella stessa finestra che in finestre separate, così come il conteggio in tempo reale del numero di caratteri, parole o linee di cui è composto un documento, una funzione che mi avrebbe aiutato moltissimo qualche mese fa.

Per averlo, bisogna attivare dal menu View la visualizzazione della barra di stato superiore e inferiore (che servirà fra poco), che riportano una serie di informazioni utili sul documento aperto fra cui, a destra della barra di stato superiore, proprio il numero di caratteri, parole o linee del documento. Cliccando sul numero si può cambiare ciclicamente il tipo di conteggio riportato.

Scrittura collaborativa

La caratteristica più interessante di SSE è il supporto nativo per la scrittura collaborativa, che permette a due o più utenti collegati alla stessa rete locale di lavorare contemporaneamente allo stesso documento.

Prima di condividere un documento bisogna aprire il pannello Collaboration delle Preferenze di SEE e assicurarsi di aver attivato l’opzione relativa (Enable Collaboration) e di non essere invisibili agli altri utenti della rete (Invisible to others on the Network).

È sufficiente ora cliccare sull’icona in basso a destra nella barra di stato (quella che assomiglia al simbolo del Wi-Fi ruotato) per rendere il documento disponibile agli altri utenti della rete. Questa circostanza viene indicata in modo evidente nella stessa barra di stato, dove compare una grossa icona colorata con le iniziali dell’utente che ha iniziato la condivisione. Per differenziare meglio i vari utenti è possibile personalizzare l’icona ed il colore associato a ciascun utente nel solito pannello Collaboration delle Preferenze, come si può vedere nelle due immagini qui sotto.

A questo punto, se un altro utente esegue SubEthaEdit su un Mac collegato alla stessa rete locale, potrà accedere non solo alla lista dei suoi documenti locali più recenti, ma anche a quelli condivisi su cui può collaborare.

Per farlo, dovrà cliccare sul nome del documento condiviso e aspettare di essere autorizzato a modificare o eventualmente soltanto a leggere il documento in questione, potendo così iniziare la sua attività di scrittura a quattro (o più) mani.

Anche la barra di stato di SEE cambierà, mostrando le icone dei due (o più) utenti che stanno lavorando in contemporanea, con i colori associati a ciascun utente.

Questi colori sono fondamentali, perché permettono di valutare a colpo d’occhio chi ha effettuato ciascuna modifica. È anche possibile lavorare sulla stessa porzione di testo, correggendo e integrando ciò che ha scritto l’altro.

SEE non ha problemi nemmeno quando si prova a scrivere in contemporanea esattamente nello stesso punto, ma si limita ad inserire entrambi i caratteri, differenziandoli in base all’utente. Per quanto ci abbia provato non sono mai riuscito a mandarlo in crash con giochetti di questo tipo.

In alternativa alla trafila di condivisione descritta prima, è anche possibile invitare esplicitamente a collaborare un altro utente che ha già aperto SEE sul suo Mac.

Inoltre, cliccando con il tasto destro del mouse sull’icona simil-Wi-Fi in basso a destra, è possibile definire a priori se il documento su cui si sta lavorando è modificabile dagli altri utenti, solo leggibile oppure è bloccato. In quest’ultimo caso non viene condiviso in rete e potrà essere modificato solo in locale.

Insomma, le possibilità non mancano, ed anche se ormai dovremmo essere abituati a lavorare in rete sullo stesso file, qui tutto si svolge in modo molto fluido e intuitivo. Peccato solo per il limite della rete locale e per il fatto che SEE giri solo su macOS, due fattori che rendono il programma utile solo ad un numero piuttosto ristretto di utenti.

Conclusioni

SubEthaEdit è un discreto editor di testo per macOS, che diventa insostituibile quando si ha bisogno di utilizzare le sue funzioni di scrittura collaborativa. Devo ammettere, però, che finora ho sempre preferito i suoi fratelli maggiori, in particolare TextMate e BBEdit.

Ma ultimammente ho scoperto una funzione piccola-piccola e molto specialistica di questo programma che, quando serve, si dimostra davvero insostituibile. Però di questo ne parlerò la prossima volta.

Mi sono sbagliato di poco, secondo Wikipedia la prima versione di SubEthaEdit risale ai tempi di Panther (Mac OS X 10.3), il sistema operativo immediatamente precedente a Tiger (10.4). ↩︎
Ma conosco fin troppi utenti rimasti ancorati allo scambio via email di una sequenza interminabile di documento_v1.docx,documento_v2.docx, documento_v2b.docx, documento_v2b_ultima_versione.docx, seguiti inevitabilmente da documento_v2b_straultimissima_versione.docx e da documento_v2b_sara_la_volta_buona.docx ↩︎
Chi rimpiange Atom può provare Pulsar, un fork open source di Atom che aspira ad essere una versione migliorata e più moderna del genitore, ma che su macOS ha sembra avere ancora problemi di prestazioni. ↩︎
Con gli altri editor quando scrivo in Markdown sono abituato a selezionare un blocco di testo e a scrivere _ o ** per circondarlo con i tag che lo fanno visualizzare rispettivamente in italico o in grassetto. Con SEE non funziona e questa mancanza mi ha fatto penare durante la scrittura di questo articolo. ↩︎
Ho proposto di aggiungere queste funzioni sul repository GitHub del programma ma finora non ho ricevuto alcun feedback dagli sviluppatori. Vedo anche che la maggior parte delle richieste rimangono inascoltate ed è probabile che la mia farà la stessa fine. ↩︎