Honnêtement, je peux dire que je suis un bon vimeur. Et je ne peux pas t'accorder le fait que Vim a un dixième des qualités d'un IDE.
Contres-citation et ajouts:
Auto-complétion
Ctrl+p sous vim.
Non, non, et non. L'autocompletion est un des points noirs de vim. Et ce pour plusieurs raisons:
1. C'est horriblement lent dès que l'on est pas dans la completion de mots des buffers ou de chemins (^X^F FYI).
2. On ne peut pas avoir plusieurs plugins qui alimentent le buffer de completion en même temps, il faut créer un faux-plugin wrapper pour cela (neocomplete + neosnippet + neocomplcache, oubliez clang-complete, snipmate, ou autre).
3. Elle n'est pas intelligente. Clang-complete fait un début de completion intelligente pour un cas précis (méthodes et attributs), mais ça n'a rien à voir avec une completion qui prend en compte le type, la sémantique probable, etc. Ce que sait faire un bon IDE.
4. Interruption du flot d'écriture. Si la completion est bien faite (hommage à ReSharper et InteliJ Idea), elle ne doit pas interrompre trop le flux d'ecoulement des doigts sur le clavier. Celle de Vim en est douloureuse, mais c'est un héritage à assumer.
Aide en ligne: Affichage dans une bulle de la signature des méthodes avec description des paramètres… Lien direct vers la doc complète
:Man sous vim. Possibilité de mapper ça sur une séquence de touches exécutées sur un mot. Je code en C, donc ça me suffit comme doc.
:Man not an editor command. J'assume que tu parles de Man.vim. Tu savais qu'il existe ^K pour ça ? (EDIT: c'est pour un afichage en pop-up OK)
À part ça, dans un gros ou moyen projet, le fait de ne pas pouvoir voir la doc autrement qu'avec ^], c'est souvent gênant. Et encore, il faut avoir généré le tagfile idoine, et qu'il soit dans le tagpath de vim.
Refactoring: Renommer/déplacer du code, laisser l'IDE montrer les impacts, valider et zou c'est fait Vs compiler, "ah merde il y a ça aussi à changer", recompiler, "ah merde j'en ai oublié un autre"…
Le :make -> amené à la ligne fautive -> correction -> :make -> … est très efficace également.
Non. Il l'est dans ton cas. Les problèmes de :make sont:
1. Make est lent de base. Si ton projet est un peu gros et en C++, avec des templates, avec CXX=g++, tu as perdu.
2. Surtout si certains de tes fichiers sont générés par un soft externe (eg: flex, bison, swig, doxygen, script de rapatriement perso)
3. :make met vim en pause ! Tu ne peux pas travailler pendant que ça compile en background.
4. :make pour du C# ? Pour du Java ? Pour du Qt ?
Bref, je m'arrête là. J'ai aussi une nette préférence pour Vim lorsque je code en C. Mais en C++ je sors KDevelop avant que les choses ne dégénèrent. ;)
[^] # Re: On peut toujours creuser un trou à mains nues...
Posté par mackwic . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 10. Dernière modification le 11 mai 2013 à 12:34.
Honnêtement, je peux dire que je suis un bon vimeur. Et je ne peux pas t'accorder le fait que Vim a un dixième des qualités d'un IDE.
Contres-citation et ajouts:
Non, non, et non. L'autocompletion est un des points noirs de vim. Et ce pour plusieurs raisons:
1. C'est horriblement lent dès que l'on est pas dans la completion de mots des buffers ou de chemins (^X^F FYI).
2. On ne peut pas avoir plusieurs plugins qui alimentent le buffer de completion en même temps, il faut créer un faux-plugin wrapper pour cela (neocomplete + neosnippet + neocomplcache, oubliez clang-complete, snipmate, ou autre).
3. Elle n'est pas intelligente. Clang-complete fait un début de completion intelligente pour un cas précis (méthodes et attributs), mais ça n'a rien à voir avec une completion qui prend en compte le type, la sémantique probable, etc. Ce que sait faire un bon IDE.
4. Interruption du flot d'écriture. Si la completion est bien faite (hommage à ReSharper et InteliJ Idea), elle ne doit pas interrompre trop le flux d'ecoulement des doigts sur le clavier. Celle de Vim en est douloureuse, mais c'est un héritage à assumer.
:Man not an editor command. J'assume que tu parles de Man.vim. Tu savais qu'il existe ^K pour ça ? (EDIT: c'est pour un afichage en pop-up OK)À part ça, dans un gros ou moyen projet, le fait de ne pas pouvoir voir la doc autrement qu'avec ^], c'est souvent gênant. Et encore, il faut avoir généré le tagfile idoine, et qu'il soit dans le tagpath de vim.
Non. Il l'est dans ton cas. Les problèmes de
:makesont:1. Make est lent de base. Si ton projet est un peu gros et en C++, avec des templates, avec CXX=g++, tu as perdu.
2. Surtout si certains de tes fichiers sont générés par un soft externe (eg: flex, bison, swig, doxygen, script de rapatriement perso)
3.
:makemet vim en pause ! Tu ne peux pas travailler pendant que ça compile en background.4.
:makepour du C# ? Pour du Java ? Pour du Qt ?Bref, je m'arrête là. J'ai aussi une nette préférence pour Vim lorsque je code en C. Mais en C++ je sors KDevelop avant que les choses ne dégénèrent. ;)