Quels gains de productivité spécifiques Vim / Emacs offrent-ils par rapport aux éditeurs de texte GUI?

Ce n'est pas un troll ou un appât à flammes ou quelque chose comme ça. J'utilise Vim comme éditeur de console de choix depuis quelques mois maintenant (pour éditer des fichiers de configuration dans mon terminal), mais je ne pense pas que je pourrais le supporter pour mon travail quotidien normal d'écriture d'applications Web , ce que je fais avec un éditeur de texte GUI (lequel n'est pas important).

J'ai l'impression que mon éditeur de texte GUI peut faire tout ce dont j'ai besoin pour mon travail. Il a une recherche / remplacement décent avec des historiques auto-complets pour les deux. Il a la coloration syntaxique, la numérotation des lignes, une interface à onglets, un copier-coller facile, etc.

Compte tenu de ce que je viens de dire, quels sont les avantages de productivité de Vim (ou même d'Emacs) par rapport à un éditeur de texte GUI mis à part le fait qu'il est installé sur chaque ordinateur. Je voudrais des tâches spécifiques qui sont meilleures / plus rapides sur Vim / Emacs ou qui ne sont tout simplement pas possibles avec les éditeurs de texte GUI existants.

Pour Vim:

• Vim a une meilleure intégration avec d'autres outils (commandes shell, scripts, compilateurs, systèmes de contrôle de version, ctags, etc.) que la plupart des éditeurs. Même quelque chose de simple comme :.!diriger la sortie d'une commande dans un tampon, est quelque chose que vous ne trouverez pas dans la plupart des éditeurs d'interface graphique.

• Une interface à onglets n'est pas aussi agréable que l'interface "fenêtrée" que Vim / Emacs vous donne. Vous pouvez voir deux fichiers ou plus en même temps côte à côte. Plus vous pouvez voir à l'écran, plus vous libérez votre esprit pour réfléchir à votre problème plutôt que de faire la comptabilité mentale des noms de variables et des signatures de fonctions.

• Ne sous-estimez pas la puissance des expressions régulières Vim. Il existe de nombreuses extensions spécifiques à Vim pour correspondre à une colonne spécifique, une marque, la position du curseur, certaines classes de caractères (mots-clés, identifiants) etc.

• Intégré diffet grep(indépendant de la plate-forme, vous n'avez donc pas besoin de télécharger et d'apprendre un nouvel outil à chaque fois que vous changez d'ordinateur).

• Le mode bloc visuel (pour éditer les colonnes) est quelque chose qui manque à de nombreux éditeurs, mais dont je ne peux pas me passer. J'ai choqué et impressionné les gens au travail en utilisant juste cela, en faisant quelques modifications en quelques pressions de touches que quelqu'un aurait autrement passé dix minutes à faire manuellement.

• Plusieurs registres copier / coller. Quand vous n'en avez qu'un, vous finissez par subir d'étranges contorsions pour ne pas écraser le presse-papiers. Vous ne devriez pas avoir à le faire.

• Le système d'annulation / restauration de Vim est imbattable. Tapez quelque chose, annulez, tapez quelque chose d'autre, et vous pouvez toujours récupérer la première chose que vous avez tapée car Vim utilise une arborescence d'annulation plutôt qu'une pile. Dans presque tous les autres programmes, l'historique de la première chose que vous avez tapée est perdu dans cette circonstance.

• Se déplacer, copier, coller et supprimer du texte est incroyablement rapide dans Vim. Les commandes sont simples, uniques et composables. Additionnez toutes les fois où vous effectuez un surlignage de la souris minutieux et laborieux et Ctrl-X, puis remplacez-les toutes par un da((supprimez un ensemble de parenthèses correspondantes et tout ce qu'elles contiennent). Cela fait gagner plus de temps que vous ne le pensez

• Les petites choses, comme *rechercher le mot sous le curseur, ou .répéter une commande, ou %rebondir entre un paren d'ouverture et de fermeture. Beaucoup trop de ceux-ci pour les énumérer.

• Langage de script intégré et puissante capacité de mappage de touches et de macros pour que l'éditeur puisse être étendu de toutes les manières dont vous avez besoin. Des tonnes de scripts déjà écrits et téléchargeables.

Si vous regardez de près, vous constaterez que même les fonctionnalités que d'autres éditeurs ont également, Vim fait souvent mieux. Tous les éditeurs ont une coloration syntaxique, mais Vim a un fichier de syntaxe pour presque tous les formats de fichiers sous le soleil, souvent avec de nombreuses options de configuration, et il est très simple d'écrire le vôtre. De nombreux éditeurs gèrent différents encodages de fichiers, mais Vim vous offre des moyens très spécifiques et infaillibles de définir les encodages de fichiers et de les convertir entre eux. La toute première chose qui m'a impressionné à propos de Vim est la façon dont il gère parfaitement les options d'indentation tab / espace et les sauts de ligne Unix / DOS par rapport aux autres éditeurs avec lesquels j'avais des problèmes à l'époque.

Beaucoup de ces points s'appliquent également à Emacs (de manière différente mais généralement tout aussi puissante).

(vim est mon poison; je suis sûr qu'emacs offre des gains similaires)

Le plus gros gain: pas besoin de toucher la souris.

Pour moi, la chose la plus pratique est de sauter vers l'avant (ou juste avant) une lettre ou une combinaison de lettres spécifique, ou de revenir en arrière, en quelques frappes. Sauter en avant par la même condition deux ou dix fois, c'est simplement une question de préfixer avec un nombre.

Si vous devez répéter une modification, vous sautez à cet endroit (2-3 touches), puis appuyez sur "." pour répéter la dernière modification. Sauter en avant (ou en arrière) est plus facile - une seule touche - si c'est la même condition de recherche.

Fondamentalement, avec un petit délai, vous pouvez apprendre dix ou vingt raccourcis clavier, ce qui signifie que vous n'avez pas à continuer à déplacer votre main pour saisir la souris. Cela vous donne trois ou quatre fois plus de mouvements / commandes d'édition que si vous deviez continuer à saisir la souris.

Après quelques jours, vous vous retrouverez grognon à chaque fois que vous devez atteindre la souris (ou appuyer <Down>15 fois), lorsque vous êtes dans un éditeur d'interface graphique.

Je me suis toujours demandé pourquoi peu de gens étaient gaga sur Vim. Voir la vidéo de Vim Power User en action:

https://www.youtube.com/watch?v=FcpQ7koECgk

Si votre éditeur actuel peut faire ce qu'il fait, il n'est pas nécessaire de changer! :)

Lisez également ceci http://www.viemu.com/a-why-vi-vim.html

Après avoir regardé la vidéo et lu cet article, je n'ai eu d'autre choix que de commencer à apprendre le VIM. Cela fait presque un an que je suis passé au VIM et je ne peux pas imaginer utiliser autre chose.

Je pense que l'un des véritables pouvoirs d'un éditeur de texte dédié est l'édition de macros. La répétition est douloureuse pour beaucoup de programmeurs, et écrire des macros appropriées peut être à la limite du divertissement. Si vous ne faites pas tout via le clavier, la création de macros nécessitera un ensemble supplémentaire de commandes plutôt que d'utiliser celles que vous utilisez déjà.

Je suis semi-compétent avec les raccourcis clavier vi, mais je préfère Emacs dans son ensemble. La raison pour laquelle ces éditeurs ont des adeptes aussi fervents est que le modèle d'édition qu'ils fournissent est plus puissant que les systèmes plus récents, c'est pourquoi fournir des "vi keybindings" ou "emacs keybindings" ne suffit pas, même si vous n'utilisez aucune fonctionnalité d'extension ou des personnalisations pour emacs ou vi.

Je ne parlerai du modèle d'Emacs que parce que je le comprends le mieux. Le modèle courant d'édition de texte aujourd'hui implique un tampon de texte, dans lequel le texte peut être inséré, supprimé, sélectionné et coupé / copié / collé dans le presse-papiers du système.

Les tampons Emacs, bien sûr, peuvent prendre en charge ces opérations. En plus de suivre la position du curseur pour chaque fenêtre dans laquelle ils sont visibles, ils gardent également une trace des «marques» qui y sont faites. Le texte entre le "point" (position du curseur) et la "marque" est appelé la "région" et correspond à peu près à la sélection dans les éditeurs traditionnels.

La différence est qu'Emacs garde la trace des derniers emplacements où la marque a été placée dans l'anneau de marque, et vous pouvez y revenir avec une touche (ou deux, selon votre configuration). Je trouve cela extrêmement utile, d'autant plus que beaucoup de commandes Emacs qui changent votre emplacement dans le tampon placent la marque à votre ancien emplacement. Un exemple est lorsque je modifie un module Python et que je dois ajouter une instruction d'importation en haut du fichier. La frappe pour aller en haut du tampon (Alt- <) définit la marque. J'ajoute la déclaration d'importation. J'appuie sur Ctrl-u Ctrl-Espace et je suis de retour là où j'ai commencé. Je peux continuer à faire cela pour revenir aux positions précédentes également. (Peut-être que j'avais besoin de sélectionner du texte lors de l'ajout de cette instruction d'importation.)

L'autre différence (et plus connue) d'Emacs est l'anneau de destruction. La plupart des touches pour supprimer du texte du tampon sauvegardent le texte dans l'anneau de suppression, qui peut ensuite être rappelé avec la commande "yank" (Ctrl-y). La caractéristique essentielle est que les commandes yank suivantes récupèrent le texte tué plus ancien. Ainsi, vous pouvez tuer plusieurs sections de texte à la suite, puis les récupérer dans l'ordre. Vous pouvez également parcourir l'anneau de destruction avec Alt-y après un tirage, en supprimant le texte récupéré et en insérant l'entrée suivante dans l'anneau.

Emacs avait ces fonctionnalités en 1978. Le seul autre système majeur à les adopter à quelque degré que ce soit est NeXTStep (et maintenant hérité par Cocoa). D'autres outils fournissent plus de fonctionnalités pour des tâches spécifiques, peuvent être étendus dans des langages beaucoup plus faciles à utiliser qu'Emacs Lisp, et ont des interfaces visuelles plus agréables ... mais Emacs reste meilleur dans l'édition de texte. C'est pourquoi, une fois que vous savez comment l'utiliser, il est si difficile d'arrêter.

Ce n'est pas exactement une tâche spécifique, mais pour les personnes qui pourraient même souffrir de RSI, le fait que vos mains ne quittent jamais le clavier en vim n'a presque pas de prix. En fait, j'ai fini par aller à gauche sur ma souris au travail parce que cela me permettait moins de bouger ma main pour atteindre la souris (mon clavier à la maison n'a pas de pavé numérique, je peux donc le garder à droite).

Un autre petit avantage était que, IIRC, le vi d'origine était conçu pour accélérer l'édition de fichiers sur une connexion à distance terriblement lente. Certes, cela ne se produit pas autant aujourd'hui, mais si vous avez une connexion lente, bonne chance pour exécuter un éditeur de texte d'interface graphique et le rendre réactif.

Pour moi, les gros problèmes de productivité sont

• Je peux à peu près tout faire depuis le clavier.
• Macros puissantes.
• Au cours de mes 20 ans de carrière avec 9 systèmes d'exploitation, les liaisons de base du clavier n'ont pas changé. Je peux utiliser à peu près n'importe quel système et je connais déjà mon chemin dans l'éditeur.
• Presque toutes les fonctionnalités que vous pourriez souhaiter dans un éditeur de texte ont déjà été ajoutées.

Une chose que j'aime vraiment dans vim est la commande "répéteur". En gros, en appuyant .en mode commande, il répète votre dernière action. Ceci est juste un exemple de fonctionnalités vraiment intéressantes que les "éditeurs de texte pour programmeurs" ont, mais souvent pas les interfaces graphiques.

D'après mon expérience, les principaux gains de productivité apportés par vim et emacs (je suis moi-même une personne vim, mais emacs est sûrement similaire) sont:

• Vous pouvez avoir les fonctionnalités fournies par les IDE modernes (comme les cycles d'édition-construction-exécution à une touche, la documentation en ligne, la complétion des onglets, etc.), mais ce n'est pas nécessaire . Le gain de productivité? Vous ne voyez que ce que vous voulez voir. D'après mon expérience, les IDE n'ont pas rendu les gens plus productifs, également parce qu'ils montraient trop d' informations (toutes sortes de navigateurs). Ce "peu de puissance supplémentaire, quand vous en avez besoin - mais pas plus tôt" est tout à fait un gain de productivité à mon humble avis.

• Les éditeurs sont très populaires parmi les programmeurs, ce qui signifie qu'il existe d'énormes référentiels de scripts, de livres et de groupes d'utilisateurs disponibles.

• D'après mon expérience (je ne peux parler que pour vim ici), l'utilisateur moyen de vim est un assez bon ingénieur logiciel. Je ne sais pas pourquoi (ou peut-être que j'ai juste de la chance), mais peut-être que les gens qui ont pris la barrière de s'habituer à un `` vieil '' outil comme emacs ou vim ont le bon dévouement (et le contact avec d'autres personnes comme ça ). C'est peut-être un effet indirect de ces éditeurs, mais traîner avec d'autres personnes vim (ou emacs) sur par exemple IRC s'est avéré assez intéressant, car les mêmes personnes étaient également très intéressées par toutes sortes de problèmes de génie logiciel (ou d'informatique) . Ces éditeurs semblent attirer un certain type de personnalité. :-)

Le "gain de productivité" que j'obtiens en utilisant un clone emacs léger pour de petits programmes est qu'il démarre comme un éclair graissé. Je peux généralement lancer un programme de test rapide en C # avant que Visual Studio n'ait fini de charger une solution "sandbox".

Bien sûr, je pourrais simplement laisser Visual Studio ouvert (ou un autre VS ouvert si j'y travaille à ce moment-là), mais il serait remplacé si je le laissais inactif pendant un moment, etc.

Pour tout ce qui est de taille significative - ou si je ne connais pas assez bien l'API que j'utilise - un IDE est la voie à suivre, IMO.

J'utilise gvim pour Windows, donc techniquement c'est un éditeur de texte GUI, mais c'est vim ..

Pour les améliorations de productivité, je trouve:

1. Je n'ai jamais besoin d'utiliser la souris, donc je suis plus rapide.
2. rechercher, remplacer, copier / coller, etc. sont tous plus rapides avec les combinaisons de touches vim que les mouvements de la souris (une fois la courbe d'apprentissage surmontée)
3. Comme mentionné dans les commentaires précédents, les RSI sont considérablement réduits. Mes poignets m'ont remercié depuis que j'ai déménagé chez vim.
4. c'est léger et rapide

Vous savez, pour vi je pense que cela revient à avoir un mode d'insertion et de commande. Bien que cela puisse sembler un retour à une époque où vous ne pouviez pas dépendre du curseur ou des touches spéciales, cela signifie en réalité que de nombreuses commandes puissantes de manipulation de mouvement et de texte sont un nombre minimal de frappes. Le codage productif ne concerne pas la saisie de texte en masse (la valeur par défaut dans les éditeurs "modernes") mais une rafale de texte en masse suivie de petits ajustements considérables et de périodes de navigation encore plus longues.

Cela m'est apparu personnellement en utilisant vi sur un réseau de campus à latence élevée. Vous pouvez facilement obtenir 10 ou 15 caractères avant la réponse. Avec vi, je pouvais prédire confortablement où ces commandes me laisseraient et pouvoir travailler à des vitesses presque normales. Cette expertise tordue est un avantage continu dans des conditions normales - moins de cerveau visuel dédié à un retour graphique constant.

Les accélérateurs de recherche de mots courants * et # sont parfaits pour parcourir le code. Et% pour faire correspondre les parenthèses est extrêmement utile. Bien sûr, cela ne semble guère comparé à ctl-] mais la moitié des frappes s'additionne.

Personnellement, j'utilise winvi qui ajoute quelques grandes choses dont je suis sûr que vim a aussi. Un saut rapide en mode hexadécimal résout beaucoup de problèmes de texte "qu'est-ce qu'il se passe". Et la gestion complètement flexible des fins de ligne est une aubaine qui est devenue une fonctionnalité attendue pour un éditeur de texte. Enfin, il peut ouvrir n'importe quel fichier, quel que soit son contenu. Cela équivaut à une compétence de piratage d'élite de premier ordre.

Sous Unix, vous pouvez rapidement capturer la sortie du programme ou même filtrer des sections de votre fichier via des commandes externes. Une fonction extrêmement puissante mais je pense sous-utilisée.

J'utilise Vim assez souvent. Cela ne remplace pas UltraEdit pour moi. Étant donné que beaucoup de points positifs ont été répertoriés, je suppose que je vais aller à contre-courant et énumérer quelques ennuis avec Vim.

• Faible gestion FTP. Je «trie» beaucoup de sites, et ne pas pouvoir facilement parcourir et éditer des fichiers sur un serveur FTP distant est un gros défaut pour moi. NWRead n'est pas assez bon.
• La bizarrerie de la console héritée des problèmes généraux du terminal qui semble affliger Linux. J'utilise généralement PuTTY pour me connecter à ma machine Linux (exécutant Ubuntu), et pour une raison quelconque, les touches fléchées correspondent à A / B / C / D en mode insertion (et tous les problèmes de prise en charge des couleurs). Dans gVim, ctrl-tab peut être mappé à "bn" facilement, mais pas en mode console, de tels problèmes abondent.
• Les options de recherche / remplacement sont très faibles, du point de vue de l'interface. Devoir taper le tout sur une seule ligne n'est tout simplement pas suffisant. Je pense que le dialogue beaucoup plus élaboré dans UltraEdit me donne beaucoup plus de pouvoir à la fin, même si le support des expressions régulières peut être beaucoup plus faible.
• Dépendance trop forte aux dispositions de clavier américaines. Un grand nombre de touches qui sont utilisées pour les fonctions principales, telles que `, ne s'impriment pas sur ma disposition de clavier danois (et situées de manière arquée, comme pour $, et bien d'autres). Rend l'utilisation de certaines fonctions assez difficile.

Remote Desktop affiche rapidement uniquement l'application Windows native. Nous avons essayé d'utiliser Eclipse pour développer sous unix. Et tu sais quoi? Ce n'était même pas possible.

La deuxième raison est que nous pourrions étendre nos Vims et Emacs pour effectuer toutes les tâches spécifiques au projet à partir de la navigation DB d'une manière spéciale pour mettre en évidence et compléter automatiquement notre propre méta-langage.

Je dirais que l'un des gros avantages est l'extensibilité de l'éditeur vim. Si je veux que quelque chose fonctionne avec CVS, je peux utiliser le plugin CVSMenu et l'ajouter à mon éditeur pour obtenir cette fonctionnalité.

Idem pour la coloration syntaxique, le comportement avec des fichiers spécifiques, etc. Toutes sortes de choses peuvent être adaptées dans vim.

Je ne sais pas si vous pouvez le faire aussi facilement dans les éditeurs de type GUI.

L'enregistrement et la relecture dans VIM sont incroyablement géniaux, ce que vous ne trouverez probablement pas dans les outils basés sur l'interface graphique.

De plus, l'incrémentation / décrémentation automatique lui donne des capacités de génération de données sans écrire de programmes pour cela.

J'étais un utilisateur d'Emacs décousu depuis des années. Mais je n'y suis jamais vraiment entré. Puis j'ai commencé à apprendre Clojure (mon premier Lisp) et j'ai découvert ParEdit.

Et cela m'a époustouflé.

(Voir ici pour quelques exemples: https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit est l'expérience d'édition la plus incroyable que j'ai jamais eue. Rien d'autre ne se rapproche. Lisp n'est plus un langage gênant à écrire, me forçant à m'inquiéter d'équilibrer beaucoup de parenthèses idiotes irritantes. Avec ParEdit, la structure Lisp cohérente devient un énorme bonus à travailler, car les mêmes transformations d'arbres - slurping, barfing, fractionnement et jointure - fonctionnent partout, dans les structures de contrôle et les structures de données. Et ParEdit m'empêche de faire des erreurs stupides. Il devient presque impossible de faire des erreurs de syntaxe.

Et contrairement à Eclipse, ce n'est pas une vérification laborieuse en temps réel qui s'exécute toujours en arrière-plan, brûlant mon processeur. Cela ne coûte rien ... ParEdit fait simplement le bon changement structurel lorsque je le demande.

(En général, Emacs est aussi rapide que nécessaire. Contrairement à Eclipse qui revient à taper dans glue.)

La prochaine chose que j'ai découverte était Yasnippet ( http://emacswiki.org/emacs/Yasnippet ). Encore une fois, je n'avais jamais rien utilisé de tel auparavant. Pas simplement une macro pour ajouter du passe-partout, mais une forme dynamique et navigable.

Le plaisir final est de réaliser que si je veux étendre cette chose moi-même, pour avoir plus de ces outils de productivité de haut niveau, j'ai la puissance de Lisp lui-même pour travailler.

(Mon expérience est de quelques années avec Visual Studio et d'autres IDE, puis 15 ans de Vim et les 6 derniers mois avec Emacs.)

Longévité - Vim / Emacs sont des logiciels libres et existent depuis des décennies. Leur utilisation ne diminuera pas, et leurs fonctionnalités ne vont pas non plus casser / disparaître / changer beaucoup, vous pouvez donc compter sur la construction de l'ensemble de votre boîte à outils de carrière autour de la maîtrise d'un seul éditeur.

Accès distant / omniprésent dans les terminaux - Bien que les deux disposent de bons systèmes pour éditer des fichiers distants, vous pouvez également les installer sur n'importe quel système auquel vous vous connectez.

Développement piloté par REPL - Les deux ont des modes "SLIME" sous diverses formes qui intègrent le type de REPL avec lequel vous travaillez. Par exemple, je n'ai jamais rencontré de développement itératif aussi puissant que celui fourni par CIDER .

Linting - Quel que soit le langage que vous utilisez, il contient probablement des outils de linting , qu'ils soient intégrés au compilateur ou à un outil externe. Ceux-ci s'intègrent parfaitement à Emacs / Vim, montrant vos erreurs de codage en temps quasi réel.

Grammaire des commandes mnémotechniques - Bien que les deux prennent un certain temps à apprendre, ces éditeurs disposent de systèmes réputés intelligents pour accéder - et même se souvenir - de milliers de commandes avec quelques frappes et combinaisons de touches. Ceux-ci peuvent éliminer complètement tout besoin d'utiliser une souris si vous le souhaitez.

Systèmes d'aide intégrés - La documentation hors ligne de nombreux langages et de leurs API est commune à trouver intégrée dans ces éditeurs, et est accessible de manière aussi simple que les systèmes d'aide vastes et complets qu'ils proposent. La saisie semi-automatique a été ajoutée pour la plupart des langues courantes. De plus, il existe une multitude d'aide à la discussion sur pratiquement tous les sujets d'aide.

Navigation - balises, paredit-likes, marques, fenêtrage, onglets, saut de vim-rails et bien d'autres éléments intégrés.

Gestionnaires / référentiels de paquets - Emacs en a quelques-uns (elpa, melpa, marmelade) et les Vim sont bons aussi (vundle, pathogène, etc. ). Je ne connais aucune communauté autour des IDE qui offre quelque chose de comparable à ceux-ci. Je vois plus de 5 000 colis avec package-list-packages.

Au-delà de la simple édition - Emacs va plus loin ici avec la possibilité de lire les actualités, de naviguer sur le Web, de gérer les e-mails, de modifier des feuilles de calcul, de créer des présentations et d'organiser tout.

Intégré tout le reste - débogueurs, synchronisation du navigateur, compilation, shells, exécution des tests.

Infiniment personnalisable - Elisp est un langage très puissant pour étendre / modifier Emacs. VimL est l'équivalent de Vim. Il y a des livres écrits sur les deux. Ajustez les thèmes et les comportements de couleur à votre plus grand plaisir!

Un avantage de tous les éditeurs basés sur console par rapport aux éditeurs GUI est qu'ils peuvent être exécutés dans un multiplexeur de terminal tel que screen ou tmux . Pourquoi est-ce bon?

• Il est plus rapide de passer d'une console multiplexeur de terminal à une autre que de passer d'une console GUI à une autre en utilisant la souris, ou même en utilisant alt-tab. En effet, les consoles peuvent être nommées et basculées vers en tapant quelques caractères du nom.
• Si vos sessions d'édition se trouvent dans les consoles d'un multiplexeur de terminal, vous pouvez y accéder depuis n'importe quelle machine. Si j'ai besoin de travailler à domicile, je peux ssh dans ma boîte, attacher le multiplexeur de terminal déjà en cours d'exécution à ma session ssh et être là où je m'étais arrêté quand j'ai quitté le travail.

Comme vim / emacs sont souvent utilisés par les programmeurs et en tant qu'utilisateur C # depuis 2003, à partir de ce biais pov, il est juste de faire cette comparaison autrement injuste (un autre pourrait être VS C ++ avec Visual Assist X vs C ++ dans vim / emacs):

Pour C # et Visual Studio:

1. Je viens de compter le nombre de frappes pour cette ligne:

       public List<string> Names = new List<string>();
   //  3      3    3      1111111111111            211   =3+3+3+8+5+2+1+1 = 26 keys strokes + 3 uses of Shift while typing the line above in VS C# 2013 vs 47 key strokes for non-IntelliSense IDE's
   //                              (IntelliSense offers the List<string> because that's what you're likely after here but you can type something else if you want)
   // https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction explains on how this is impl. for C#. In C++ I've heard of 3rd party VS plugin that improves or replaces the VS C++ auto-complete

2. J'ai lu sur la fonctionnalité emacs pour sauter dans le code. Je ne pense pas qu'il ait une fonctionnalité exactement comme ça. Il a cependant une fonctionnalité similaire. Voici l'inconvénient de VS. Il y a beaucoup de petites fonctionnalités mais avec le temps elles cessent de fonctionner. La dernière fois que j'ai vérifié, la fonction de saut ne fonctionnait pas, mais c'était il y a quelques années. VS a introduit une nouvelle fonctionnalité de saut graphique que j'utilise à la place. Cela nécessite la souris ou le toucher.

3. Voici où l'emacs / vi gagne. Si vous devez beaucoup sauter dans le code, les fonctionnalités VS pour cela n'existent pas ou n'ont pas été suffisamment testées.

Le problème avec la navigation GUI basée sur la souris est que

a) tout comme s'asseoir en position très statique peut-être mauvais, si c'est le cas, les souris ont tendance à faire en sorte que vos doigts soient également en position statique. Ma douleur au poignet a disparu avec le changement de trackball. J'ai d'abord essayé la souris verticale mais cela n'a rien fait pour le problème.

b) Mon clavier idéal aurait 2 rangées de touches de fonction, pas de pavé numérique, donc je pourrais placer le trackball plus près, rend la distance de saut plus supportable.

En fin de compte, cependant, si vous voulez sauter entre quelques endroits spécifiques, il est clair que le «cercle de marque» est plus efficace. VS a quelque chose du genre ... la dernière fois que je l'ai utilisé, cela ne fonctionnait tout simplement pas de manière fiable ...

c) et il y a probablement une tonne de petites fonctionnalités qui cassent avec chaque version, c'est donc l'inconvénient de VS.

Solution à ce problème de "source fermée": écrivez le VS entier en C # puis autorisez la modification / édition du code compilé (au moment de l'exécution, en enregistrant les modifications sous forme de correctif éventuellement chargé au prochain démarrage) sans libérer la source. Cela peut être fait en demandant au décompilateur de sortir le code tel qu'il était lors de l'entrée. 180 degrés par rapport au fonctionnement des compilateurs natifs. Le binaire devient alors le code source et l'exécutable au lieu de ce désordre de fichiers .cs et de fichiers .exe, etc. Il existe des outils tiers qui peuvent presque déjà le faire, donc "modding" C # exe est plutôt trivial mais je propose de prendre cela pour la conclusion logique: incluez même des commentaires dans les fichiers .exe et .dll. Les fichiers seront toujours minuscules par rapport aux applications C / C ++ compilées. Optimisation? Vous pouvez également inclure du code pré-optimisé. Lorsque le moddeur modifie l'exe pendant que l'application est en cours d'exécution, le "AST" non modulé et le binaire optimisé qui l'accompagne sont rebranchés. Même idée que dans le compilateur C # mais prise plus loin. Étape suivante: écrivez le système d'exploitation entier dans ce langage, de sorte que même lorsque Windows est une source fermée, il puisse être modifié de manière triviale car le code source est fourni avec chaque binaire. Pas de configuration d'environnements, de compilation, de liaison. Modifiez simplement le système d'exploitation pendant son exécution. Proche de l'analogie: si vous avez écrit un navigateur Web en Common Lisp, vous pouvez modifier le navigateur Web sans l'arrêter et créer des pages Web dans la même langue que le navigateur. il peut être modifié de manière simple car le code source est fourni avec chaque binaire. Pas de configuration d'environnements, de compilation, de liaison. Modifiez simplement le système d'exploitation pendant son exécution. Proche de l'analogie: si vous avez écrit un navigateur Web en Common Lisp, vous pouvez modifier le navigateur Web sans l'arrêter et créer des pages Web dans la même langue que le navigateur. il peut être modifié de manière simple car le code source est fourni avec chaque binaire. Pas de configuration d'environnements, de compilation, de liaison. Modifiez simplement le système d'exploitation pendant son exécution. Proche de l'analogie: si vous avez écrit un navigateur Web en Common Lisp, vous pouvez modifier le navigateur Web sans l'arrêter et créer des pages Web dans la même langue que le navigateur.