J'utilise un IDE (Eclipse) pour développer des logiciels. Pourquoi devrais-je passer à vim ou emacs? [fermé]

Mon travail de jour est développeur Java / Web. J'utilise eclipse depuis environ 5 ans. Je pense que c'est excellent et j'utilise également Webstorm pour javascript et html / jsp.

J'ai parfois besoin de ssh sur le serveur et de jouer avec les fichiers de configuration; pour cela j'utilise vi et ça me fait mal. Je dois monter une page web listant la syntaxe / les commandes: appuyez sur échapper, puis sur astérisque, tournez-vous trois fois et le texte sera entré deux lignes au-dessus de votre curseur . C'est si peu intuitif pour moi, et j'imagine tous ceux qui ont grandi à la fin des années quatre-vingt.

Voici les principales raisons pour lesquelles je pense que l'éclipse est brillante (et je suppose que d'autres IDE), et ne passez pas à emacs et / ou vim.

• Erreur de mise en surbrillance sans besoin de recompiler le projet.
• Aide au code.
• Refactoring.
• Ouverture appel hiearchy / Déclaration d'ouverture.
• Entièrement intégré avec contrôle de source.
• Le débogueur est inclus.
• disponibilité de plugins tiers - par exemple findbugs / checkstyle.

L'un des arguments que j'entends est qu'avec emacs / vim, vous pouvez créer vos propres plugins - eh bien, mais vous pouvez aussi le faire dans eclipse. Mais vous n'en avez pas besoin car tout est déjà là! C'est comme dire d'acheter cette voiture à moitié construite, vous pouvez construire le reste vous-même.

Pourquoi les gens utilisent-ils emacs / vim? Les personnes qui l'utilisent travaillent-elles réellement sur des projets orientés objet complexes dans de grandes organisations?

Quelles sont les raisons de passer à vim / emacs. Comment ma productivité augmenterait-elle si je changeais?

Utilisez l'outil qui correspond à vos besoins. Connaître VIM ou Emacs est une bonne chose si vous devez vous connecter à un serveur distant et modifier un fichier de configuration ou quelque chose de similaire. Je connais assez bien VIM, mais je ne l'utiliserais pas pour développer en Java. C'est pour cela qu'Eclipse, Netbeans, etc. sont faits.

Emacs et Vi ont encore une place.

• Ils sont omniprésents dans les environnements Unix et Unix, et peuvent être installés sur la plupart des autres plates-formes populaires.

• Ils sont populaires et stables, donc les apprendre une fois est rentable à long terme.

• Ils s'exécutent sur un terminal texte, vous pouvez donc les utiliser dans des sessions telnet et ssh.

• Ils fournissent des modes d'édition et une coloration syntaxique pour une grande variété de langues, y compris des langues très nouvelles et très rares. (C'est l'un de mes avantages préférés.)

La clé pour comprendre ces programmes, cependant, est de savoir quels problèmes ils devaient à l'origine résoudre. Pour Vi, cela éditait des fichiers texte sur des connexions de terminaux aussi lents que 300 bauds. Dans cet environnement, vous ne voulez pas afficher les menus ou modifier radicalement le contenu de l'écran si vous pouvez l'éviter.

Emacs était destiné à être utilisé dans un environnement plus rapide. Sa force était qu'il pouvait être chargé une fois et ne jamais sortir. L'utilisateur pouvait accomplir toute autre tâche dont il avait besoin depuis Emacs sans quitter, et souvent de manière plus conviviale que s'il devait le faire à partir de la ligne de commande. Les gens n'avaient pas d'environnement de bureau graphique avec une fenêtre Emacs ouverte. Emacs permet à l'utilisateur d'accomplir presque toutes les tâches normales (et de nombreuses étranges) en quelques touches seulement. Tout ce qui n'est pas intégré peut être scripté.

