J'ai l'impression que ça ne dépend que de la philosophie du projet. Vim est avant tout un éditeur de texte, et pas un IDE. S'il faut parser 100k lignes de code pour mettre des couleurs sur une fonction de 3 lignes (et ça va être le cas, si tu as quelques include standard), alors tu vas le payer en terme de réactivité et de légèreté.
En ce qui me concerne, j'ai toujours utilisé un éditeur de texte léger et des terminaux pour coder, parce que j'ai l'impression que les IDE me font perdre plus de temps qu'ils m'en font gagner (mais bien sûr, c'est complètement personnel, et ça ne marche que sur les petits projets). Si la coloration syntaxique n'est pas instantanée (par exemple, s'il faut 1/2 s pour vérifier si A est un type ou une variable), alors on aura commencé à taper la suite avant de s'apercevoir qu'on a fait une erreur. On perd toute la légèreté et la réactivité de l'interface.
Du coup, si j'étais Monsieur Vim, je me contenterais d'une analyse locale au fichier, en utilisant une heuristique naïve. C'est le genre d'heuristiques sur lesquelles les compilateurs se basent pour émettre des warnings (par exemple sur if (A = B) ).
Sur le fond, c'est quand même vraiment bizarre que C ou C++ sont assez ambigüs pour ne pas être capables de déterminer si une ligne est une déclaration ou une instruction à exécuter sans avoir besoin de la totalité du contexte. Je comprends bien que c'est pour des raisons historiques et pragmatiques, mais quand on en est là, on peut quand même se poser des questions sur la cohérence du langage. Je ne pense pas que ça soit le job des éditeurs de texte de pallier les problèmes profonds des langages; quand la coloration syntaxique n'est pas possible, bah elle n'est pas possible, et puis c'est tout. C'est un peu comme si un langage permettait de lire le caractère qui indique un commentaire dans une variables globale ou un truc chelou comme ça; au bout d'un moment, il y a des choses qu'un éditeur de texte ne peut pas vraiment faire;
[^] # Re: up
Posté par arnaudus . En réponse au journal Amélioration de la coloration syntaxique C dans vim. Évalué à 6.
J'ai l'impression que ça ne dépend que de la philosophie du projet. Vim est avant tout un éditeur de texte, et pas un IDE. S'il faut parser 100k lignes de code pour mettre des couleurs sur une fonction de 3 lignes (et ça va être le cas, si tu as quelques include standard), alors tu vas le payer en terme de réactivité et de légèreté.
En ce qui me concerne, j'ai toujours utilisé un éditeur de texte léger et des terminaux pour coder, parce que j'ai l'impression que les IDE me font perdre plus de temps qu'ils m'en font gagner (mais bien sûr, c'est complètement personnel, et ça ne marche que sur les petits projets). Si la coloration syntaxique n'est pas instantanée (par exemple, s'il faut 1/2 s pour vérifier si A est un type ou une variable), alors on aura commencé à taper la suite avant de s'apercevoir qu'on a fait une erreur. On perd toute la légèreté et la réactivité de l'interface.
Du coup, si j'étais Monsieur Vim, je me contenterais d'une analyse locale au fichier, en utilisant une heuristique naïve. C'est le genre d'heuristiques sur lesquelles les compilateurs se basent pour émettre des warnings (par exemple sur if (A = B) ).
Sur le fond, c'est quand même vraiment bizarre que C ou C++ sont assez ambigüs pour ne pas être capables de déterminer si une ligne est une déclaration ou une instruction à exécuter sans avoir besoin de la totalité du contexte. Je comprends bien que c'est pour des raisons historiques et pragmatiques, mais quand on en est là, on peut quand même se poser des questions sur la cohérence du langage. Je ne pense pas que ça soit le job des éditeurs de texte de pallier les problèmes profonds des langages; quand la coloration syntaxique n'est pas possible, bah elle n'est pas possible, et puis c'est tout. C'est un peu comme si un langage permettait de lire le caractère qui indique un commentaire dans une variables globale ou un truc chelou comme ça; au bout d'un moment, il y a des choses qu'un éditeur de texte ne peut pas vraiment faire;