antonio.macrì

Interessanti, davvero. TeXworks, dopo GNU Emacs, è l’altro mio editor preferito.

Ad maiora!
Orlando

Grazie del’interesse, mi fa piacere che qualcuno li abbia apprezzati!

EDIT: Che linguaggio si usa per scrivere questi script? Dove poter reperire un breve tutorial?

Il codice è scritto in un linguaggio che sembra venga chiamato TwScript. A volte viene anche chiamato (un po’ impropriamente, secondo me) QtScript. È una implementazione dello standard ECMAScript, lo stesso che viene usato nei vari browser col nome di Javascript. In parole povere, lo standard ECMAScript definisce le caratteristiche di base del linguaggio, come i tipi di dato, gli operatori, la sintassi in generale. Ciascuna implementazione aggiunge degli oggetti specifici. Così ci sono le implementazioni fornite dai browser che espongono degli oggetti (window, document, location, eccetera) per lavorare con le pagine web. Quella di TeXworks invece fornisce l’oggetto TW, tramite il quale si accede ad alcune funzionalità di TeXworks stesso: al documento corrente, alla selezione, e così via.

Il motore che esegue lo script (perché riconosce il linguaggio ECMAScript) è in realtà fornito dalle Qt: QtScript è propriamente il modulo Qt che si occupa di ciò. TeXworks gli dice solamente quali altri oggetti esporre (TW).

A questa pagina trovi delle informazioni molto generali. Un buon punto di partenza è la guida TexWorksQtScripting, per vedere gli oggetti forniti da TeXworks e che dà anche alcuni consigli generali. Per conoscere più a fondo l’ECMAScript, basta una qualsiasi guida Javascript. Se vuoi creare anche delle interfacce grafiche, allora anziché scrivere direttamente l’XML ti conviene scaricare il Qt SDK e in particolare il Qt Creator, che serve proprio a disegnare le finestre di dialogo. Il resto è tutto smanettare e leggere il manuale (“Qt Reference Documentation”, visualizzabile dallo stesso Qt Creator). Come dicevo nell’altro post, purtroppo non tutti i metodi sono accessibili da script, ma solo gli “slots”, e ancora maggiori sono le limitazioni nella creazione di nuovi oggetti da script, ma si riesce comunque a fare cose interessanti.

PS: ho fatto un paio di modifiche al codice, una sull’interfaccia (niente di importante), l’altra era una svista che faceva eseguire dei cicli inutili. Conviene che li riscarichi.

Ciao,
Antonio

Credo di aver finalmente risolto:
`\newlength{\heightoframebox}
\newlength{\depthoframebox}

% print and save position: visualizza (a PDF) il suo argomento e ne salva la posizione su file
\newcommand\psp[1] {%
\immediate\write\SymbolExport{page = \number\thepage}%
\settodepth{\depthoframebox}{\framebox{#1}}\settoheight{\heightoframebox}{\framebox{#1}}%
\zsavepos{b\thepage\detokenize{\string#1}}\framebox{#1}\zsavepos{e\thepage\detokenize{\string#1}}%
\immediate\write\SymbolExport{left = \zposx{b\thepage\string#1}}%
\immediate\write\SymbolExport{right = \zposx{e\thepage\string#1}}%
\immediate\write\SymbolExport{middle = \zposy{b\thepage\string#1}}%
\immediate\write\SymbolExport{height = \the\heightoframebox}%
\immediate\write\SymbolExport{depth = \the\depthoframebox}%
}`
che produce per ogni simbolo:
`page = 1
left = 10962208
right = 11735533
middle = 46493363
height = 10.34444pt
depth = 3.4pt
command = \textasciicircum
`

left e right sono le coordinate orizzontali del bordo sinistro e destro del framebox. Le coordinate verticali del bordo inferiore e superiore (che TeX misura dal basso verso l’alto) sono invece rispettivamente middle-(depth*65536) e middle+(height*65536).

Forse il codice è un po’ ridondante (dovre provare a smanettare direttamente con \ht e \dp), ma almeno funziona. Mi rimane da capire bene cosa rappresenta middle. Approfondirò…

Ciao

Grazie della risposta, innanzitutto. Non vorrei andare off-topic nel risponderti, ma provo a farlo.

Ciao,
scrivere un editor per LaTeX che non sia grossomodo un ‘esercitazione’ è assai difficile perché esistono editor già molto evoluti come TeXWorks e Kile.
Il progetto potrebbe essere interessante solo nel caso che si implementino idee veramente nuove che facilitino la stesura del sorgente

Lo so che non è facile sviluppare un editor serio, ma tutto è partito come curiosità e la curiosità è poi dilagata, facendo, col tempo, venire in mente nuove idee. Non dico che siano tutte idee eccezionali o rivoluzionarie. A volte accade di rendersi conto che qualcosa che ti fai tu risponde meglio alle tue esigenze rispetto a ciò che ti viene offerto. È anche una questione di gusti. Esistono editor abbastanza diversi tra loro, è vero, ognuno con una sua anima. Ma proprio per questo non è detto che io (ma userei un pronome indefinito) ne riesca a trovare uno che più si confà alle mie richieste.

Sempre che tu non voglia esclusivamente divertirti, ti consiglierei di pensare a contribuire allo sviluppo di TeXWorks per esempio, piuttosto che correre da solo.