De toute évidence, les besoins des gens ont beaucoup changé depuis le lancement de ces programmes, mais ils ont encore de réels atouts. J'ai appris les bases des deux et je les utilise chaque semaine. Pourtant, je pense que leurs forces sont souvent surestimées. Ils ont atteint un statut si légendaire que les gens n'admettent pas leurs faiblesses et ont plutôt tendance à penser qu'ils font quelque chose de mal si Emacs / Vi ne les rend pas plus productifs qu'Eclipse ou Visual Studio.

Maintenant au point.

Java est un langage populaire avec un excellent support dans Eclipse, et il y a de fortes chances que vous développiez du code sur un système d'exploitation moderne qui vous permet d'accomplir rapidement des tâches courantes et de scripter d'autres sans le faire via votre IDE. Je ne pense pas qu'il serait judicieux pour vous de changer.

J'utilise emacs depuis plus de 5 ans. Je ne peux plus vous dire les combinaisons de touches que j'utilise, mes doigts s'en souviennent et doivent regarder le clavier juste pour voir ce que mes mains tapent.

Il y a quelques années, j'ai commencé à utiliser Eclipse, et il n'y a aucune chance que je retourne librement à emacs. Désolé la mémoire musculaire, même si vous me manquez C-x r SPC 1, Eclipse me rend beaucoup plus productif et c'est ce qui compte.

Non, je ne pense pas que vous devriez changer , mais vous devriez consacrer quelques heures pour apprendre les bases de vim afin de ne plus avoir à le rechercher.

Pourquoi devrais-je passer à vim ou emacs?

Très probablement, vous ne devriez pas changer . Vim est un excellent éditeur de texte puissant, mais il ne remplace pas un IDE, et ne devrait pas l'être! Eclipse est très bon dans son sous-ensemble de choses spécifiques à l'EDI, et vim est très bon dans son sous-ensemble de choses spécifiques à l'édition de texte. Chacun a son propre objectif, différent.

Je sais qu'il existe des plugins qui étendent les fonctionnalités de vim afin qu'il puisse faire plusieurs des mêmes choses spécifiques à l'IDE qu'un IDE peut faire. Mais ce n'est toujours pas la principale force de Vim, et un IDE sera presque toujours en mesure de le faire mieux. Parce que c'est sur cela qu'ils se concentrent.

Ce que je fais dans mon travail quotidien, c'est d' utiliser à la fois Visual Studio et vim pour éditer C #. Cela fonctionne très bien pour moi, et je ne couperais jamais l'un d'eux pour compter exclusivement sur l'autre.

En ce qui concerne emacs, je ne suis pas un expert, mais je ne pense pas qu'il puisse rivaliser avec les fonctionnalités IDE d'Eclipse en ce qui concerne Java (veuillez me corriger si je me trompe). Si vous développez dans lisp, alors il peut certainement être considéré comme un excellent IDE, mais je ne pense pas qu'il ait le même support pour Java.

Donc, si vous voulez un éditeur de texte plus puissant à utiliser avec Eclipse, je vous recommanderais certainement d'apprendre vim ou emacs. Mais en complément, pas en remplacement . Cela peut vraiment être payant à long terme, même si aucun d'entre eux n'a une courbe d'apprentissage particulièrement facile:)

Voici une belle lecture longue sur les points forts de vim. Et voici une liste de quelques trucs sympas que vous pouvez faire.

En gros, lisez ceci (PDF) pour voir pourquoi Emacs est puissant. Une fois que vous connaissez Lisp, il est presque trivialement facile d'écrire des extensions pour celui-ci (j'ai plusieurs flux de travail et déploiements de contrôle de source scriptés via un module complémentaire que j'ai écrit pour moi-même appelé employer-mode). En ce qui concerne ce que vous énumérez ci-dessus;

