Sistemi per la preparazione dei documenti: compilati, WYSIWYG, e duali

Vorrei dire che uno dei motivi del perché mi trovo bene con TeX è proprio il fatto che l’ambiente di lavoro è un editor di testo puro.

Io questo non sono mai riuscito a farlo funzionare fino in fondo. Ti faccio un esempio con una formula scritta per mie note personali (forse contiene qualche errore, ma l’esempio è valido):

`
{

\def \l {\mathrm{l}}
\def \r {\mathrm{r}}
\def \Bl {\mathrm{Bl}}
\def \Br {\mathrm{Br}}
\def \B {\mathrm{B}}
\def \n2om {n_{2\omega}}
\begin{equation}\label{eq:interface_conditions}
\begin{aligned}
F_{1\l} &= F_{2\r} + F_{2\l} \exp (i\,k_2 L) + F_{\Br} + F_{\Bl} \exp(i\,k_\B L) \\
%
F_{1\r} &= -\n2om \, F_{2\r} + \n2om \, F_{2\l} \exp (i\,k_2 L) – \n2om \, F_{\Br} +
\n2om \, F_{\Bl} \exp(i\,k_\B L)\\
%
F_{3\r} &= F_{2\r} \exp (i\,k_2 L) + F_{2\l} + F_{\Br} \exp(i\,k_\B L) + F_{\Bl} \\
%
-F_{3\l} &= \n2om \, F_{2\r} \exp (i\,k_2 L) + \n2om \, F_{2\l} –
\n2om \, F_{\Br} \exp(i\,k_\B L) + \n2om \, F_{\Bl}
\end{aligned}
\end{equation}

}

`

La ho scritta con cura: ho messo dei tab, definito a parte alcune notazioni per alleggerire la scrittura, fatto attenzione agli spazi. Non riesco a leggerla con la stessa scioltezza con cui la leggo quando è composta tipograficamente, e questo mi rende più difficile rivedere testi che ho scritto. Devo avere il testo compilato di fronte, leggerla, se non la ho già trovata nel codice TeX fare doppio click per andare al punto giusto con SyncTeX, e infine posso modificarla. Per questo mi sono rivolto a sistemi che permettono l’editing WYSIWYG di documenti strutturati (mi servono sia “editing” che “strutturati”).

Oggi si potrebbe implementare un compositore che elabora l’intero documento.

Credo che il trucco chiave per l’editing WYSIWYG sia la compilazione incrementale. Forse la scala dei tempi “chiave” è attorno ai 100 ms (cioè il tempo fra due pressioni di tasti)—oggi TeXmacs lo fa.

\def \n2om {n_{2\omega}}

non funziona perché è violata una normal di basse di TeX e LaTeX: le macro da definre con \def e con gli alri comandi di definizione nativi di TeX e definiti con LaTeX, devono essere formata con una stringa di sole lettere;

Non avevo pensato a questo e, se lo ho mai saputo, lo avevo anche dimenticato. Detto ciò, non me ne sono accorto perché … TeX compila il codice. Ci ho messo un po’ a capire cosa succede e ci sono arrivato solo grazie ad una ricerca su Google che mi ha portato sulla pagina https://texfaq.org/FAQ-linmacnames (punto 4): la sorta di “pattern matching” che TeX impiega quando esegue una macro si applica anche quando non ci sono argomenti.

Comunque hai ragione in generale, uso TeX per “prove ed errori”, con un quadro d’insieme parziale su come funziona il software; per esempio ho in mente in maniera parziale la famosa distinzione fra occhi bocca e stomaco, so dell’esistenza dei modi orizzontale e verticale e la loro definizione di massima ma non so identificare quando vengono attivati.

Detto questo, non mi sono spiegato bene, e insisto con le mie argomentazioni.
Con “non sono mai riuscito a farlo funzionare fino in fondo” intendo “Non sono mai riuscito a fare funzionare fino in fondo per me l’editing di un documento scritto con markup in formato solo testo”.

In particolare, non riesco a leggere con la scioltezza che vorrei la matematica, appena le formule superano una modesta complessità. Riprendendo l’esempio

`
\begin{aligned}
F_{1\l} &= F_{2\r} + F_{2\l} \exp (i\,k_2 L) + F_{\Br} + F_{\Bl} \exp(i\,k_\B L) \\
%
F_{1\r} &= -\nIIom \, F_{2\r} + \nIIom\, F_{2\l} \exp (i\,k_2 L) – \nIIom\, F_{\Br} +
\nIIom\, F_{\Bl} \exp(i\,k_\B L)\\
%
F_{3\r} &= F_{2\r} \exp (i\,k_2 L) + F_{2\l} + F_{\Br} \exp(i\,k_\B L) + F_{\Bl} \\
%
-F_{3\l} &= \nIIom \, F_{2\r} \exp (i\,k_2 L) + \nIIom\, F_{2\l} –
\nIIom\, F_{\Br} \exp(i\,k_\B L) + \nIIom\, F_{\Bl}
\end{aligned}
`

