Adopting vim native package management.

OK, today, I switch to Vim 8 native package management.

Before, I used Pathogen with controversial git submodule feature.

I think it's always better to use native features instead of third party ones, even if I never had any issue with Pathogen.

If you have a similar configuration, just type following commands to switch (assuming your modules are in .vim/bundle directory)

cd ~/.vim  # go to your vim config directory
mkdir -p pack/myplugs/start  # create a pack dir for plugin loading on startup
for DIR in bundle/*; do git mv $DIR pack/myplugs/start; done  # move every submodule from bundle to pack keeping git aware 

You may have to update your git submodules if they emptied in the process:

git submodule update --recursive --remote

Then edit your ~/.vimrc file to remoce call to pathogen

" remove this line
call pathogen#infect() 

Rerun vim, to check if everything is OK for you. Cleaning the .vim directory is left as an exercise.

Native package management feature adds plugins to the runtime path at startup for bundles stored in .vim/pack/whatever/start. You can also configure optional module by putting them in .vim/pack/whatever/opt. If you put a module foodebug in that directory, you have to activate it manually with command:

:packadd foodebug

You could achieve the same with Pathogen though.

Unfortunately, using packages loaded at vim startup does not make their documentation directly available with :h command. To do so, it seems you have to manually update your help tags using:

:helptags ~/.vim/pack

Now I use space as leader

Lately, I read an increasing number of articles about using space bar as leader key to Vim. So I decided to give it a try.

Leader key is a key that can be use in your Vim mapping with the <leader> keyword. For instance:

" Typing <leader> then n in normal mode toggles NERDTree
nnoremap <leader>n :NERDTreeToggle<cr>

So it can quickly become a mapping trigger.

I have to admit I am a recent user of the leader key. By default, it's set to backslash. You can change it by writing the line bellow in your .vimrc:

let mapleader='<some_char>'

Backslash is not convenient, even less for French users sticking with French keyboard layout. So I changed to the comma (as I read it was the way to do). It makes me begin to use it in my mapping. But I have not using it a lot so far, as the comma does not get so easily under my finger.

And a couple of days ago, I decided to map it to space. And I got my mind blown!

" doing so is enough
let mapleader=' '

Obviously, the space bar is the most accessible key of your keyboard, so mapping can be typed as easily as possible.

The greatest effect is that it makes me think about creating new mappings to improve my productivity. And I have a lot of fun doing it since then. I shall update my .vimrc on github soon. I have put some other new stuff in it.

Miscellaneous Vim Tips

Lately I was reading an old book about Vim. And I found a bunch of new tricks I didn’t know!

• :sbuffer N: split the screen horizontally and open buffer N. No need to ctrl+W, S then :bN anymore! You can split vertically with :vert sbuffer N (or the shortcut :vert sbN)
• If you have splitted your screen to much and you feel that your life is a mess, try CTRL+w, o to keep current window only.
• If you have splitted your screen to much and you feel that your life is a mess, try :qall to quit all at once. I remapped it to q in command mode in my .vimrc this week.
• I used to be very limited in visual mode. Precisely, I almost never use the block visual selection. I’m wrong! You can select a block and do I<insert your text><esc> to insert before the block in every seleced line. A<insert your text><esc> to insert after the block.
• Speaking about visual block, you can select the whole lines form the block selection by hitting $. It could be useful.
• gd in normal mode stands for “go to declaration”. It may work for the language you need and can help you on legacy code with oversized functions / methods.
• CTRL-x, CTRL-f: as you may know, Vim has several types of completions that are extremely useful. I didn’t know this particular one: it completes using file names in current workin directory (cwd). By the way, if you want to change Vim cwd do like you do in the shell with command :cd <directory>.
• CTRL+l redraws the buffers. It’s quicker than :redraw command.

I’m glad to be still learning with Vim after all these year. That’s a reason why I like this editor so much. Have a nice week end folks!

Un peu de typographie avec Vim

Pour changer, une note en Français.

Ces derniers temps, j’ai lu plusieurs articles sur les règles de typographie, notamment en Français. Ces règles sont souvent bafouées sur le Net où il est fréquent de constater des espaces insécables oubliées, des traits d’union utilisés à la place de tirets cadratins ou même le rejet systématique des ligatures. Je n’ai même pas le cœur d’évoquer le traitement infligés aux guillemets, à l’apostrophe et aux majuscules accentuées.

Le fait est que l’application de ces règles est malaisée sur Internet, car le contenu est rarement écrit au travers d’un éditeur de texte perfectionné. Cela oblige l’auteur à utiliser ces immondes entités HTML comme « œ ».

Avec Vim, le calvaire typographique est terminé. Vim propose en effet une fonctionnalité géniale : les digraphs. Les digraphs permettent de remplacer la saisie d’un caractère unicode – qui se fait normalement à partir de son code – par la saisie de deux caractères, choisis de façon à pourvoir se rappeler facilement de l’effet de leur combinaison. Le « mode » digraph s’obtient avec la combinaison ctrl + k en mode insertion. Ainsi tapez ctrl + k puis :

• oe pour obtenir œ ;
• E' pour obtenir É ;
• << pour obtenir « (et inversement) ;
• <espace><espace> pour obtenir une espace insécable.

etc…

D’autres sont moins instinctives :

• -N donne un tiret demi-cadratin (–) ;
• -M donne un tiret cadratin (—) ;
• '9 donne l’apostrophe (’).

Il est également possible de créer ses propres digraphs. Par exemple, les points de suspensions… Il suffit, pour cet exemple, de rajouter cette ligne dans votre fichier .vimrc. Ainsi, le digraph pour les points de suspension sera « 3. ».

digraphs 3. 8230

Et pour faciliter le processus, vous pouvez carrément utiliser un plugin qui va faire les remplacements directement au moment de la frappe. J’ai vu UniCycle pour le faire en anglais. Je l’ai forké pour l’adapter au Français. Ça doit prendre une demi heure à faire mais je n’ai pas pris le temps !

Deux dernières choses. Tout d’abord, il existe des formes de ligatures plus fines encore, comme les enchainements de f, de t et de i. Même pour moi cela commence à aller loin, en tout cas pour l’instant. Les digraphs de base de Vim sont limités pour ça, et parfois même les fontes. Par exemple, pour f et i, le digraph fi donne « fi » mais pour t et i, le digraph ti donne le hiragana chi (ち).

Enfin, vous pouvez encore plus loin en utilisant la gestion des césures, via la propriété CSS hyphens. Même si c’est encore expérimental, c’est plutôt cool, non ?

Maintenant, vous n’avez plus d’excuses pour ne pas utiliser Vim à chaque fois que vous voudrez taper du texte !

Code folding in Vim

An intresting feature that a use from time to time in Vim is code folding. It allows you to fold and unfold parts of your code soure using za in normal mode.

To use it, you have to choose a fold method, which is the strategy that vim will use to fold the code. Vim knows following methods:

• manual
• indent
• expr
• marker
• syntax
• diff

Check :h foldmethod for details. The methods I use the most are indent which uses the indentation level to decide when to fold (it can be useful on large xml document) and marker.

Marker is a bit particuliar since it fold using a marker on a comment line. By default, the marker is

[inline comment mark] {{{ Label
some folded code
[inline comment mark] }}}

Last trick: it's cumbersome to set foldmethod=marker every time we open a file that use marker foldmethod. To avoid that, you can pass vim set command in a comment at the end of your file:

[inline comment mark] vim: foldmethod=marker

Then reopen your buffer et voilà!

Folding is interesting when your dealing with great amount of data. Please remember that it is not a good idea to make regions within a function. If you think that you fonction is too big, be courageous and split it in smaller ones.

Espaces insécables dans vim

Je l'ai appris il y a peu de temps et je l'utilise de plus en plus. Et oui messieurs dames, l'espace insécable existe dans Vim. Vous pouvez en insérer en faisant ctrl + k puis 2 fois espace.

Quel intéret me direz vous ?
D'une part, cela permet de ne pas couper les espaces lorsque vous reformatez un bloc avec la commande gq ou indépendamment de votre volonté si vous avez paramétré l'option textwidth. Cela permet notamment de ne pas coupez vos liens quand vous écrivez en markdown, par exemple ou si vous êtes tatillons sur l'usage de l'espace insécable dans la ponctuation en Français.
D'autre part, comme il s'agit (si j'ai bien compris) d'un caractère unicode, vous pouvez le mettre dans tous vos documents en UTF-8. Je veux dire par là que vous pouvez vous passer de l'utilisation de l'attroce &nbsp; dans vos documents HTML. Notez en passant que j'ai eu un mal fou à savoir orthographier correctement cette entité.

Seul point négatif : c'est un caractère vide (blank). Comment dans ce cas faire la différence dans vos document entre un espace sécable et un espace insécable ? En temps normal, j'ai envie de dire qu'on s'en fiche. Si toutefois, vous voulez le voire dans Vim, utilisez les commandes ci-dessous :

" listchars permet de dire comment afficher les caractères invisibles
set listchars=nbsp:%

" list permet de déclencher l'affichage des caractères invisibles, selon le
" paramétrage de l'option listchars.
set list

" Et, classiquement, pour les faire disparaître
set list!

C'était l'article utile du week-end.

Les autocommands dans Vim

Les autocommands sont une fonctionnalité intéressante de Vim. Elles permettent d'exécuter des actions lors d'évènements générés par l'éditeur. Par exemple, vous pouvez enclencher la correction orthographique en Français si vous éditez un fichier Latex. La commande pour cela est :

:autocmd BufNewFile,BufRead *.tex  set spell spelllang=fr

Analysons cette commande. La déclaration d'autocommands utilise la commande autocmd. Sa syntaxe est la suivante :

:au[tocmd] [group] {event} {pat} [nested] {cmd}

Dans notre cas, nous n'avons pas spécifié de groupe. {event} représente l'évènement à écouter. On peut associer une action à plusieurs évènements, comme ici où on veut déclencher une action sur BufNewFile, création d'un fichier dans un buffer et sur BufRead, lecture d'un fichier dans un buffer. {pat} est le motif associé à l'évènement, ici un nom de fichier se terminant par .tex. cmd est la commande à exécuter telle qu'on pourrait l'écrire en mode normal.

Je n'aborde pas [nested] qui sert à imbriquer des autocommand car je n'ai pas bien saisi les cas d'utilisation !

La page autocommand-events de l'aide vous donnera tous les évènements qu'il est possible d'écouter. Vous comprendrez alors qu'il s'agit d'une fonctionnalité majeure qui offre énormément de possiblités.

Personnellement, je l'utilise surtout pour :

• changer les options d'indentation suivant le type de fichier ;
• utiliser des templates lors de la création de nouveaux fichiers ;
• mettre en place des mappings spécifiques.

Quelques conseils pour plus de facilité dans vos tests de configuration. Tout d'abord, vous verrez que lorsque vous vous attaquez à des commandes un peu compliquées et que vous sourcez régulièrement votre fichier .vimrc, les commandes s'ajoutent. Vous pouvez éviter ce comportement en utilisant la commande suivante, qui supprime toutes les autocommandes définies :

:autocmd!

Comme ce n'est pas super pratique d'appeler systématiquement cette commande avant de sourcer votre .vimrc vous pouvez également faire figurer vos autocommands dans des groupes. Toutes les autocommands d'un groupe sont réinitialisées si celui-ci commence par la commande :autocmd!. Exemple :

augroup sqlgroup
    autocmd!
    autocmd BufEnter *.sql,*.pks,*.pkb setlocal ignorecase
    autocmd FileType sql inoremap <buffer> DO<Tab> DBMS_OUTPUT.PUT_LINE();<Esc>hi
augroup END

Enfin, si vous utilisez les autocommands pour des mappings ou pour paramétrer des options, réduisez leur scope au buffer contenant le fichier :

"mapping local au buffer
autocmd FileType sql inoremap <buffer> DO<Tab> DBMS_OUTPUT.PUT_LINE();<Esc>hi
"set local au buffer
autocmd FileType html,xml,ant setlocal softtabstop=2 shiftwidth=2

Vous voilà maintenant prêts pour mettre en place une foule de snippets spécifiques à chaque type de fichiers que vous éditez !

En cas de besoin, je partage mon fichier .vimrc sur Github.

Tableaux like a boss

J'utilise beaucoup reStructuredText (rst) au boulot pour initialiser de la documentation. Ce qui est intéressant avec ce système, c'est qu'il est possible de tracer des table en ASCII qui vont être interprétées et transformées dans le langage cible (html pour moi).

La façon la moins tordue de décrire ces tables est la suivante :

=======  =======  =======
Header1  Header2  Header3
=======  =======  =======
cell11   cell12   cell13
cell21   cell22   cell23
=======  =======  =======

Vous remarquerez que c'est déjà super chiant de tout aligner et vous devez me penser que je suis un doux dingue pour tenter de vous dire que rst est génial si vous voulez décrire un tableau de 30 colonnes. Un peu c'est vrai...

Rassurez-vous, je ne trace pas ces tableaux à la main ! J'essaie d'être un peu plus malin.

Il existe une commande column sous Linux / Cygwin qui permet d'afficher des données sous forme de table. Génial ! Essayons d'en tirer parti dans Vim.

Commencez à décrire votre tableau en séparant les champs par des pipes :

Header1|Header2|Header3
cell11|cell12|cell13
cell21|cell22|cell23

Sélectionnez les lignes avec Vim (Shift + V) puis tapez la commande suivante :

:'<,'>!column -t -s '|'

Elle prend la sélection, et la passe à travers la commande column. L'option -t lui dit de conserver les lignes et l'option -s permet de définir le séparateur.

Vous vous retrouvez avec ça :

Header1  Header2  Header3
cell11   cell12   cell13
cell21   cell22   cell23

Il vous suffit alors de mettre les délimiteurs de table pour que votre tableau soit reconnu par rst.

=======  =======  =======
Header1  Header2  Header3
=======  =======  =======
cell11   cell12   cell13
cell21   cell22   cell23
=======  =======  =======

Et voilà !

La coloration syntaxique dans vim (le 'straight' vim)

Une coloration syntaxique agréable c'est super important. J'ai mis du temps à m'en rendre compte finalement.

Il y a quelques mois, je suis passé de gVim (la version graphique avec des menus et où on peut nativement utiliser la souris), à Vim en mode texte, dans le terminal. Là, la première chose que je me suis dit, c'est que c'est moche. En effet, on a un pauvre ensemble de couleurs : on est bien loin des thèmes du mode graphique (ah desert, comme ton chatoiement me manqua alors !).

Je me disais à ce moment que c'était une fatalité... j'ai commencé à me faire à l'idée que les choix de couleurs pour le surlignage de recherche (hlsearch) ou pour le diffsplit allait progressivement me rendre aveugle (clair fluo sur clair fluo, vous saisissez ?).

Au bout d'une semaine passer à me ré humecter les yeux au sérum physiologique, je me suis dit qu'il fallait faire quelque chose... Et voilà le résultats de mes intenses recherche.

Étape de guérison numéro 1 : vous pouvez réclamer plus de couleur à votre terminal

Et oui, ces petits salauds de terminaux peuvent bien souvent cracher 256 couleurs mais ne prennent pas la peine de le dire à notre Vim adoré. Alors il faut forcer un peu les choses. Taper cette commande et mettez là aux premières loges de votre .vimrc (sans les deux points, bien sûr).

:set t_Co=256

Étape de guérison numéro 2 : des beaux thèmes existent

Trouvez des endroits qui parlent de beaux thèmes de coloration. Installez en. Prenez 30 minutes de votre temps pour en tester plusieurs sur les langages avec lesquels vous avez l'habitude de coder.

Rappelez-vous : les thèmes de base de vim sont tous globalement pourris. Je les ai tous passez en revue. Quand la coloration n'est pas moche, c'est le highlighting ou le wildmenu qui sont illisibles. Heureusement que des gens de goût existent dans le village mondial.

Pour changer de thèmes, une fois les formalités d'installation dépassées (comment, vous n'utilisez pas encore git et Pathogen, tss...), la commande c'est

:colorscheme <votre_theme>

(remarque : oui, ce n'est pas set colorscheme, c'est colorscheme, direct, sans emphase. Me demandez pas pourquoi, de toute façon je m'en fous)

Mon choix à moi : Jellybeans

J'ai choisi, pour l'instant en tout cas, le thème Jellybeans de nanotech. Je l'adore ! Voici ses points forts selon moi :

• Des couleurs élégantes et peu agressives qui toutefois se démarquent bien les unes des autres.
• Du surlignage qui ne m'éclate pas les yeux, que ce soit sur le hlsearch, les TODOS, le diffsplit ou le wildmenu.
• Sur le html, il utilise un jeu de couleurs différent pour les balises ouvrantes et les balises fermantes. Cela m'a surpris au début mais je trouve ça finalement plutôt pas mal.

Sur ceux, je vous laisse dans votre quête du thème de couleur parfait pour votre éditeur de texte. Et ne cédez pas à la tentation d'utiliser SublimeText pour autant !

Dernières remarques

• Je n'ai rien contre SublimeText. Je trouve qu'il porte très bien son nom. Hélas, j'aime trop vim pour avoir l'idée de changer.
• Le * du dessin : cette remarque s'applique en premier pour moi. Comme on dit, c'est l'hôpital qui se fout de la charité !

Caractères Appariés

Une fonctionnalité sympathique de certains éditeurs de texte est de pouvoir apparier des caractères et de placer le curseur au milieu pour continuer la frappe. Exemple : vous tapez un guillemet double, l'éditeur en écrit deux et laisse le curseur entre les deux. C'est ce que fait par exemple l'éditeur d'IntelliJ. Le problème est que ce comportement est parfois indésirable et nous ralentit dans certaines situations. Je me suis demandé comment mettre en place ce comportement vim. Ma solution simple, utiliser des mappings en mode insertion.

imap '<TAB> ''<ESC>i
imap "<TAB> ""<ESC>i
imap [<TAB> []<ESC>i
imap {<TAB> {}<ESC>i
imap (<TAB> ()<ESC>i
imap <<TAB> <><ESC>i

Dans cette configuration, je valide l'appariement par Tab. Ça demande un peu de pratique mais ça me convient : je préfère avoir à valider un comportement automatique plutôt que d'annuler son déclenchement.

J'ai vu qu'il existait un plugin pour faire la même chose mais la description et le code ont l'air compliqués ('¬°o°)¬. Alors je crois que je vais continuer à utiliser mes petits mappings.

Abréviations et snippets dans Vim

J'utilise depuis peu de temps les abréviations dans Vim. Comme leur nom l'indique, elles permettent un remplacement automatique du texte tapé.

On peut mettre en place une abréviation à l'aide de la commande :ab[breviate]. Il est possible d'utiliser un préfixe pour mettre en place une abréviation pour un mode précis. A priori, vous allez les utiliser surtout en mode insertion, vous préférerez donc la commande :ia[bbrev].

Par exemple, tapez la commande suivante :

:ia teh the

Et lorsque vous taperez teh en mode insertion, il sera remplacé par the. C'est beau non ? On se croirait dans Word...

Il y mieux. Vous pouvez vous en servir pour faire des snippets. Par exemple, vous voulez que MAIN soit remplacé par :

if __name__ == '__main__': 
    main()

Vous pouvez passer la commande suivante :

:ia MAIN if __name__ == '__main__':<CR>main()

(si votre indentation automatique marche bien, ça ira !)

<CR> signifie carriage return, c'est le truc de base pour mettre un retour charriot dans les abréviations et les mappings.

Le problème, c'est que le remplacement aura lieu à chaque fois que vous taperez le terme. Pour éviter un remplacement, vous pouvez l'annuler avec Ctrl+V après la saisie. Ce n'est pas forcément ce que vous souhaitez...

OK, alors voilà ce que vous pouvez faire : vous pouvez utiliser un mapping en mode insertion. Reprenons notre exemple, sauf que nous souhaitons à présent que le remplacement soit validé par appui sur la touche Tab.

:imap MAIN<TAB>  if __name__ == '__main__':<CR>main()

Si vous ne vous rappelez pas vos abréviations ou de vos mappings utilisez simplement :

:ia

pour lister vos abréviations et

:imap

pour lister vos mapping.

Si vous voulez mettre en place une liste de snippet pour un type de fichier donné (exemple, pour du C ou du Python), peut-être pouvez vous mettre tous vos ia et imap dans un fichier que vous sourcerez par une autocommand. Mais cela fera l'objet d'un autre post sur Vim.

VIMTIP : K majuscule

À la dernière réunion TupperVim (!) de Grenoble, je me suis aperçu qu'il y a une fonctionnalité de vim qu'on découvre souvent par erreur : l'accès à la doc avec K (K majuscule). Par défaut, le programme appelé est man. C'est donc utilie pour le C et le shell. Mais en dehors de ça...
Et bien, rassurez vous : c'est paramétrable via la commande suivante

:set keywordprg=<programme>

Si vous laissez keywordprg vide, l'aide de vim sera utilisée, ce qui est pratique... pour naviguer dans l'aide de vim !

Si vous codez du Python, vous pouvez ainsi faire :

:set keywordprg=pydoc

Ce qui vous permettra d'accéder à la doc pour l'élément sous le curseur avec K. À placer en autocommand.

ctags

ctags a participé à sauver ma journée.

C'est un outil qui génère un fichier tag contenant les endroits où sont définis les éléments (fonctions, classes) dans les fichiers source. Ce fichier tag est ensuite utilisable par des éditeurs de texte comme vim. Je pensais qu'il ne marchait que pour le C et le C++, mais en fait il prend en compte beaucoup de langages :


romain@lilibox:~$ ctags --list-languages
Ant
Asm
Asp
Awk
Basic
BETA
C
C++
C#
Cobol
DosBatch
Eiffel
Erlang
Flex
Fortran
HTML
Java
JavaScript
Lisp
Lua
Make
MatLab
OCaml
Pascal
Perl
PHP
Python
REXX
Ruby
Scheme
Sh
SLang
SML
SQL
Tcl
Tex
Vera
Verilog
VHDL
Vim
YACC


Vous construisez le fichier avec

ctags -R


Dans le code source avec vim, faites Ctrl+] pour aller à la définition d'une fonction[1] et Ctrl+t pour revenir à l'endroit précédent.

L'inconvénient est qu'il faut générer les tags dès qu'on retouche aux fichiers où sont définies les fonctions appelées, mais pour débugger du shell ou du C tordu, ça aide bien !

[1] et oui, cela marche mieux avec la disposition américaine des touches !