• Erreur de mise en surbrillance sans besoin de recompiler le projet. Cela n'a pas de sens pour toutes les langues. Vous pouvez facilement y intégrer REPLsde nombreuses langues. En ce moment, je ruby, python, haskell, common lisp, schemeet erlangtout accroché dans emacs. Soit dit en passant, l'addon JavaScript js2-modea une "compilation" incrémentielle complète, donc il met en évidence des choses comme des erreurs de syntaxe pour vous, donc c'est certainement possible, mais pas la norme
• Aide au code. il y a un addon pour cela appelé autocomplete.el, je crois, consultez le wiki Emacs
• Refactoring. Je suppose que vous voulez dire "refactoring automatisé", ce qui n'a pas de sens dans toutes les langues. Existe probablement pour certains, mais je ne sais pas.
• Ouverture appel hiearchy / Déclaration d'ouverture.
• Entièrement intégré avec contrôle de source. Il a un git-modeintégré à partir d'Emacs 22.3, pas sûr des autres contrôles de source
• Le débogueur est inclus. Langue par langue ici. Généralement, s'il a une intégration REPL, il a aussi un débogueur Emacs, mais ce n'est pas universel
• disponibilité de plugins tiers - par exemple findbugs / checkstyle. je ne sais pas à propos de ceux-là, mais il y a beaucoup d'addons pour cela, du pourquoi-ce-n'est-pas-dans-la-base-package-utile, au tout à fait frivole

Cela dit, si vous n'aimez pas Lisp et que vous n'avez pas l'intention de l'apprendre, je ne peux honnêtement pas recommander Emacs. La victoire que vous en retirerez est d'apprendre à fabriquer des outils et d'appliquer ces principes pour augmenter votre propre productivité, sans obtenir un tas de mods standard et les enchaîner.

Je vois deux options ici:

• Utilisez Nano à la place - C'est exactement comme le Bloc-notes dans Windows pour Linux. Ne nécessitant aucune combinaison de raccourcis clavier, il vous suffit de taper nano somefile.confet vous avez un bel éditeur. Vous pouvez même ajouter une coloration syntaxique
• Gardez le programme localement et synchronisez-le sur SCP avec le serveur - je le fais quand j'ai besoin de travailler sur un petit site Web mais que je n'ai pas assez de ressources pour exécuter Apache localement. J'évoque simplement WinSCP, j'affiche les répertoires que je veux et j'utilise "Garder les fichiers distants à jour". Les changements se reflètent généralement en quelques secondes
• Utilisez un plugin dans votre éditeur / IDE pour travailler "directement" avec le fichier distant - Avant de me soucier du contrôle des révisions, j'ai simplement lancé Notepad ++ (mon éditeur préféré) et utilisé NppFTP pour travailler sur les fichiers. NppFTP est plus rapide que l'option WinSCP puisque Npp lui indique immédiatement quand un fichier est enregistré, qui est immédiatement téléchargé. Cependant, comme je l'ai dit, vous perdez le contrôle des révisions. Je suis sûr qu'il existe un plugin pour Eclipse que vous pouvez utiliser

J'espère que cela t'aides

Personnellement, j'aime Vim parce qu'il est extrêmement bon pour éditer du texte, c'est-à-dire très ergonomique (les raccourcis clavier ne me fatiguent pas tellement les mains et je n'ai pas besoin d'utiliser beaucoup la souris) et efficace à utiliser une fois que vous maîtrisez (ce qui prendra bien sûr du temps et de la patience, car ce n'est pas l'éditeur le plus intuitif pour les débutants).

Je préférerais cependant Eclipse pour le développement Java à grande échelle en raison des nombreuses fonctionnalités qui sont facilement disponibles. Bien sûr, certains plugins peuvent rendre Eclipse un peu plus tolérable.

Si vous êtes satisfait d'Eclipse, alors ne changez pas.

Si vous pouvez utiliser Eclipse partout où vous en avez besoin, ne changez pas.

Si votre projet / entreprise utilise à peu près exclusivement Eclipse, ne changez pas.

Si vous n'avez que rarement besoin d'autre chose, imprimez une feuille de triche pour l'un des éditeurs et sortez-la du tiroir lorsque vous en avez besoin, puis recommencez à utiliser Eclipse.

Voir la (même) question sur SO: /programming/1346820/what-are-the-efficiences-afforded-by-emacs-or-vim-vs-eclipse