devo compilarlo per leggerlo con scioltezza. In “formato codice”, sono costretto a leggere ogni sottoespressione, quindi non ho la visione di insieme.

La tesi del mio post è che l’editing sotto i due formati “codice” e “compilato” è superiore all’editing sotto uno solo dei due formati e che l’assenza di un software che lo faccia per TeX non è dovuta a limitazioni tecniche ma a “limitazioni sociali”. Credo di avere delle argomentazioni passabili a sostegno della tesi.

Per l’assenza di limitazioni tecniche.

Un’argomentazione è che un software esiste, è BaKoMa TeX, e non è mai stato molto diffuso perché a pagamento secondo me. L’autore purtroppo è deceduto e adesso non si sa cosa succederà al software, è possibile che si perda. Lo ho provato qualche anno fa e ricordo che funzionava, ma lo ho testato poco (c’era la versione di prova per tempo limitato, e poi non lo ho comprato) .

A parte il software commerciale (che dimostra la parte “tecnica” della tesi), software disponibili pubblicamente che realizzano questo parzialmente per TeX sono stati scritti alla fine degli anni ’80. Vedere VORTEX: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1988/5485.html , tesi di dottorato di Pehong Chen, c’è un link da cui è scaricabile. Ho letto solo parti del documento e mi pare che l’editabilità del testo nella finestra “compilato” non sia completa in questo sistema, è possibile che si possa solo fare copia-incolla e qualche cambio di formattazione. Ho trovato anche il codice: https://github.com/tex-other/vortex (credo ci siano le parti interessanti di compilazione incrementale per esempio).

Per l’esistenza di limitazioni sociali, credo ci siano due fattori in gioco. Uno è la scarsità di incentivi: scrivere questo codice richiede un paio di anni di lavoro concentrato, e non si viene né pagati, né si può usare facilmente come credenziale accademica (magari mi faccio venire la voglia e controllo se nei concorsi per l’università italiana viene dato peso all’aver scritto codice scientifico). L’altra è che l’esistenza di tale software non viene vista come “cosa desiderabile”: e invece dovrebbe secondo me, per questo scrivo.

Poi esistono anche software diversi da TeX che lo fanno, ma in questo caso cambia la sintassi del documento (la discussione “sintassi” la so affrontare in maniera solo parziale, mi interessa comunque ma è eventualmente per un altro post).

OldClaudio” post=120621

Facci sapere, per favore, quando avrai conoscenza certa che TeXmacs sia in grado di lavora anche con Mac OS-11.4 e successivi

Mi sono informato ulteriormente. C’è la possibilità che l’ostacolo sia il dovere fare un passo in più rispetto al semplice doppio click

Quoto dalla risposta che ho ottenuto:

”
Poiché TeXmacs non è un’applicazione “firmata” da un developer riconosciuto da Apple, allora non la può aprire semplicemente cliccando ma la deve copiare esplicitamente nelle Applicazioni oppure aprirla con il menu che si ottiene con Cltr+Click e selezionare “Aprire” o “Eseguire” non so come sia in italiano.

Ecco le istruzioni:

https://support.apple.com/en-gb/guide/mac-help/mh40616/mac
”

Fammi sapere se così funziona o se c’è qualche altro ostacolo.

Apro un file LaTeX, tanto per vedere che cosa succede; Tutti i comandi che il file contiene sono riprodotti in rosso (senza il backslash), intercalati al testo. Ci sono anche i commenti in grigio; il testo è formattato né più né meno come con LyX, non viene aperta la finestra della trasformazione, ma suppongo che sia necessario cliccare qualcosa; esplorerò la cosa con calma.

