C’est au contraire une excellente raison pour préférer Emacs… 
C’est au contraire une excellente raison pour préférer Emacs… [/quote]
L’utilisation d’un langage plus complet que le vim-script c’est cool, qu’il soit fonctionnel c’est classe. Mais s’il y a un langage à pleurer c’est le lisp (son concepteur lui même avait émis des critiques importantes à son égard).
C’est moins intégré, mais je crois que vim peut s’interfacer avec du python. (EDIT : voila par exemple : chl.be/glmf/kafka.fr.free.fr/art … ython.html)
Oui c’est vrai que c’est particulier comme langage (((1) 2) 3) faut être vigilant, j’suis pas au bout de mes peines 
, dire que j’avais prévu 15 jours pour dégrossir la bête…
Là tu ne parle que de sa syntaxe, il a d’autres trucs amusant :
[ul]
[li]tu écris une fonction nommée A[/li]
[li]tu écris une fonction nommée B qui utilise A[/li]
[li]tu écris une autre fonction nommée A[/li]
[li]tu utilise B[/li][/ul]
Quel méthode va être utilisée par B ? 
Non, tu redéfinis la fonction A (ou, dit autrement, tu assignes une nouvelle fonction au symbole A, sachant que B fait référence au symbole et non pas à la fonction d’origine). Je ne vois pas où est le problème… D’ailleurs les implémentations correctes te renvoient un warning quand tu redéfinis A, histoire que tu n’oublies pas que c’est une redéfinition.
Non, tu redéfinis la fonction A (ou, dit autrement, tu assignes une nouvelle fonction au symbole A, sachant que B fait référence au symbole et non pas à la fonction d’origine). Je ne vois pas où est le problème… D’ailleurs les implémentations correctes te renvoient un warning quand tu redéfinis A, histoire que tu n’oublies pas que c’est une redéfinition.[/quote]
La gestion du contexte est dynamique. C’est beau en théorie et très casse gueule en pratique. Je ne sais plus comment se comporte le C et le C++ quand tu fais ce genre de chose au sein d’une même unité de compilation, mais dès que tu sort de l’unité de compilation pour utiliser l’autre méthode tu doit le faire exprès. Ce genre de comportement ça entraîne de gros effets de bord (ce que typiquement les langages fonctionnels tentent d’éviter).
Le fonctionnement serait un peu plus propre avec des packages ou des espaces de nom, mais en l’état je trouve ça rédhibitoire.
Donc, si je suis bien votre raisonnement, lorsque tu écrit une fonction, tu dois impérativement renommé suivant un ordre prédéfinie au préalable dans ce cas d’étude A (1° fonction) / B (utilise A) | écriture d’une nouvelle fonction Aa ou A2 ou C.
Question : C’est raccourci, ou il existe plus propre ?
Tu peut avoir plusieurs fonctions de même nom mais de profil différent.
Les packages et namespace sont à peu près ça (pour simplifier), ta fonction s’appelle stringUtil.concat() ou stringUtil::concat().
[quote=“MisterFreez”]
Tu peut avoir plusieurs fonctions de même nom mais de profil différent.
Les packages et namespace sont à peu près ça (pour simplifier), ta fonction s’appelle stringUtil.concat() ou stringUtil::concat().[/quote]
Ok, merci pour ce renseignement, je vais creuser ça
Emacs par habitude je suppose, couplé à awesome et zsh on s’en passe plus.
Après c’est une histoire de goût faut essayer, sinon y a notepad aussi 
[quote=“MisterFreez”]La gestion du contexte est dynamique. C’est beau en théorie et très casse gueule en pratique. Je ne sais plus comment se comporte le C et le C++ quand tu fais ce genre de chose au sein d’une même unité de compilation, mais dès que tu sort de l’unité de compilation pour utiliser l’autre méthode tu doit le faire exprès. Ce genre de comportement ça entraîne de gros effets de bord (ce que typiquement les langages fonctionnels tentent d’éviter).
Le fonctionnement serait un peu plus propre avec des packages ou des espaces de nom, mais en l’état je trouve ça rédhibitoire.[/quote]
Bon déjà il y a des packages en Common Lisp. Ensuite, je ne vois pas vraiment de quoi tu parles quand tu mentionnes la “gestion de contexte dynamique”, le seul truc qui pourrait vaguement correspondre c’est les multimethods. Peux-tu expliciter stp (quitte à séparer les sujets pour éviter de trop continuer à polluer ici) ?
[quote=“MisterFreez”]Tu peut avoir plusieurs fonctions de même nom mais de profil différent.
Les packages et namespace sont à peu près ça (pour simplifier), ta fonction s’appelle stringUtil.concat() ou stringUtil::concat().[/quote]
Dans ce cas il s’agit bien de multimethods déclarées avec defmethod, qui correspondent à l’overloading en C++ et dont les règles de résolution sont tout à fait claires (et dont l’utilisation se limite généralement à la programmation objet). Pour les fonctions classiques définies avec defun (qui partagent d’ailleurs le même espace de nom que les multimethods, ce qui veut dire qu’une multimethod ne peut pas entrer en collision avec une fonction) c’est comme je l’ai dit précédemment : quand tu redéfinis la fonction ça remplace l’ancienne, point barre.
Et Vim peut s’interfacer avec Perl comme pour PYthon??
Oh un mainteneur de vim sous debian a change d’avis:
http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/
http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/
Ce n’est pas récent, ses posts date de 2008 
Mais bon au final il préfère Emacs …
C’est assez intéressant même si la plupart de ces points soit ne m’intéressement pas (savoir qu’emacs utilise GTK+ je m’en fou) soit je les connais et ça ne me pose pas de problème (le debugage bien plus efficace si on utilise emacs avec gdb).