Sono riuscito a trovare la pace dei sensi del programmatore, ovvero l’editor definitivo?
In realtà penso di no, però dopo quest’ultimo periodo di test è garantito il fatto che Scite abbia guadagnato un sacco di punti!
Non sono proprio alla prima esperienza con Scite, ma il precedente incontro (circa un anno addietro) non ha portato a niente di interessante. E ora cosa è cambiato??
Premessa
Gli editor che uso maggiormente sono EditPlus sotto Windows, mentre per Linux sono un appassionato fans di (g)vim e gedit. Il fattore scatenante che mi ha portato alla ricerca di qualcosa di completamente diverso, citando i Monty Python, è stata la scoperta del supporto ai temi, disponibile sia per gvim che per gedit, ma non per EditPlus: ho scoperto di prediligere i temi cosidetti “dark”, li trovo meno stancanti per gli occhi.
Il fatto di non poter disporre di un medesimo supporto visuale in Windows mi ha disturbato un pò (lo so che gvim c’è anche per Windows, e che anche gedit stesso può essere compilato per win32, ma a volte sono proprio pigro…), e la visione di diversi screenshot e screencast di Textmate (veramente figo!), mi ha spronato alla ricerca di qualcosa di nuovo e possibilmente unificato in modo da limitare i capogiri passando da un sistema all’altro.
E come avrete capito in Scite ho trovato quello che cercavo.
Le possibilità di personalizzazione si spingono veramente in dettaglio e permettono un controllo pressochè totale dell’editor, anche per ciò che riguarda l’aspetto estetico.

Ecco di seguito un paio di screenshot, uno per Windows e uno per Linux, in modo da evidenziare l’aspetto molto simile:

Linux

Windows

Altri screenshot sono disponibili sul mio spazio in picasaweb

Veramente niente male, eh? Syntax highlighting, code folding, tabs per lavorare su più file in contemporanea, ovviamente una toolbar (nascosta da me per default).
Un ulteriore tocco di classe è dato dal font Droid, un ottimo Sans Monospaced che, almeno ai miei occhi, risulta molto chiaro e leggibile.
Ma i vantaggi non finiscono qui, anzi ora comincia il bello!
Tramite dei file chiamati “API file” è possibile realizzare funzionalità tipo il completamento automatico o il calltip, caratteristiche di solito presenti solo in IDE decisamente più corposi di un “semplice” editor.

Calltip

Autocompletamento

L’installazione di default di Scite (parlo per Ubuntu Gutsy) non installa alcun API file, ma solo i i file .proprerties (specifici per linguaggio) che contengono al massimo l’elenco delle keywords; comunque una breve ricerca in rete può fornirne di diversi, per i più svariati linguaggi. Se poi, come è successo al sottoscritto, non è disponibile alcun supporto alle librerie utilizzate, allora viene in aiuto tags2api.py un comodissimo Python script che effettua il parsing di un tagfile generato tramite ctags e restituisce in output il file API bello pronto per essere utilizzato in Scite.

Ecco la sequenza di comandi utilizzati per generare i tagfile per le EFL


$ ctags -f imlib2.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Imlib2.h
$ ctags -f eet.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Eet.h
$ ctags -f evas.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Evas*
$ ctags -f ecore.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Ecore*
$ ctags -f edje.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Edje*
$ ctags -f embryo.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Embryo.h
$ ctags -f epsilon.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Epsilon*
$ ctags -f ewl.tags --excmd=number --c-types=pcdgstue /opt/e17/include/ewl/*.h
$ ctags -f etk.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Etk_Engine_Ecore_Evas* /opt/e17/include/etk/*.h
$ ctags -f emotion.tags --excmd=number --c-types=pcdgstue /opt/e17/include/Emotion.h
$ ctags -f engrave.tags --excmd=number --c-types=pcdgstue /opt/e17/include/engrave/*.h
$ ctags -f efreet.tags --excmd=number --c-types=pcdgstue /opt/e17/include/efreet/*.h


Ed ecco un esempio di invocazione di tags2api per la generazione del file API, nel dettaglio per la libreria ETK


$ python tags2api.py etk.tags > etk.api


Il file API non fornisce però il (o la?) syntax highlight per le funzioni specifiche, così ci ho messo del mio, e con un altro script Python creo un blocco di funzioni che va aggiunto come keywords4 nel file cpp.properties (per ora non ho trovato altro modo).

Nel mio spazio in staff.get-e.org trovate i file API delle EFL già pronti per l’uso, il mio cpp.properties e SciTEUser.properties da usare come esempio, e lo script api2func.py per generare il blocco di funzioni per il sintax highlight.
I file API possono essere messi in una qualsiasi directory, a patto che possa essere raggiunta da SciTE; la configurazione fornisce due directory predefinite: $(SciteDefaultHome), la directory nella quale si trova il file SciTEGlobal.properties (Windows -> c:ProgrammiScintilla Text Editor, Ubuntu -> /usr/share/scite), e $(SciteUserHome), la directory nella quale si trova il file SciTEUser.properties (Windows -> C:Documents and Settings , Ubuntu -> ~).
La configurazione che ho scelto e’ questa: ho creato la directory .scite/api nella mia home, l’ho riempita con i file API, e nel file SciTEUser.properties ho indicato il seguente percorso:

api.*.c=$(SciteUserHome)/.scite/api/ecore.api

Wow, ora posso ricominciare a scrivere del codice!
Scherzi a parte, mi rimane in sospeso la parte relativa a git e/o cvs, per vedere se esiste qualcosa di già fatto oppure capire come integrarli nell’editor, visto che il supporto alla compilazione c’è già!

Alla prox

[tags]scite, e17, api[/tags]