L’esportazione verso LaTeX funziona molto meglio dell’importazione (i comandi in rosso sono quelli che non è riuscito ad importare). Il modo efficace di usare TeXmacs come editor LaTeX è scrivere in TeXmacs e poi esportare. Questo in linea di massima è vero anche per LyX, ma non ho fatto un confronto delle capacità di importazione dei due programmi; da un lungo discorso fatto su una delle mailing list di TeXmacs ho tratto (senza capirlo a fondo) il concetto che la grammatica di LaTeX è tale che non può esistere un filtro di importazione completo, ma non ho un concetto intuitivo di quali siano le limitazioni rispetto all’insieme di pacchetti LaTeX “comunemente usati” (insieme definibile in maniera approssimativa).
L’esportazione verso LaTeX è estremamente ragionevole, ma esistono dei costrutti TeXmacs non esportabili, che quindi vanno evitati quando si scrive con l’idea di esportare verso LaTeX. La collaborazione con altre persone che usano LaTeX scrivendo il codice è limitata dalle capacità di importazione (interessante https://www.texmacs.org/joris/latexconv/latexconv.pdf, ma non ne conosco lo status attuale).

Detto ciò, i software a me noti che permettono l’editing “in parallelo” sia del codice sia del testo compilato per TeX sono

– BaKoMa TeX, di cui come ho scritto non si conosce pubblicamente lo status (vedere http://www.bakoma-tex.com/menu/talks.php)
– Compositor: https://compositorapp.com/ , mai testato e del quale non conosco eventuali limiti (l’editing del sorgente secondo la pagina web è fatto con una sorta di pop-up, vedere sezione “Source Editing When You Need It”). Ma funziona per il Mac, quindi forse tu lo puoi testare.

TeXmacs è un software originale, che funziona per conto proprio, e che fra le sue funzioni ha anche quella di esportare verso LaTeX. Con LaTeX ci sono differenze sintattiche di fondo (credo sia il tipo di automa che può interpretare la grammatica, ma per questo non sono in grado di dare informazioni sufficienti), le macro sono impostate in maniera completamente diversa (con un linguaggio funzionale, che credo sia proprio diverso rispetto alle macro del TeX) e anche la filosofia è diversa (l’accesso al sorgente viene considerato come un supporto al WYSIWYG); per la filosofia vedere questo articolo di M. Gubinelli su maddmaths: http://maddmaths.simai.eu/divulgazione/focus/texmacs/ (è in forte polemica, ma argomentata, con TeX). Da quello che ho capito nelle discussioni con gli autori, la grammatica diversa rende il testo completamente strutturato (LaTeX per costruzione non può esserlo).

Come ultima osservazione sulla grammatica, non so se le diverse grammatiche influenzino la capacità di organizzare il testo in regioni arbitrarie di una pagina (per TeX, vedere Hoenig, A. (1987). TeX does windows-conclusion. TUGboat, 8(2), 211–215. …io ho solo letto l’introduzione e guardato le figure, non mi sogno di interpretare il codice … e “Comment on “TeX does windows” a pagina 216 dello stesso numero di TUGboat)

Rispondo solo a due punti che mi premono di più

Quello che mi sorprende dei riferimenti internet e articoli che citi evidentemente anche dagli scambi fra appassionati di TeXmacs, e che sono molto datati.

Sono i riferimenti significativi (secondo me) che ho trovato sul tema (escludendo il lavoro su TeXmacs e il software BaKoMa). Ho anche controllato su Google Scholar le citazioni ad un lavoro di P. Chen e M.A. Harrison: Chen, P., & Harrison, M. A. (1988). Multiple representation document development. Computer, 21(1), 15–31. https://doi.org/10.1109/2.222114 — mi pare sia lo stesso tema della tesi di dottorato, ne esiste una copia su ResearchGate messa a disposizione da Harrison; le citazioni sono tutte entro il 2000 (approssimativamente), e non mi sono parse (a giudicare dai titoli) contenere dimostrazioni di software più avanzati rispetto al VorTeX.

La mia impressione è che il tema “editor duali” e anche il tema più generale “rappresentazione multipla” sia stato lasciato da parte—c’era un fermento culturale (così uso l’espressione dei miei libri di testo delle scuole) che non vedo nei decenni successivi.

Detto questo, ho riprovato BaKoMa TeX, scaricando la versione di prova (il sito non è più sotto il controllo dell’autore, che è deceduto, ma ho dato per buono che il software sia nelle condizioni in cui l’autore lo ha lasciato: in altre parole forse a scaricare ed installare c’è un po’ di rischio, ma la curiosità ha vinto).

Lo scopo di TeXmacs, di LyX, in parte di BaKoMa, è quello di rendere più facile l’input a scapito dele performance estetiche

Nel mio test con BaKoMa (di un paio di ore) mi pare che le prestazioni estetiche siano le stesse di quelle del “TeX batch”—gli algoritmi che l’autore ha implementato nel software devono essere sottili, perché posso scrivere sia nella rappresentazione visuale che in quella sorgente e tutto sembra stare in ordine, sincronizzato e per quello che vedo rappresentato come risulterà nell’output della compilazione. Il cursore si muove in maniera sincronizzata nelle due rappresentazioni (bisogna imparare un piccolo dettaglio: quando un ambiente è seguito da un altro ambiente, se uno muove il cursore nella rappresentazione “visuale” il cursore non può essere messo fra i due ambienti). Ho usato un file di un paio di pagine, da quello che mi ricordo di aver letto BaKoMa funziona bene anche con file più lunghi (deve essere la compilazione incrementale).
Ho provato una macro semplice e gli argomenti possono essere editati nella rappresentazione visuale (idem per un ambiente di mdframed). Mi aspetto che questo avvenga “sub conditione”, quando è possibile fare corrispondere la posizione del cursore nell’output della macro alla posizione del cursore nell’argomento.

Forse un modo per salvare il software è che se ne interessi una grande organizzazione (magari il TUG) che sia in grado di trattarne l’acquisto con gli attuali possessori dei diritti e raccogliere i fondi necessari.

Detto ciò le mie brevi prove mi hanno mostrato che non è ovvio, come credevo, che una rappresentazione duale sia più comoda della rappresentazione singola, ho percepito come fastidioso il muovermi fra le due rappresentazioni—cosa che ho dovuto fare alcune volte per sistemare il cursore fra due ambienti, un paio di volte per “convincere BaKoMa” a farmi mettere un gruppo in apice al post di una lettera sola (può essere che non abbia capito come fare) e per aggiungere un punto ad una lista quando il punto corrente finiva con un’equazione. Ho avvertito una forte inclinazione ad usare solo una o solo l’altra rappresentazione.

Un punto da considerare è che ho uno schermo piccolo, e ho messo la finestra del codice in basso a sinistra. Forse con uno schermo più grande avrei potuto mettere le due rappresentazioni fianco a fianco e sarebbe stato più comodo.

Sono stato superficiale a dire che “così va bene”, credo che la cosa saggia sia fare più esperienza. Per la cronaca, l’impostazione di TeXmacs è scrivere solo nella finestra WYSIWYG (che viene rappresentata di default), e passare saltuariamente alla rappresentazione sorgente.

lorenzo.pantieri” post=120650

La prospettiva di poter mettere mano sia sul sorgente (con il documento finito che cambia di conseguenza) sia sul documento finito (con il sorgente che cambia di conseguenza: ma come?) .

Questo lo so 🙂

In BaKoMa c’è un set di costrutti che possono essere inseriti attraverso menu o scorciatoie da tastiera. Tutti gli altri costrutti devono essere inseriti a partire dal codice sorgente; la facilità d’uso non è però data dall’inserimento della macro, ma dall’inserimento degli argomenti, i quali possono essere inseriti nell’interfaccia WYSIWYG. Lo ho già scritto in un messaggio precedente ma espando un poco l’esempio con l’ambiente di mdframed; nel mio test ho modificato leggermente un esempio della guida di mdframed, adesso lo propongo qui così com’è nella guida perché non ho il mio file sottomano.

Supponiamo di avere nel preambolo

`

\newmdtheoremenv [%
outerlinewidth = 2 ,%
roundcorner = 10pt ,%
leftmargin = 40 ,%
rightmargin = 40 ,%
backgroundcolor = yellow!40 ,%
outerlinecolor = blue!70!black ,%
innertopmargin = \topskip ,%
splittopskip = \topskip ,%
ntheorem = true ,%
] {theorem}{Theorem} [section]

`

e nel file

`

\begin {theorem} [Pythagorean theorem]
. . .
\end{theorem}

`

Nella parte WYSIWYG compare la cornice nella sua forma tipografica nella quale si può inserire il testo (argomento dell’ambiente). Ho fatto solo due prove (questo ambiente e una mia macro con alcuni argomenti), immagino che l’inserimento WYSIWYG sia possibile quando c’è una corrispondenza semplice fra la posizione del cursore nella rappresentazione visiva e la posizione del cursore nel codice.

Per quanto riguarda le formule (cosa essenziale, perché il codice che genera le formule è più difficile da leggere delle formule stesse), c’è un insieme di scorciatoie da tastiera per inserire le parti di formula (frazioni, radici, apici, pedici … non ho il programma sott’occhio e non mi ricordo quanto è completa). Quest’ultima parte la fa anche LyX. La differenza importante è che BaKoMa, al contrario di LyX, non ha bisogno di una traduzione manuale di ogni nuovo costrutto per fare l’editing WYSIWYG dei suoi argomenti (come detto sopra, mi aspetto che l’editing visuale degli argomenti sia sottoposto ad una condizione sul movimento del cursore).