Almeno, questa è la mia opinione: tentare di scrivere un nuovo editor solo se si hanno idee innovative da proporre altrimenti conviene dare una mano con TeXWorks.

TeXworks in effetti è l’editor che preferisco, semplice, essenziale, con anteprima. Al contrario di Kile, che trovo barocco. Capisco che puoi pensare che sia una perdita di energie, ma è anche questo che muove il software libero (mi è capitato di dare una letta qualche volta al tuo blog e mi è parso di capire che ne sei un sostenitore): prendere ciò che c’è già e modificarlo per riadattarlo alle proprie esigenze.

…come per esempio un sistema di tips che suggerisca la sintassi corretta di un comando che si inizia a digitare appartenente ad un pacchetto caricato nel preambolo od alla classe alla maniera di un IDE per sviluppatori di un dato linguaggio.

Mi interesserebbe parecchio un argomento legato, ovvero (spererei proprio che esista già, ma non ne ho conoscenza) uno standard (un formato) per commentare i comandi alla loro definizione che ne precisino la sintassi (numero di argomenti, cosa rappresentano, eccetera). È una cosa usuale per i linguaggi di programmazione tradizionali, mi piacerebbe molto vederla in TeX/LaTeX. Approfitto per chiedere: qualcuno conosce uno formato di questo tipo? Un editor se ne potrebbe avvantaggiare moltissimo.

La lista di simboli è già presente per esempio in Kile: si clicca un simbolo e compare ne viene inserito il codice nel sorgente, il quale verrà poi processato in compilazione.
Per il resto ti confesso di non aver capito a cosa ti possa servire il pdf contenente il simbolo nella posizione fissa che desideri. Non riesco ad immaginarne un uso nel caso di un editor.

Dovresti spiegare meglio le basi della tua strategia.

Se riesco a individuare la posizione del glifo di un simbolo, la estraggo assieme al nome del comando che viene usato per inserirlo e scrivo tutto nel file exports.txt. In seguito, converto ogni pagina PDF in immagine e, usando la posizione trovata prima, ne ritaglio tutti i simboli salvandoli (come immagine) da qualche parte. A questo punto, per ogni simbolo ho l’immagine e il nome del comando: rielaboro tutti i simboli, li catalogo e li inserisco in un database. L’editor dovrebbe contenere una sorta di tabella con questi simboli (riordinabile secondo alcuni criteri: per pacchetto, per tipologia…): tu ci clicchi e vengono inseriti.

L’idea è che mi piacerebbe estrarre automaticamente questi simboli dalla Comprehensive LaTeX Symbol List, proprio perché la consulto molto spesso e vorrei che l’editor che uso ne riproducesse in qualche modo l’organizzazione. Ciò consentirebbe, tra l’altro, di inserire (eventualmente) in modo automatico una \usepackage con il nome del pacchetto che contiene il simbolo (informazione presente nella CLSL).

In definitiva, lo sviluppo di nuove idee rappresenta un processo entusiasmante, ma reinvetare la ruota ogni volta è certamente poco produttivo.

Tieni conto che possono essere sviluppati delle nuove feature per TeXWorks per mezzo di un linguaggio di scriting interno dunque iniziare a contribuire al progetto non è affatto lungo.
Per esempio, io avrei bisogno di un comando che in automatico riorganizzi con le giuste spaziature il contenuto del sorgente LaTeX di un ambiente tabular, allineando il testo delle celle ai caratteri &, per migliorarne l’editing manuale.
Oppure mi servirebbe un comodo comando per inserire ad inizio sorgente i tag per TeXWorks di definizione della codifica ecc.
Ecco dunque la conclusione: inventare potenti tool per editor LaTeX è fantastico, ma con plug-in per TeXWorks diventa anche utile con poco sforzo.
Anzi, rendere possibile la tecnologia a plug-in per TeXWorks è già di per se una buona avventura.
R.

Tra le idee c’è anche questa che dici tu sulle tabelle (ho già buttato giù del codice che pare funzionare): è una cosa semplice da fare ma che pure non ho visto in nessun editor (magari mi è sfuggita). Apro una parentesi: TeXworks non supporta i progetti con più file. Anche qui trovo che la scelta che l’utente deve fare del file TeX principale sia una cosa evitabile: (al di là di possibili sofisticazioni) basterebbe che l’editor si crei un albero dei file aperti (chi include chi): il file principale non può che essere la radice.

Voglio essere più chiaro, ragionando su due filoni. Da un lato, tutte le scelte progettuali che si fanno nello sviluppo di un’applicazione sono basate su compromessi e temo che ciò che io voglio non sia ciò che altri desiderano. Detto questo, c’è un altro aspetto da considerare: le idee sono appunto idee e possono essere ovviamente applicate su editor diversi. Voglio ancora studiare le diverse possibili strade: la fattibilità di cui parlavo all’inizio deve tenere certamente conto di tutto ciò ed evitare un eccesso di spreco di energie. Considero la possibilità di intervenire su TeXworks (che, ripetto, è quello che mi ispira di più) ma lascio assolutamente spalancata la possibilità di fare qualcosa di mio.

Apprezzo molto il tuo intervento (anzi ti chiedo se puoi suggerirmi link significativi su TeXworks, a parte quelli che si trovano sulla homepage).

Torno quindi a chiedere se esiste un modo per estrarre la posizione del riquadro disegnato da \framebox.