Discussion :

[MaximeCh]

Une video que tout utilisateur de vim devrait voir!

[calvaire]

Une video que tout utilisateur de vim devrait voir!

+1
merci pour la video

[xXxNeWgEnErAtIoN]

Vim c'est vraiment pas top, ça vaut pas nano

[Meseira]

Vim c'est vraiment pas top, ça vaut pas nano

Excellent, un troll vim/nano, ça change de l'éternel vim/emacs

[Steinvikel]

Nano, c'est bien quand tu ne connais pas vim. Vim, c'est bien tout court.

[Sodium]

Sinon un vrai IDE c'est bien aussi

[Markand]

Sinon un vrai IDE c'est bien aussi

Commentaire probable d'une personne n'ayant jamais utilisé vim (ou ne connait que :w et :q). Ah ! je me demande pourquoi autant d'IDE proposent une émulation vim (VS, Qt Creator, VS Code) s'il est tellement mauvais cet éditeur de texte.

[bbalet]

La seule chose de sensée à faire quand vi(m) s'ouvre c'est la séquence ESC : q !

[Sodium]

Commentaire probable d'une personne n'ayant jamais utilisé vim (ou ne connait que :w et :q). Ah ! je me demande pourquoi autant d'IDE proposent une émulation vim (VS, Qt Creator, VS Code) s'il est tellement mauvais cet éditeur de texte.

Je vais répondre très simplement à ta question du pourquoi : parce que les développeurs n'aiment pas changer leurs habitudes.

Pour moi c'est assez simple, quand un développeur a besoin de VIM pour être efficace, c'est qu'il passe plus de temps à pisser du code qu'à réfléchir à comment le structurer efficace. VIM et autres encouragent les mauvaises pratiques de programmation, faire des fichiers énormes, des fonctions longues. Les outils doivent s'adapter à une bonne façon de travailler et non l'inverse.

[Invité]

Pour moi c'est assez simple, quand un développeur a besoin de VIM pour être efficace, c'est qu'il passe plus de temps à pisser du code qu'à réfléchir à comment le structurer efficace. VIM et autres encouragent les mauvaises pratiques de programmation, faire des fichiers énormes, des fonctions longues. Les outils doivent s'adapter à une bonne façon de travailler et non l'inverse.

Mais oui, bien-sûr. D'ailleurs, dans les IDE, il n'y a pas d'outils de navigation de code, de refactoring et de debugging : l'utilisateur réfléchit tellement bien à sa structure de code que ces outils sont complètement inutiles.

[Sodium]

Je ne vois pas bien le rapport entre ton argument et le miens en fait.

[Invité]

Le rapport c'est que les IDE incitent plus au pissage de code que les éditeurs. Qui n'a jamais commencé à coder une classe trop rapidement en se disant "au pire on peut refactorer en quelques clics", et puis au final, il a fallu plus que quelques clics...
Par contre, les éditeurs qui encouragent les fichiers énormes et les fonctions longues, là je vois vraiment pas le rapport.

[Sodium]

Le rapport c'est que les IDE incitent plus au pissage de code que les éditeurs. Qui n'a jamais commencé à coder une classe trop rapidement en se disant "au pire on peut refactorer en quelques clics", et puis au final, il a fallu plus que quelques clics...