En ce qui concerne la réponse, "les personnes qui l'utilisent travaillent-elles réellement sur des projets orientés objet complexes dans de grandes organisations?" - Accroche-toi à ton chapeau, mais la réponse est "oui". J'ai travaillé sur des projets avec des dizaines de millions de lignes de code utilisées dans le chemin critique de la conception du processeur même exécutant l'ordinateur que vous utilisez pour poser cette question. Et les gens ont essayé Eclipse mais l'ont trouvé trop lent et maladroit (bien que, certes, nous n'utilisions pas Java).

Emacs et vim sont des éditeurs très configurables et puissants, et les deux offrent de gros gains de productivité une fois les concepts de base maîtrisés.

Vi gagne avec ce qui sont essentiellement des opérations basées sur des ensembles. Par exemple, changer toutes les instances de "foo" en "bar" dans une définition de classe est une ligne unique.

Emacs est tout aussi puissant, mais vous devez apprendre Emacs Lisp pour l'utiliser à son plein potentiel.

Dans les deux cas, cela ne vaut la peine de changer que si vous prévoyez d'utiliser emacs ou vi pour tout .

Le meilleur outil (à court terme) est celui avec lequel vous êtes très compétent.

Les gens utilisent une technologie de plus de 30 ans parce qu'ils sont très compétents avec elle. Ils ont construit leur flux de travail et leurs habitudes autour de ces outils. Si vous êtes plus familier avec un IDE moderne comme Eclipse, il n'y a pas beaucoup de raisons de changer. Apprendre à utiliser Eclipse plus efficacement est un meilleur investissement de votre temps (par exemple, utilisez Mylyn ).

J'essaie actuellement de passer de NetBeans à vim. L'apprentissage de vim prend du temps et de la pratique, mais je vois ses avantages par rapport à, appelons-les, "éditeurs GUI" pour certains cas.

Mais, contrairement à vous, je code principalement Ruby, et je n'ai pas besoin de toute la magie noire génératrice de code, à auto-complétion, refactor-my-code que NetBeans et Eclipse offrent. Si je codais Java ou C #, je n'essaierais certainement pas de changer du tout.

En tant qu'utilisateur de longue date d'emacs, je trouve qu'emacs est assez confortable comme environnement d'édition et de développement (et dans une certaine mesure, il s'intègre également au processus de construction, au contrôle de version, à la recherche contextuelle rapide et autres, donc je suppose que cela se qualifie comme un "IDE").

Je suis également vraiment à l'aise avec l'utilisation d'éditeurs vi et similaires (j'ai commencé à utiliser ed, car je pensais qu'emacs était trop complexe; rétrospectivement, c'est à l'envers, mais cela m'a donné une base solide pour l'apprentissage futur de vi). J'utilise vi principalement pour les "petites modifications rapides", principalement sur les machines distantes où emacs n'est pas installé.

Pour votre "Je dois occasionnellement faire ssh sur le serveur et jouer avec les fichiers de configuration; pour cela j'utilise vi" scénario, je recommanderais un petit ensemble de commandes et quelques réflexions générales autour de vi:

• Vi n'est pas modal, il a des commandes "a" (ajouter), "A" (ajouter à la fin de la ligne), "i" (insérer) et "I" (insérer au début de la ligne), prenant le texte à insérer comme argument et signalant "fin de commande" avec Esc
• h, j, k et l sont des touches de mouvement. Cela PEUT fonctionner en utilisant les touches fléchées, mais comme la séquence typique de style VT "Je suis une touche fléchée" commence par Esc, cela interrompra la commande d'insertion de texte à laquelle vous ne pensez pas.
• : le linum vous déplace vers le linum , la ligne 1 est la ligne la plus haute et la ligne $ est la plus basse
• . est la commande "répéter la dernière commande" (voir la première puce)

Cela ne devrait pas prendre plus d'une heure ou deux pour jouer avec vi pour être au "Je peux éditer un fichier texte en toute confiance, mais je ne suis peut-être pas efficace avec ça" et c'est aussi bien que vous devrez probablement l'être . À défaut, tout éditeur qui ne se trompe pas sur la conversion automatique entre les tabulations et les espaces devrait être "assez bon" pour vos besoins. Si Eclipse est installé sur tous vos serveurs distants, je ne vois pas vraiment comment utiliser cela comme un gros problème.

Je suis vraiment un gars Emacs. Je l'utilise pour toute ma programmation et j'encourage activement mes collègues à l'utiliser également (et ils m'ignorent activement). Je le trouve beaucoup plus productif que n'importe quel IDE, et je ne changerais jamais.

