In effetti scrivere regular expression fa spesso uscire di testa, ma con vim è un massacro perchè è leggermente diverso dallo standard che sono abituato ad affrontare col perl. Sic.

Qui c’è un bello schema riassuntivo: Vim Regular Expressions

Se per caso servisse sistemare dei tag uno per riga, si potrebbe usare una cosa del genere:

: [intervallo]global/[matching]/[comando]

Essenzialmente definito l’intervallo di righe su cui agire, global effettua un comando secondo le occorrenze definite dal matching.

Nel caso specifico si vogliano cancellare le righe vuote in tutto il file, la stringa sarà la seguente:

: %g/^$/.d

Dove % indica tutte le righe del file, g sta per global, ^$ è la sintassi della regex per individuare le righe che non contengono nulla, .d indica di cancellare nel punto individuato.

Gli operatori delle regexp sono greedy. E’ un dato di fatto.
Se prendiamo una riga tipica e html’osa come la seguente:

<span>Questa riga <b>è orgogliosamente</b> taggata a random.</span>

avremo la prova che la regexp è avida.
Un pattern infatti come /<.*>/ match’erà tutti gli elementi che
- partono con un <,
- comprendono un numero qualunque (*) di qualsiasi carattere (.),
- fino ad arrivare al più estremo >.
Questa è la cosa interessante: quel pattern match’a tutta la riga, non solo il primo tag.

<span>Questa riga <b>è orgogliosamente</b> taggata a random.</span>

E questo perché gli operatori delle regexp (ie: *) sono avidi, cioè cercano le corrispondenze su quanto più testo è possibile (ie: fino all’ultimo >)!

Dunque, che si fa se si vuole avere un pattern più ragionevole, magari solo e precisamente sui tag?

Semplice, bisogna spiegare a * di non essere così goloso.
Gli operatori (nelle regexp di perl) si rendono non-greedy grazie a ? (attenzione: ? applicato ad un operatore alla sua sinistra è diverso dall’operatore ? utilizzato come rimpiazzo di un carattere).
Una dicitura corretta del pattern è /<.*?>/, che porterà al seguente evidenziamento:

<span>Questa riga <b>è orgogliosamente</b> taggata a random.</span>

Purtroppo per fatti suoi, il magnifico editor VIM utilizza un modo alternativo per de-greedy’zzare gli operatori (e in generale per le regexp). Nello specifico in VIM la sintassi è /<.\{-}>/ . L’operatore *? del perl è rimpiazzato da un poco leggibile \{-}.

Ulteriori info riguardo le regexp di vim le ho trovate qua: http://www.geocities.com/volontir/ (parte 4.3).

Il buon vecchio:

sim@idrogeno:~/script/gcc/tmp$ cat hw.c
#include 
int main(int argc, char **argv) {
        printf("Hello world\n");
        return 0;
}

post compilazione appare così:

sim@idrogeno:~/script/gcc/tmp$ head -n1 hw
ELF>à@@À@@%"@@@@@À@@@@¤¤ ¨¨`¨▒ ÐÐ`Ð` @@
Påtdèè@è@$$Qåt/lib64/ld-linux-x86-64.so.2GN
▒ÂÀ__gmon_start__libc.so.6puts__libc_start_mainGLIBC_2.2.5u▒i
1`HèkèúèåHÃÿ5Ê ÿ%Ì @ÿ%Ê héàÿÿÿÿ%Â
héÐÿÿÿ1íIÑ^HâHäðPTIÇÀð@HÇÁ@HÇÇÌ@èÇÿÿÿôHHY HÀtÿÐHÃUHåSH=p
uK¸À`Hj H-¸`HÁøHXÿH9Ús%HBHE ÿŸ`H7 H9ÚrâÆ# H[ÉÃfff.UH=
Håt▒¸HÀt¿È`IÃÉAÿã@ÉÃUHåHì}üHuð¿Ü@èÛþÿÿ¸ÉÃóÃfffff.Hl$ØL|$øH- L=
Ld$àLl$èLt$ðH\$ÐHì8L)ýAþIõHÁýIÔèSþÿÿHít1Û@LâLîD÷AÿßHÃH9ërêH
\Hl$Ld$▒Ll$ Lt$(L|$0HÄ8ÃUHåSH
Høÿt»¨`DHÿÐHHøÿuñH[ÉÃHè_þÿÿHÃHello worlc$äþÿÿÿÿÿx▒ÿÿÿzRx
zRx                                                                                Ì@ AC
  þÿÿ$4þÿÿJf@ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
È@@@õþÿoh@è@@                @
sim@idrogeno:~/script/gcc/tmp$

Bene. Ogni tanto capita di avere a che fare con spazzatura illeggibile.
Ora, se apriamo il binario con vim -b hw avvertiamo l'editor che sta per aprire un binario, quindi che stia attento.
Il codice è comunque ancora illeggibile.
Per rendere piu' chiaro l'hex interno usiamo l'opzione :set display=uhex che visualizza i vari valori byte per byte.
Dovremmo vedere qualcosa tipo:

<7f>ELF<02><01><01><00><00><00>
[...]

Per essere in grado di lavorare sul serio sul codice piu’ comodamente è necessario convertire il testo (o meglio, fare un hexdump) ulteriormente con un programma unix che si chiama xxd (man) attraverso l’opzione :%!xxd (modifica tutto il file [%] usando il comando esterno [!] xxd). Avremo quindi:

sim@idrogeno:~/script/gcc/tmp$ head hw.xxd
0000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
0000010: 0200 3e00 0100 0000 e003 4000 0000 0000  ..>.......@.....
0000020: 4000 0000 0000 0000 c010 0000 0000 0000  @...............
0000030: 0000 0000 4000 3800 0800 4000 2500 2200  ....@.8...@.%.".
0000040: 0600 0000 0500 0000 4000 0000 0000 0000  ........@.......
0000050: 4000 4000 0000 0000 4000 4000 0000 0000  @.@.....@.@.....
0000060: c001 0000 0000 0000 c001 0000 0000 0000  ................
0000070: 0800 0000 0000 0000 0300 0000 0400 0000  ................
0000080: 0002 0000 0000 0000 0002 4000 0000 0000  ..........@.....
0000090: 0002 4000 0000 0000 1c00 0000 0000 0000  ..@.............

Ora possiamo modificare il programma con vim andando a toccare i codici hex nella parte centrale (la parte letterale è irrilevante).
Posizionandoci su un carattere nella parte letterale e utilizzando il comando ga possiamo vedere che vim ci annuncia la codifica in hex corrispondente (e, ovviamente, presente nella parte centrale nel caso di caratteri).
E’ fondamentale, finite le modifiche al codice, reversare il dump con :%!xxd -r e poi salvare l’eseguibile con vim come normale.

A me piace vim, mi ci trovo benone. E mi fa comodo che evidenzi il testo degli script in maniera leggibile.

In linea generale, l’impostazione d’esempio fornita (/usr/share/vim/vim71/vimrc_example.vim) va alla grande. Unica pecca, i commenti blu scuro che su sfondo nero diventano difficili da identificare. E così si incominciano a leggere documentazioni varie e a rompere le balle a chi si conosce che potrebbe avere gli indizi necessari.

Seguendo la documentazione, spesso si legge di un’impostazione da inserire nel ~/.vimrc che risolve le cose in maniera rapida e veloce.

set background=dark

In effetti questa impostazione dice a vim che il background del terminale è scuro (c’è anche l’opzione light), e l’editor cambierà i toni dei colori di conseguenza, in modo da aumentare il contrasto. Il tutto rende il testo più leggibile, ma cambia i colori impostati.

Ammettiamo che vi piacciano i colori, ma quel commento blu proprio non vada giù…

La soluzione eccola qua: leggendo documentazione su syntax e guardando gli esempi nelle dir /colors (es.: /usr/share/vim/vim71/colors) si vede che è possibile settare i colori dei singoli parametri tramite il comando highlight (hi). Attualmente il problema è risolvibile aggiungendo all’inizio di .vimrc le righe come questa:

hi clear

syntax on

hi Comment  ctermfg=Gray ctermbg=Black