Donc parce que certains ont ces mauvaises pratiques (et encore, je ne l'ai jamais observé moi-même), il faudrait mettre tout le monde sur des outils préhistoriques.

Par contre, les éditeurs qui encouragent les fichiers énormes et les fonctions longues, là je vois vraiment pas le rapport.

Travailler sur code bien séparé en VIM est chiant. Naviguer entre les fichiers est chiant, chercher une fonction est chiant. Ca pousse les pisseurs de codes à tout rassembler en un seul endroit et à pondre des horreurs qu'ils seront les seuls à comprendre.

[Luc Hermitte]

Travailler sur code bien séparé en VIM est chiant. Naviguer entre les fichiers est chiant, chercher une fonction est chiant. Ca pousse les pisseurs de codes à tout rassembler en un seul endroit et à pondre des horreurs qu'ils seront les seuls à comprendre.

Hum... On ne doit pas utiliser le même outil car la navigation via les tags, ou via des solutions plus avancées aujourd'hui (merci le Language Server Protocol) n'est vraiment pas complexe.
Quant à naviguer dans les fichiers, c'est tellement plus simple avec la complétion sur le nom du fichier plutôt que sa recherche dans un arbre...

Après, je fais parti des qui considèrent que dans la mesure où vim intègre l'appel au compilateur nativement, c'est un environnement de développement intégré. Probablement parce que j'ai connu les premiers "IDE" qui faisaient guère plus. Après, c'est sans compter les plugins et l'évolution de l'outil.

La vraie difficulté, c'est le fait qu'il soit modal, et qu'il faille apprendre à s'en servir sans être assisté par une souris. Et après nombre d'intégristes veulent le limiter à 0-plugins, pas d'utilisation hors console/tmux, pas de touche de curseur...

[disedorgue]

Travailler sur code bien séparé en VIM est chiant. Naviguer entre les fichiers est chiant, chercher une fonction est chiant. Ca pousse les pisseurs de codes à tout rassembler en un seul endroit et à pondre des horreurs qu'ils seront les seuls à comprendre.

Euh, non, vim fait très bien ce que tu lui reproches, ce que l'on peut considéré comme chiant avec vim, c'est ça configuration, mais en même temps, ça fait parti de l'apprentissage...

[Invité]

Travailler sur code bien séparé en VIM est chiant. Naviguer entre les fichiers est chiant, chercher une fonction est chiant. Ca pousse les pisseurs de codes à tout rassembler en un seul endroit et à pondre des horreurs qu'ils seront les seuls à comprendre.

Je confirme les propos de Luc Hermitte et disedorgue : c'est du grand n'importe quoi. Si tu ne connais rien à un sujet, ne te force pas à le commenter quand même. Ou alors, va plutôt chier sur Visual Studio Code, il y a une news récente sur laquelle tu pourras troller : https://www.developpez.net/forums/d1.../#post11278365

[Sodium]

Autre problème avec les amateurs de VIM, ses défenseurs ont systématiquement une position dogmatique, rendant la discussion difficile

Ce que vous décrivez ne fait absolument pas de VIM un bon IDE, ça permet juste de pisser du code plus vite, et probablement encore plus mal.

[Luc Hermitte]

Autre problème avec les amateurs de VIM, ses défenseurs ont systématiquement une position dogmatique, rendant la discussion difficile

Ce que vous décrivez ne fait absolument pas de VIM un bon IDE, ça permet juste de pisser du code plus vite, et probablement encore plus mal.

Pourtant, nous avançons des réponses à tes critiques, et tu adresses pas ce qui ne te convient pas dans les réponses. Une position dogmatique est généralement c'est celle qui est tranchée et qui refuse la discussion, non? Ceci dit, au moins avec toi chose que j'apprécie, il y a un début de discussion (on ne pouvait pas en dire autant de précédents messages qui méritaient, eux, leurs -1).

Les deux critiques que tu as adressées sont : "Naviguer entre les fichiers est chiant, chercher une fonction est chiant"

Ce à toi je t'ai répondu que contrairement à ce que tu sembles penser c'est très simple. Avec "gd" je vais à la définition du machin sous le curseur, et grâce aux plugins s'occupant de l'interfaçage avec des serveurs LSP ça marche même entre fichiers différents, même quand il y a des surcharges au milieu. C'est tout l'intérêt de ce protocole: offrir à tous les outils les mêmes capacités de navigation, indexation, refactorisation...

Les hics:
- ça ne se fait pas avec clic-droit souris, mais avec g(oto)d(efinition)
- ca demande plus de boulot de configuration qu'avec les autres outils, et je l'admets volontiers, c'est vite la plaie.

Quant à la navigation dans les fichiers, il y a des plugins (et même un natif moyennement ergonomique) qui rajoutent des arbres & cie. Mais la mode chez nous, c'est les fuzzyfinders: on tape un morceau des noms des fichiers (et éventuellement des répertoires qui y conduisent), et pouf, on va dans le bon fichier. Je trouve ça bien plus efficace que de se perdre dans des arborescences vite complexes. Mais, c'est vrai, il faut une fois encore installer des plugins, ou taper des '*' entre deux morceaux de nom de fichiers.

Relativement à ces critiques précises, je considère que tu ne connais pas/mal l'outil.

Tu aurais d'autres critiques aussi précises qui font que pour toi ce n'est pas adapté pour concevoir? (j'accepte tout de suite ce que n'est pas un case tool qui offre des diagrammes de classes, génère du code à partir d'eux... Tout comme beaucoup d'IDE ceci étant)

PS: Pour ce qui est de mal pisser du code, mes wizards pour le C++ connaissent les règles qualités modernes et sont orientés sémantiques, nous sommes très loin des templates/wizards que l'on trouve dans les autres IDE qui proposent allègrement copie et destructeurs virtuels sans sourciller (oui c'est mal, cf la FAQ), ou qui font croire que tout attribut doit avoir une paire setter/getter (oui, je pense à toi eclipse).

[disedorgue]

Autre problème avec les amateurs de VIM, ses défenseurs ont systématiquement une position dogmatique, rendant la discussion difficile

Tout comme ces pourfendeurs

Ce que vous décrivez ne fait absolument pas de VIM un bon IDE, ça permet juste de pisser du code plus vite, et probablement encore plus mal.

Dans les faits, ici tu es en train de dire que tu pisses du mauvais code, puisque nous n'avons fait que te rétorquer que vim était capable de faire ce que tu lui reprochais de ne pas savoir faire

[Invité]

Ce que vous décrivez ne fait absolument pas de VIM un bon IDE, ça permet juste de pisser du code plus vite, et probablement encore plus mal.

Pourquoi tu nous parles d'IDE ? Vim ne prétend pas être un IDE ni avoir ses usages (pas de base du moins). Et ton analyse sur vim qui permet de coder plus mal, tu l'as eu en grattant un ticket au PMU du coin ?

Autre problème avec les amateurs de VIM, ses défenseurs ont systématiquement une position dogmatique, rendant la discussion difficile

De quelle discussion parles-tu ? Tu as commencé par chier sur vim en balançant un HS sur les IDE puis des pseudo-arguments complètement faux. Quant à la position dogmatique, tu veux peut-être qu'on parle de JavaScript ?