Sauf si j'écris Java ou C # (et j'imagine qu'il y a d'autres langages dans cette catégorie). Ils ont de si grandes bibliothèques de choses avec des noms longs, que les gains que j'obtiens en utilisant Emacs sont complètement perdus en essayant de se souvenir de tout.

Je vous encourage certainement à essayer vim et / ou Emacs. Mais vous allez probablement vous retrouver dans Eclipse pour Java.

Je n'ai aucun problème avec les différents éditeurs UNIX disponibles, mais je ne les utilise que sous protestation. Pas, comme je l'ai dit, parce que j'ai un problème avec eux, mais parce que si je dois les utiliser, cela signifie que notre processus de déploiement fait défaut.

Cela mérite probablement un peu plus de contexte: je travaille sur des solutions de commerce électronique à grande échelle, tout ce qui régit le fonctionnement de nos systèmes est généré par un processus de construction / déploiement en un clic. Nous avons un éventail d'environnements de test, donc à tout moment, je peux apporter une modification via Eclipse, le vérifier dans les CV et déclencher une construction / déploiement pour prouver que ma correction a fonctionné. Donc, si je pirate dans 'vi', c'est parce que nous ne pouvons pas attendre le délai d'une heure d'un déploiement ou parce que le déploiement ne couvre pas les fichiers que je modifie et doit être étendu pour le faire donc (sinon je piraterai vi la prochaine fois que le fichier en question devra être changé).

Personnellement, les deux programmes me poussent vers le haut du mur. Le problème avec Eclipse est que c'est lent comme morve lorsque vous travaillez sur un grand projet et que c'est quand il ne fait pas d '«indexation DGLP» ou autre. vous souhaitez actualiser votre référentiel? obtenu 15 minutes? Oh et que diriez-vous de cette astuce astucieuse où vous Ctrl-C du texte puis Ctrl-P quelque part, mais au lieu d'aller là où vous le vouliez, il ouvre un fichier complètement différent et passe sur autre chose et vous vous demandez si wtf était là en premier lieu. Oh et ai-je mentionné de travailler avec eclipse sur un grand projet sur un VPN? pratiquement impossible.

Quant à vim, c'est agréable et rapide en supposant que vous connaissez la multitude de combinaisons de touches complètement insensées pour lui faire faire quelque chose et bonne chance si vous vous trouvez dans un mode inconnu par accident. De plus, avec vim, vous devez à peu près connaître la structure complète de votre répertoire de projets dans votre tête afin d'ouvrir les fichiers appropriés. Le principal avantage de Vim est qu'en théorie, vous pouvez créer du code plus rapidement car ce sont toutes les clés, mais en réalité, peu m'importe la quantité de texte que j'écris, ce n'est pas le volume de texte qui importe, c'est la qualité du code et souvent la qualité le code nécessite de regarder des dizaines de fichiers pendant des heures jusqu'à ce que vous trouviez la bonne chose à taper (ce qui est généralement très court).

Ce que je souhaite, c'est que quelqu'un écrive un programme en ligne de commande, comme vim, qui a en fait une structure de répertoires comme eclipse sur le côté ou quelque chose que vous pourriez développer / réduire et ouvrir des fichiers. Quelqu'un sait-il quelque chose comme ça?

Si vous n'êtes pas satisfait de VIM ou EMACS, vous pouvez rechercher sur cette machine d'autres éditeurs de texte. Il peut y avoir une saveur de nedit ou gedit ou quelque chose que vous pouvez utiliser qui aura des commandes plus familières (ctrl x, c, v et s font ce que vous attendez par exemple).

Vous avez probablement plus de deux choix sur votre distribution, ça vaut le coup d'y jeter un œil.