[vim] Comment vérifier la bonne fermeture des if et do

**Erlen** · 26/10/2012, 10h27

Bonjour,

J'ai fait un long script bash et j'utilise vim.
À la fin vim surligne des fi et done laissant supposer que j'ai fermer plus de if que je n'en ai ouvert. Mais après vérification je n'ai pas trouvé d'où venait cette erreur. Et le script s’exécute sans erreur, un bug de vim ?
Y a-t-il un moyen de vérifier tout ceci. Notamment existe-t-il un éditeur qui permette de fermer les différents if écrit un peux comme pour les éditeurs tex ou on peut compresser les \begin \end.
Merci

**N_BaH** · 26/10/2012, 11h03

ce n'est pas un bug de vim à proprement parler, mais du script de coloration syntaxique, qui ne prend pas ou mal en charge certains aspects du shell pour lequel tu code.

solution facile : une indentation rigoureuse.
pour plus : corriger le script de coloration syntaxique
...
?

**Erlen** · 26/10/2012, 11h17

Alors j'ai une indentation rigoureuse mais quand on ouvre une boucle sur 150 lignes difficile à la fin de vérifier.
Sinon tu veux dire quoi par

corriger le script de coloration syntaxique

**N_BaH** · 26/10/2012, 12h26

sur Debian, il est sous /usr/share/vim/vim72/syntax/sh.vim

**jack-ft** · 26/10/2012, 13h50

Envoyé par Erlen

Y a-t-il un moyen de vérifier tout ceci.

Comme je l'ai déjà dit ailleurs, je ne tape jamais aucun caractère d'indentation: je demande à mon éditeur de le faire pour moi.
J'ai un peu testé vim il y a un an. Il y a plusieurs modules de coloration et d'indentation et j'ai eu un peu de mal à comprendre comment les utiliser.
Du coup, je suis repassé sous mon emacs préféré...
mais le module sh-mode n'est pas parfait!
Il m'arrive parfois de repasser un coup un fichier sous vim et de lancer quelque chose comme "=G" pour réindenter tout le code et comparer avec ce que me propose emacs (avec C-x h C-M-\) pour comprendre l'origine des problèmes.
Sinon il me semble avoir entendu parler d'une sorte de lint en ligne pour script shell... est-ce une voie?

J'ai eu des soucis avec des backquotes mal fermées dans des strings qui ont tendance à paniquer les parsers. Du coup, je les remplace systématiquement par des $()