Vivere in org-mode

Un interessante articolo sull'utilizzo di org-mode per tenere organizzate le proprie attività, e seguire la filosofia GTD (Get Things Done).
Personalmente, da affezzionato utente Emacs, uso già org-mode per molte delle mie attività, ma l'approccio conciso e ben illustrato di questo articolo potrebbe aiutare altri utenti ad avvcinarsi meglio ad Org e a utilizzarne appieno le infinite possibilità.

Secondary Selection & Emacs

Una discussione sulla mailing list Perl6 mi ha portato a fare una rapida ricerca e scoprire che, ovviamente, Emacs supporta anche
la Secondary Selection. Questa è una modalità nativa di X11 (che in realtà supporta fino a 4 clipboard coesistenti) che funziona un po'
come il kill-ring di Emacs stesso, ma che nella sua implementazione non si appoggio al kill-ring.
In sostanza è possibile copiare e incollare testo indipendentemente dalla regione selezionata e senza modificare il contenuto del kill-ring,
consentendo quindi ad Emacs di gestire fino a due clipboard contemporanee, una delle quali gestita tramite un ring e collegata
alla clipboard principale di sistema.

Non usate :wq! per uscire da vi!

Una cosa che non capisco di Vi(m) e dei suoi utenti è la costante ed errata abitudine di usare il comando q! per uscire dall'editor.
Ho già scritto in precedenza riguardo questo soggetto, ma sono incappato in una innocente immagine di un minicorso del linguaggio C che, ancora una volta, insegna a chi è alle prime armi ad uscire da Vi con la combinazione mortale :wq! (qui l'immagine del post).


Vediamo di approfondire ancora una volta.
Anzitutto cosa suggerisce l'aiuto in linea di Vi? Eseguendo :help si ottiene qualcosa del genere:

*help.txt*      For Vim version 7.4.  Last change: 2016 Mar 31

                        VIM - main help file
                                                                         k
      Move around:  Use the cursor keys, or "h" to go left,            h   l
                    "j" to go down, "k" to go up, "l" to go right.       j
Close this window:  Use ":q<Enter>".
   Get out of Vim:  Use ":qa!<Enter>" (careful, all changes are lost!).

Andiamo bene! L'help in linea suggerisce di uscire dall'editor con :qa!, in sostanza l'equivalente di una kill -9!


Eppure ci sono alcuni modi molto piu' furbi di uscire da Vi senza rischiare di perdere i dati, e il mio preferito è quello di usare ZZ che esce salvando se necessario le modifiche. Perché questa cosa è importante? Perché forzare un aggiornamento del file ad ogni  uscita ne cambia il timestamp e potrebbe creare conflitti con strumenti di controllo delle versioni e di build automatico.
Ma non solo, se si digita :help :x si scopre che:

*:x* *:xit*
                        Like ":wq", but write only when changes have been
                        made.

ZZ                      Write current file, if modified, and quit (same as
                        ":x").  (Note: If there are several windows for the
                        current file, the file is written if it was modified
                        and the window is closed).

Mettiamo ora a confronto le varie modalità:

comando	caratteri	rischio di perdita modifiche
:qa!	4	si
:wq!	4	no
ZZ	3 (contando SHIFT)	no
:x	2	no

Quindi perché non istruire gli utenti da subito ad usare modalità di uscita smart, visto che risultano perfino piu' compatte (in termini di caratteri) rispetto a quelle brutali?

Cosa sono gli Emacs mode? Major mode, minor mode, oh my...

Uno dei concetti chiave di Emacs che mi pare sia molto spesso sottovalutato da chi non lo utilizza è quello dei mode.
Emacs è un editor multi-mode, ovvero è possibile attivare piu' modi contemporaneamente.
A loro volta i mode si suddividono in due categorie principali:

• major mode rappresentano il contesto di un buffer;
  
• minor mode forniscono funzioni trasversali fra uno o piu' buffer.
  

Molto spesso la differenza non viene colta, ma è importante perché l'uso combinato dei mode può personalizzare tantissimo il comportamento
di Emacs.
Anzitutto Emacs ammette un solo major mode per buffer, mentre virtualmente infiniti minor mode possono essere attivati su ogni buffer.


Un major mode definisce il "contesto" di utilizzo del buffer, nonché le funzioni principali fornite in quel buffer. Ad esempio
se si sta editando un buffer che contiene uno script Perl, il relativo major mode fornirà funzioni legate a Perl. Analogamente, se
si sta visualizzando il contenuto di una directory, il relativo major mode (es. dired) fornirà le funzioni principali
per interagire con il buffer. Un major mode può anche "rimappare" alcuni tasti funzione per rendere piu' facile l'utilizzo all'interno
di tale buffer.


Un minor mode fornisce sottofunzioni specifiche all'interno del buffer, e magari a livello globale su tutti i buffer. L'esempio classico
è quello del correttore ortografico (es. flyspell) che agisce sul testo indipendentemente questo sia codice o testo o una chat.


Per meglio comprendere questi concetti, mi si passi un blasfemo paragone con Eclipse.
In Eclipse è possibile editare progetti Java, C/C++, Perl, PHP, Python (e altri). A seconda del tipo di progetto Eclipse carica funzioni
differenti e fornisce refactoring e renaming in modo differente, e questo è esattamente quello che fa un major mode Emacs. Ecco perché poco
sopra ho parlato di "contesti" del buffer.
Tornando ad Eclipse, i commenti e le parole chiave vengono evidenziate in modo analogo fra i vari linguaggi, come pure i marker degli errori
e dei problemi, e questo è quello che fa il minor mode Emacs (ok, per i font c'è la fontify, ma non scendiamo a questo livello).
E i template del codice? Eclipse fornisce template per, ad esempio, i get e set (getter e setter), cosa che in realtà richiede due passaggi: uno di
front-end e uno di backend. Il front-end mostra la UI all'utente, il back-end scrive il codice contestualizzato. Questa operazione può essere
fatta in Emacs tramite un altro minor mode (es. yas).


Per riassumere si tenga sempre presente che il major mode stabilisce cosa è possibile fare con un buffer, sia in termini di contenuti, che di tasti funzioni,
che di funzioni stesse, mentre un minor mode stabilisce quali arricchimenti si possono fornire al contenuto del buffer.
La linea di separazione non è così marcata, perché come è noto Emacs è un ecosistema che si piega su stesso e si espande, ma per avvicinarsi a questo
strumento quanto sopra dovrebbe bastare.

Magit spin-offs: another way to name a tracking branch.

A few days ago my attention was caught by an entry in the Magit Branch Pop-up buffer: Create a new spin-off.
Uh?

What the hell is a spin off?
According to the Magit Branching documentation, a spin-off is nothing more than a tracking branch.
A tracking branch, created on the git side with the -t switch, is a branch that knows (i.e., it has
knowlegde) about the branch it was originated from. Well, every branch in git has, of course, knowlegde
about its ancestor branch (how would you merge otherwise?), but in this case
the knoweldge is made explicit by the tracking feature.


In particular, when a tracking branch is checked out git advices about commits that made the
current (tracking) branch diverging from its ancestor, something like the following:

% git checkout b
Switched to branch 'b'
Your branch and 'master' have diverged,
and have 1 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

In the above example you can see that the b branch is behind master two commits, as well as after master by one commit.
In other words, your b branch has done a single commit while master advanced by two other commits. As git
suggests, you can pull and git will automagically fetch updates from the master branch into b.
And in fact:

% git pull
From .
 * branch            master     -> FETCH_HEAD
Merge made by the 'recursive' strategy.

The tracking is useful to know transparently when and how (much) your branch is diverging from the source, and this of course
is true both for local commits and remote ones:

% git status
On branch b
Your branch is ahead of 'master' by 2 commits.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean

What happens into Magit? Well, once you checkout a tracking branch the popup buffer shows that is unmerged from the source branch, and
it does suffice to F pull to prompt the merging popup.





So, to recap, a Magit spin-off lies a tracking branch, which in turn is a branch explicitly aware of what makes it different
from the source branch. This is useful, for instance, for features and short living development branches that are going to be merged
surely by design and must be kept up to date from the normale release history. I don't see the point in using tracking into
versions branches.

Emacs yank at point (dal mouse)

Finalmente, dopo tanto tempo, ho trovato un trucchetto per far si che
Emacs incolli la clipboard tramite mouse dove c'è il cursore.
Mi spiego meglio: quando in Emacs si effettua un yank (incolla) dal mouse, mediante il pulsante centrale,
la parte copiata viene posizionata dove si trova il puntatore del mouse nel buffer, spostando il cursore in quel
punto (point). La cosa può risultare noiosa, perché spesso si vuole copiare un comando o un link da altre applicazioni
senza spostare il cursorse e senza dover posizionare esattamente il puntatore del mouse.
Niente di piu' semplice nell'editor piu' configurabile del mondo:

(setq mouse-yank-at-point t)

Valorizzando la variabile mouse-yank-at-point si ottiene il comportamento desiderato: il mouse incolla (yank)
dove si trova il cursore (at-point) senza spostare quest'ultimo.

Compilare Emacs 25.1 (per Spacemacs): segmentation fault

Se si tenta di compilare Emacs 25.1 su una Kubuntu 16.10 si potrebbe avere un errore di segmentation fault.

La soluzione e' abbastanza semplice: occorre impostare un flag del compilatore e ritentare.

./configure --prefix=/opt/emacs25.1 CFLAGS=-no-pie

Il flag no-pie produce un eseguibile che non puo' essere posizionato arbitrariamente, e questa e' una misura di sicurezza per evitare exploit sulla memoria.

Se poi si usa Spacemacs, una nuova installazione risolve diversi problemi e consente anche di far funzionare tutti i layer correttamente (ad esempio con PHP avevo alcuni problemi legati ai font-face), ma per un uso ottimale occorre che sia presente la libxml2 (-dev) affinche' si possa compilare anche il supporto alla documentazione. Ovviamente quest'ultimo punto non dipende da Spacemacs.

Quando scrivere gli articoli scientifici diventa un'arte

Un interessante articolo su come sia possibile utilizzare strumenti evoluti, anche se apparentemente antichi, per creare un workflow di editing degli articoli scientifici.

Ormai io non scrivo piu' molte pubblicazioni scientifiche, ma quando lo faccio uso strumenti molto simili. L'università invece, e paradossalmente, ha sempre cercato di condizionarmi mentalmente all'uso di strumenti di editing "piu' user-friendly" (leggasi Microsoft) e nessun controllo di gestione se non il Salva con nome e l'aggiunta di un numero progressivo...insomma, altro che approccio scientifico!

Emacs, Org, Kanban

Personalmente non sono un amante di Kanban, anzi diciamo pure che non lo applico per niente. Ok, chiamatemi pure arretrato, ma non ho bisogno della visualizzazione dei miei task, quanto piu' di gestirli correttamente attraverso stati, dealine, dipendenze, ...
... ma questa è un'altra storia!
Devo però portare all'attenzione un interessante post su come usare Org Mode, e in particolare le tabelle e i task che si possono in esso definire, al fine di gestire un flusso Kanban like: leggete con attenzione questo articolo.

Emacs, elisp e suggest.el

L'ecosistema di Emacs è veramente molto esteso e denso, ed è facile perdersi al suo interno.

Oggi ho scoperto un pacchetto denominato "suggest"  il cui scopo è tanto semplice quando sbalorditivo: dato un input e un output questo fornisce una lista di potenziali funzioni elisp che possono soddisfare la condizione.

Spacemacs

E' ormai un mese che utilizzo ogni giorno Spacemacs, una distribuzione Emacs molto curata e altamente integrata.

Devo dire che non mi trovo affatto male, anche se non essendo mai stato un utente Helm il sistema di navigazione a menu' è a tratti un po' ingombrante per i comandi che le mie dita ormai conoscono perfettamente.

Due sono le ragioni fondamentali che mi hanno avvicinato a Spacemacs:

1. l'integrazione fra tutte le librerie installate e installabili;
2. il fatto che sia possibile, con una configurazione abbastanza semplice, avere tutta la potenza Emacs in ogni installazione che devo usare.

E' ancora presto per dire se sarà un lungo amore o se si tratta di una breve infatuazione. Diciamo che al momento noto un certo rallentamento nel run-time di Spacemacs rispetto al mio plain Emacs, ma sono ancora in sperimentazione!

 

Fare il caffé con Emacs

Nell'eterna lotta fra gli editor di testo (o gli ambienti multifunzione) Emacs vince a mani basse perché....sa fare anche il caffé.

E non scherzo: esiste un modo appropriato per pilotare una macchinetta del caffé direttamente dall'editor.

Ovviamente non è possibile pilotare qualunque macchinetta: occorre che la macchina del caffé sia collegata in rete e che supporti il protocollo HTCPCP (Hyper Text Coffee Pot Control Protocol).

Atom vs Emacs

Atom.io e' un nuovo editor di testo, in fase di sviluppo.

E' promettente: un editor totalmente personalizzabile da parte degli utenti che possono scrivere facilmente moduli ed estensioni per cambiarne il comportamento e l'aspetto.

Ok, ricorda qualcosa....se non fosse per il "semplicemente" direi che e' esattamente identico ad Emacs. Eccetto che Emacs puo' essere ancora piu' semplice!

A parte le battute dovute piu' che altro alla religione degli editor, Atom appare veramente un clone moderno di Emacs.

Non solo Emacs e' di fatto l'unico vero editor totalmente personalizzabile che io abbia mai visto e usato, ma alcune delle feature di Atom sono identiche a quelle di Emacs.

Ad esempio, il modulo  Zen fa esattamente quello che il mio Emacs fa con poche righe di codice lisp, e soprattutto senza dover installare una estensione.

La possibilita' di avere i suggerimenti sui nomi dei file da editare e' esattamente quello che fa il mio Emacs con IDO.

Sort Lines  fa esattamente quello che il comando sort fa, solo che Emacs permette di eseguire gia' tutti i comandi disponibili su un buffer o una regione, e quindi risulta ancora una volta vincente.

E come per Emacs, le estensioni si sprecano e portano fino ad esempi inutili come Editor Stats  (francamente mi interessa sapere di piu' cosa sto editando che sapere 'quanto').

Insomma, a parte per la tecnologia utilizzata e per il fatto che la struttura di Atom mi appare maggiormente a "micro-kernel", direi che di differenze significative con Emacs non ce ne sono.

E questa mi sembra una bella vittoria per Emacs, precursore di molte idee riprese poi negli IDE e negli ambienti moderni.

Non mi e' ancora chiaro se Atom potra' funzionare anche in console e quindi via terminale remoto, cosa che Emacs svolge egregiamente (anzi, Emacs puo' lavorare in modalita' client-server e anche come wrapper di terminale).

Ma sicuramente una cosa e' chiara: Emacs ha una licenza piu' conveniente che quella di Atom.

Editors

No, questo non è un post tecnico: gli editors a cui mi riferisco non sono quelli di testi, bensì quelli musicali. Gli Editors sono un gruppo inglese che sta avendo un grosso successo, e devo dire hanno uno stile e un ritmo carico. Il cantante ha una voce con una tonalità molto calda, che si rapisce.

Ebbene ieri sera sono andato, o meglio mia moglie mi ha portato, al concerto degli Editors a Bologna. Ammetto che probabilmente io non ci sarei mai andato di mia iniziativa: non è un genere di band che mi interessa vedere dal vivo. 

Fino a ieri sera.

Gli Editors sul palco sono veramente travolgenti. Lo spettaccolo è stato veramente bello e travolgente, e il gruppo non si prende nemmeno una pausa fra una canzone e l'altra.

Insomma ne è proprio valsa la pena, consiglio caldamente a tutti di vedere almeno un loro concerto. E così magari qualcuno riuscirà a spiegare da dove il cantante, esile, tira fuori questo vocione avvolgente.

E prima dell'inizio del concerto, mentre guardavo i gadget, qualcosa ha colpito il lato nerd del mio cervello. La mug ufficiale degli Editors non ricorda forse un'altra mug, di un editor famoso, guarda caso il mio preferito, ovvero lo GNU dietro a Emacs? Ok il simbolo degli editors è un toro, quello di Emacs uno gnu, ma effettivamente la somiglianza c'è.

Che si tratti solo di una concidenza fra il nome della band, il simbolo scelto e il mio editor preferito?

Minimal Emacs

Non so se si debba parlare di "evoluzione" o di "regressione", ma sempre piu' spesso mi accorgo di trovarmi a mio agio con le cose essenziali e minimali, senza troppe distrazioni.

Ed e' cosi' che nell'infinito processo di configurazione del mio Emacs sono giunto al minimo storico per quanto riguarda i gadgets:

(when (fboundp 'tool-bar-mode)
 (progn
  (scroll-bar-mode -1)
  (menu-bar-mode -1)
  (tool-bar-mode -1) ) )

ovvero rimozione della toolbar, della scrollbar e perfino della barra dei menu'. In sostanza ora Emacs appare come uno di quegli orribili terminali X con il minimo delle decorazioni possibili. Perche'? Beh, perche' cosi' facendo resta un sacco di spazio per il contenuto dei buffer, e dopotutto chi usa i menu' o la scrollbar?

Duck Duck Emacs

Circa due anni fa ho iniziato ad usare DuckDuckGo (abbreviato DDG) come motore di ricerca al posto di Google Search, o meglio e' da circa due anni che alterno i due motori di ricerca.

Oggi ho scoperto che il Wiki di Emacs utilizza DDG come motore per la ricerca all'interno del sito stesso, e questo mi appare un chiaro segnale della community nei confronti della liberta' dei motori di ricerca...

IDO (era ora!)

Ho attivato IDO (Interactively Do Things), un modo per Emacs che facilita l'interazione con i buffer e i file. L'idea e' tanto semplice quanto potente: ogni volta che uno switch e' richiesto (ad esempio da un buffer ad un altro o verso un altro file) IDO entra in azione proponendo dei completamenti sulla base di quello "che trova". Se si sta cercando un file IDO mostra le possibili directory e file per ogni livello, se si sta cercando un buffer IDO mostra le alternative. Premendo solo alcuni caratteri del nome di un file/buffer IDO lo "promuove" come prima scelta, semplificando e velocizzando lo switch.

Come ogni personalizzazione, richiede tempo e pazienza per abituarsi ad usarla e ad usare i nuovi keymap, ma confido di essere attivo ed efficiente in IDO nel giro di pochi giorni (considerando anche il tempo che ormai passo in Emacs!).

E dire che l'ultima volta che avevo dato uno sguardo ad IDO non era ancora parte della distribuzione ufficiale Emacs, quindi parlo di prima della release 22!

Verso Emacs 24.4

Sono in trepida attesa del rilascio ufficiale della nuova minor release di Emacs, la 24.4, che promette molte novità interessanti.

E' possibile trovare diverse informazioni a riguardo sul planet ufficiale, ad ogni modo quelle che a colpo d'occhio mi stanno tenendo con il fiato sospeso sono:

• un sistema di bilanciamento delle parentesi degno di tale nome. Sono abituato ad usare il modo di bilanciamento di parentesi e virgolette, ma sinceramente non funziona molto bene se si forza uno sbilanciamento (ad esempio cancellando una parentesi). La nuova versione sembra essere finalmente completa dell'intelligenza necessaria a tenere il bilanciamento corretto;
• un modo uniforme e platform independent di massimizzazione della finestra;
• il modo di indentazione elettrico è ora il default, inoltre il modo di indentazione rigido si comporta un po' come in Org: le frecce consentono di spostare l'intero blocco di indentazione;
• eshell supporta ora molti comandi "visual", ossia che richiedono una modalità interattiva e non line-oriented;
• c'è un browser integrato in Emacs, e quindi non è piu' necessario installare moduli esterni;
• supporto alle notifiche di file (inotify o via glib), quindi questo dovrebbe risolvere la necessità di aggiornare buffer Dired aperti, anche se ancora non mi è chiaro se e come questa funzioni si attivi e come portarla su sistemi non Linux.

Intanto occorre portare pazienza, poi presto si potrà lanciare la compilazione di Emacs 24.4 per fare una prova su strada!

Magit migliorato ancora!

Era da un po' di tempo che non aggiornavo la mia versione di Magit, il front-end git per Emacs, e devo dire che sono rimasto molto colpito dallo sviluppo costante e accurato che il progetto ha avuto.

Certo, Magit non semplifica la vita a chi non conosce git, anzi è necessario conoscere bene il workflow di git per poter lavorare in Magit, ma la nuova gestione è veramente migliorata ed aiuta a districarsi fra le varie opzioni.

Infatti ora è disponibile un buffer con le abbreviazioni dei principali comandi, in modo da semplificare la scelta delle opzioni da seguire. Inoltre c'è un uso molto calibrato dei colori nei buffer, tanto che anche il buffer del commento di commit ora utilizza differenti colori per indicare le sezioni ignorate e quelle di testo effettivo. E a proposito del buffer dei commenti di commit: viene abilitato in default il flyspell (ovvero lo spellchecking al volo con evidenziazione delle parole sbagliate).

Complimenti agli sviluppatori per questo fantastico front-end!

Editor di testi

Aron Seigo ha pubblicato un interessante post nel quale parla della sua "conversione" da Vim a Kate, l'editor di default dell'ambiente KDE (per chi non lo sapesse, Seigo e' stato il leader dello sviluppo della versione 4 di KDE).

Tre sono fondamentalmente le motivazioni del passaggio da Vim a KDE: (i) scorciatoie simili, (ii) la possibilita' di avere delle sessioni, ossia una sorta di project management per gruppi di file e (iii) la console integrata.

L'aspetto degli editor mi tocca sempre profondamente, anche perche' l'editor di testi e' effettivamente lo strumento piu' usato da uno sviluppatore software (e anche dai sysadmin). Francamente sono abituato a Emacs e tendo a vedere negativamente ogni altra possibilita'. Si tratta certamente di una mia inclinazione e preferenza, ma Emacs e' a tutti gli effetti uno di quegli strumenti che mi permette di fare tutto e, cosa non trascurabile, funziona su qualunque piattaforma io debba lavorare. E con piattaforma non intendo solo il sistema operativo/architettura, ma anche il sistema grafico (che potrebbe anche essere assente).

Purtroppo Emacs sta diventando, a mio avviso, sempre piu' un sistema per abitudinari, e questo fara' si che molte delle feature interessanti non vengano portate su Emacs facilmente.

Tuttavia continuo ad essere molto soddisfatto di Emacs, che fino ad ora mi permette di avere una interfaccia unificata verso file system, sviluppo di software, editing di testo e shell.

Questione di gusti.