Quels gains de productivité spécifiques Vim / Emacs fournit-il sur les éditeurs de texte GUI?

Cela ne signifie pas comme un troll ou une flamme ou quelque chose comme ça. J’utilise Vim comme éditeur de console depuis quelques mois (pour éditer des fichiers de configuration dans mon terminal), mais je ne pense pas pouvoir le supporter pour mon travail quotidien d’écriture d’applications Web. , ce que je fais avec un éditeur de texte GUI (ce qui n’est pas important).

Je pense que mon éditeur de texte GUI peut faire tout ce dont j’ai besoin pour mon travail. Il a une recherche / remplacement décente avec des historiques à complétion automatique pour les deux. Il a la coloration syntaxique, la numérotation des lignes, une interface à tabs, une copie et un collage faciles, etc.

Compte tenu de ce que je viens de dire, quels sont les avantages en termes de productivité de Vim (ou même d’Emacs) par rapport à un éditeur de texte graphique, hormis le fait qu’il soit installé sur chaque ordinateur. Je voudrais des tâches spécifiques qui sont meilleures / plus rapides sur Vim / Emacs ou qui ne sont pas possibles avec les éditeurs de texte 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 :.! , pour diriger la sortie d’une commande dans un tampon, vous ne le trouverez pas dans la plupart des éditeurs d’interface graphique.

  • Une interface à tabs n’est pas aussi agréable que l’interface “fenêtrée” que Vim / Emacs vous offre. Vous pouvez voir deux ou plusieurs fichiers simultanément simultanément. Plus vous pouvez voir à l’écran, plus vous libérez votre esprit pour penser à votre problème plutôt que de faire une comptabilité mentale des noms de variables et des signatures de fonctions.

  • Ne sous-estimez pas le pouvoir des expressions régulières de Vim. Il y a beaucoup d’extensions spécifiques à Vim pour correspondre à une colonne spécifique, une marque, la position du curseur, certaines classes de caractères (mots-clés, identificateurs), etc.

  • diff et grep intégrés (plate-forme indépendante, 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 de bloc visuel (pour éditer des 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 ceci, en faisant quelques modifications dans quelques touches que quelqu’un aurait autrement passé dix minutes à faire manuellement.

  • Multiple copier / coller des registres. Lorsque vous n’en avez qu’un, vous finissez par traverser d’étranges contorsions pour éviter de bash le presse-papiers. Vous ne devriez pas être obligé.

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

  • Se déplacer, copier, coller et supprimer du texte est extrêmement rapide dans Vim. Les commandes sont simples, à touches uniques et composables. Additionnez toutes les fois que vous faites une mise en surbrillance de la souris prudente et laborieuse et Ctrl-X, puis remplacez-les toutes par un da( (supprimez un ensemble de parens correspondants et tout ce qu’elles contiennent).

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

  • Langage de script intégré et puissant mappage de touches et capacité de macro 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 trouverez que même les fonctionnalités des autres éditeurs, 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 beaucoup d’options de configuration, et il est très simple d’écrire vos propres fichiers. De nombreux éditeurs gèrent bien 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 la conversion entre eux. La toute première chose qui m’a impressionné à propos de Vim est à quel point il gère parfaitement les options d’indentation d’espace / tabulation 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 aussi bien à Emacs (de manières différentes mais généralement aussi puissantes).

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

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

Pour moi, le plus pratique est de sauter (ou juste avant) une lettre spécifique ou une combinaison de lettres, ou de sauter en arrière, avec quelques frappes au clavier. Sauter deux fois ou dix fois dans les mêmes conditions, c’est simplement le préfixer par un chiffre.

Si vous devez répéter une édition, vous avancez à cet endroit (2-3 frappes), puis appuyez sur “.” pour répéter la dernière édition. 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 à changer de 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.

Au bout de quelques jours, vous vous retrouverez grincheux à chaque fois que vous atteindrez la souris (ou appuyez sur 15 fois), lorsque vous êtes dans un éditeur 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’y a pas besoin de changer! 🙂

Aussi, lisez 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é à 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 macro. La répétition est pénible pour beaucoup de programmeurs, et écrire des macros correctes peut être amusant. Si vous ne faites pas tout via le clavier, la création de macros nécessitera un jeu de commandes supplémentaire plutôt que d’utiliser celles que vous utilisez déjà.

Je suis semi-compétent avec les raccourcis de vi, mais je préfère Emacs en général. La raison pour laquelle ces éditeurs ont des partisans si fervents est que le modèle d’édition qu’ils proposent est plus puissant que les systèmes plus récents, ce qui explique pourquoi il n’est pas suffisant de fournir des «raccourcis clavier vi» ou des «raccourcis emacs». ou personnalisations pour emacs ou vi.

Je vais seulement parler du modèle d’Emacs parce que je le comprends le mieux. Le modèle commun pour l’édition de texte aujourd’hui implique un tampon de texte, dans lequel du texte peut être inséré, supprimé, sélectionné et coupé / copié / collé dans le presse-papier du système.

Les tampons Emacs, bien sûr, peuvent supporter ces opérations. Avec le suivi de la position du curseur pour chaque fenêtre dans laquelle ils sont visibles, ils conservent également la trace des “marques” qui y sont enregistrées. Le texte entre le “point” (position du curseur) et la “marque” est appelé “région” et correspond approximativement à la sélection dans les éditeurs grand public.

La différence est que Emacs garde la trace des derniers endroits où la marque a été définie dans l’anneau de marque, et vous pouvez y revenir avec une frappe au clavier (ou deux, selon votre configuration). Je trouve cela extrêmement utile, surtout depuis que de nombreuses commandes Emacs qui modifient votre emplacement dans la mémoire tampon définissent la marque sur votre ancien emplacement. Par exemple, lorsque je modifie un module Python et que je dois append 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-Space et je suis de retour où j'ai commencé. Je peux continuer à le faire pour revenir aux positions précédentes. (Peut-être que je devais sélectionner du texte en ajoutant cette instruction d'importation.)

L’autre (et plus connu) différence Emacs est le kill ring. La plupart des frappes de touches pour supprimer du texte du tampon enregistrent du texte sur le «kill ring», qui peut ensuite être rappelé avec la commande «yank» (Ctrl-y). La caractéristique essentielle est que les commandes de récupération suivantes récupèrent le texte détruit plus ancien. Vous pouvez donc tuer plusieurs sections de texte à la suite, puis les récupérer dans l’ordre. Vous pouvez également parcourir le cercle mortel avec Alt-y après un coup, en supprimant le texte récupéré et en insérant la prochaine entrée dans l’anneau.

Emacs avait ces fonctionnalités en 1978. Le seul autre système majeur à les adopter de quelque façon que ce soit est NeXTStep (et maintenant hérité par Cocoa). D’autres outils offrent plus de fonctionnalités pour des tâches spécifiques, peuvent être étendus dans des langages beaucoup plus simples à utiliser qu’Emacs Lisp, et ont des interfaces visuelles plus agréables … mais Emacs rest meilleur en é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 peuvent même souffrir de RSI, le fait que vos mains ne quittent jamais le clavier dans vim est presque inestimable. J’ai fini par aller à gauche avec ma souris au travail car cela me permettait de déplacer ma main moins pour atteindre la souris (mon clavier à la maison n’a pas de pavé numérique, donc je peux le garder à droite).

Un autre petit avantage était que l’IIRC, le vi original, était conçu pour accélérer l’édition de fichiers sur une connexion à distance extrêmement lente. Certes, cela ne se produit pas presque autant aujourd’hui, mais si vous avez une connexion lente, bonne chance pour faire fonctionner un éditeur de texte et le faire réagir.

Pour moi, les grandes choses de la productivité sont

  • Je peux tout faire à partir du clavier.
  • Macros puissantes
  • Dans ma carrière de 20 ans utilisant 9 OS, les raccourcis clavier de base n’ont pas changé. Je peux monter à peu près n’importe quel système et je connais déjà mon éditeur.
  • Presque toutes les fonctionnalités que vous voudrez peut-être dans un éditeur de texte ont déjà été ajoutées.

Une chose que j’aime beaucoup à propos de vim est la commande “repeater”. Fondamentalement, en appuyant sur . 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 de programmeur ont souvent des interfaces graphiques.

Dans mon expérience, les principaux gains de productivité que fournissent vim et emacs (je suis moi-même une personne, mais emacs est certainement similaire) sont:

  • Vous pouvez avoir ces fonctionnalités fournies par les IDE modernes (comme les cycles d’édition-build-run et la documentation en ligne, la saisie des tabulations et autres), mais vous n’êtes pas obligé . Le gain de productivité? Vous voyez seulement autant que vous voulez voir. D’après mon expérience, les IDE n’ont pas rendu les gens plus productifs, car ils affichaient trop d’ informations (tous les types de navigateurs). Ce “petit peu de puissance, quand vous en avez besoin – mais à plus tôt” est 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.

  • Dans 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 c’est (ou peut-être suis-je juste chanceux), mais peut-être que les personnes qui ont pris l’habitude de s’habituer à un “vieux” outil comme emacs ou vim ont le bon engagement (et contactent d’autres personnes comme ça) ). Peut-être est-ce un effet indirect de ces éditeurs, mais passer du temps avec d’autres personnes de vim (ou emacs) sur IRC, par exemple, s’est avéré très intéressant, car les mêmes personnes étaient également intéressées par toutes sortes d’ingénierie logicielle (ou informatique). . Ces éditeurs semblent attirer un certain type de personnalité. 🙂

Le “gain de productivité” que j’obtiens en utilisant un clone léger d’Emacs pour des programmes minuscules, c’est qu’il démarre comme un éclair gratté. Je peux généralement sortir un programme de test rapide en C # avant que Visual Studio ait fini de charger une solution “sandbox”.

Bien sûr, je pouvais simplement laisser Visual Studio ouvert (ou un autre VS ouvert si j’y travaillais à ce moment-là), mais si cela restait un moment inactif, etc.

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

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

Pour améliorer la 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 plus rapides avec les raccourcis vim et 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é à vim.
  4. c’est léger et rapide

Vous savez, pour vi je pense que cela revient à avoir un mode insertion et 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 que beaucoup de commandes de mouvement et de commande de texte puissantes sont un nombre minimal de frappes. Le codage productif ne concerne pas la saisie de texte en bloc (la valeur par défaut dans les éditeurs «modernes»), mais une rafale de texte en bloc suivie de petits ajustements considérables et de périodes de navigation encore plus importantes.

Pour moi, cela a été une évidence en utilisant vi sur un réseau de campus à forte latence. Vous pouvez facilement obtenir 10 ou 15 caractères avant la réponse. Avec vi, je pouvais facilement prédire où ces commandes me quitteraient et pouvoir travailler à des vitesses presque normales. Cette expertise tordue est un avantage continu dans des conditions normales – moins de cerveaux visuels dédiés à la rétroaction graphique constante.

Les accélérateurs de recherche communs * et # word sont parfaits pour parcourir le code. Et% pour apparier les parenthèses est extrêmement utile. Bien sûr, à peine comparé à ctl-] mais la moitié des frappes s’ajoutent.

Personnellement, j’utilise winvi, qui ajoute quelques grandes choses dont je suis sûr que vim aussi. Un saut rapide dans le mode hexadécimal crée beaucoup de problèmes de texte. Et la gestion complètement flexible des fins de ligne est une aubaine 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 et pourtant sous-utilisée.

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

  • Manipulation FTP faible. Je “sortinge” beaucoup de sites, et ne pas pouvoir parcourir et éditer facilement des fichiers sur un serveur FTP distant est une grande lacune pour moi. NWRead n’est pas suffisant.
  • La bizarrerie de la console héritée des problèmes généraux du terminal qui semble empoisonner Linux. J’utilise habituellement PuTTY pour me connecter à ma machine Linux (exécutant Ubuntu), et pour certaines raisons, les touches fléchées correspondent à A / B / C / D en mode insertion (et aux problèmes de prise en charge de la couleur entière). Dans gVim, ctrl-tab peut être associé à “bn” facile, mais pas en mode console, de tels problèmes ne manquent pas.
  • Les options de recherche / remplacement sont très faibles, en termes d’interface. Le fait de devoir taper le tout en une seule ligne ne suffit pas. Je pense que le dialog beaucoup plus complexe dit qu’UltraEdit me donne beaucoup plus de pouvoir à la fin, même si le support des expressions régulières peut être beaucoup plus faible.
  • Une trop grande confiance dans les dispositions de clavier américaines. Un grand nombre de touches utilisées pour les fonctions principales, telles que `, ne sont pas imprimées sur la disposition de clavier danoise (et sont placées de manière aléatoire, comme avec $ et bien d’autres). Cela rend difficile d’utiliser certaines fonctions.

Remote Desktop affiche rapidement uniquement les applications Windows natives. 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 systèmes Vims et Emacs pour effectuer toutes les tâches spécifiques au projet à partir de la navigation dans la firebase database afin de mettre en évidence et de compléter automatiquement notre propre méta-langue.

Je dirais que l’un des grands avantages est l’extensibilité de l’éditeur de vim. Si je veux que quelque chose fonctionne avec CVS, je peux prendre le plug-in CVSMenu et l’append à mon éditeur pour obtenir cette fonctionnalité.

Même chose avec la coloration syntaxique, le comportement avec des fichiers spécifiques, etc. Toutes sortes de choses peuvent être personnalisées dans vim.

Pas si sûr de pouvoir le faire aussi facilement dans les éditeurs de type GUI.

Record and Replay dans VIM est incroyablement génial, ce que vous ne trouverez probablement pas dans les outils basés sur l’interface graphique.

L’ auto-incrémentation / décrémentation lui confère également des capacités de génération de données sans écrire de programme pour cela.

Cela faisait des années que j’étais un utilisateur Emacs. Mais jamais vraiment eu dedans. Puis j’ai commencé à apprendre Clojure (mon premier Lisp) et j’ai découvert ParEdit.

Et ça m’a bouleversé.

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

Lisp + ParEdit est l’expérience d’édition la plus étonnante que j’ai jamais eue. Rien d’autre ne s’approche. Lisp n’est plus un langage maladroit à écrire, ce qui me force à me soucier de trouver un équilibre entre beaucoup de parenthèses idiotes et irritantes. Avec ParEdit, la structure cohérente de Lisp devient un énorme avantage pour travailler avec les mêmes transformations d’arbre – encombrement, clivage, séparation et jonction – qui 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 tourne toujours en arrière-plan, brûlant mon processeur. Cela ne coûte rien … ParEdit fait simplement le bon changement structurel quand je le demande.

(En général, Emacs est aussi rapide que nécessaire. Contrairement à Eclipse, c’est comme taper de la colle.)

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. Pas simplement une macro pour append une forme standard, mais une forme navigable dynamic.

Le plaisir final est la prise de conscience que si je veux étendre cette chose moi-même, pour avoir plus de ces outils de productivité de haut niveau, j’ai le pouvoir de travailler avec Lisp.

(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 va pas diminuer, et leurs fonctionnalités ne vont pas disparaître / changer / changer beaucoup, vous pouvez donc compter sur la construction de votre coeur de boîte à outils de carrière autour de la maîsortingse d’un seul éditeur.

Accès distant / omniprésent dans les terminaux – Bien que les deux systèmes disposent de bons systèmes pour éditer des fichiers distants, vous pouvez également les installer sur tous les systèmes auxquels vous vous connectez.

Développement basé sur REPL – Les deux ont des modes “SLIME” sous différentes 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 – Quelle que soit la langue que vous utilisez, elle contient des outils de filtrage , qu’ils soient intégrés au compilateur ou à un outil externe. Ceux-ci s’intègrent parfaitement avec Emacs / Vim, montrant vos erreurs de codage en temps quasi réel.

Grammaire des commandes mnémoniques – Bien que les deux prennent un certain temps à apprendre, ces éditeurs disposent de systèmes astucieux pour accéder – et même se souvenir – à des milliers de commandes avec quelques combinaisons de touches et de touches. Ceux-ci peuvent éliminer complètement le besoin d’utiliser une souris si vous êtes si enclin.

Systèmes d’aide intégrés – La documentation hors ligne de nombreux langages et de leurs API est commune à ces éditeurs, et est accessible de manière tout aussi simple aux systèmes d’aide vastes et complets qu’ils présentent. L’achèvement automatique a été ajouté pour la plupart des langues courantes. En outre, il existe une foule d’aide à la discussion sur pratiquement toutes les rubriques d’aide.

Navigation – balises, paredit-likes, marques, fenêtrage, tabulations, sauts vim-rails et bien d’autres fonctions intégrées.

Gestionnaires de paquets / référentiels – Emacs en a quelques-uns (elpa, melpa, marmelade) et Vim’s aussi (vundle, pathogen, etc. ). Je ne connais aucune communauté autour des IDE qui offre quelque chose de comparable. Je vois plus de 5 000 paquets avec des package-list-packages .

Au-delà de la simple modification – Emacs va plus loin avec la possibilité de lire des nouvelles, de naviguer sur le Web, de gérer le courrier électronique, de modifier des feuilles de calcul, de créer des présentations et d’organiser tout.

Intégrez tout le rest – débogueurs, synchronisation du navigateur, compilation, shells, test en cours d’exécution.

Personnalisable à l’infini – Elisp est un langage très puissant pour l’extension / modification d’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 pour votre plus grand plaisir!

L’un des avantages de tous les éditeurs de console par rapport aux éditeurs graphiques est qu’ils peuvent être exécutés dans un multiplexeur de terminal tel que screen ou tmux . Pourquoi est-ce bien?

  • Il est plus rapide de passer d’une console de multiplexage de terminal à une autre que de passer d’une console GUI à une autre en utilisant la souris, ou même en utilisant l’onglet Alt. En effet, les consoles peuvent être nommées et basculées en tapant quelques caractères du nom.
  • Si vos sessions d’éditeur se trouvent dans les consoles d’un multiplexeur de terminaux, vous pouvez y accéder depuis n’importe quel ordinateur. Si je dois faire un travail à la maison, je peux ssh dans ma boîte, attacher le multiplexeur de terminal en cours d’exécution à ma session ssh, et être au bon endroit quand j’ai quitté mon travail.

Comme vim / emacs sont souvent utilisés par les programmeurs et en tant qu’utilisateurs de C # depuis 2003, à partir de ce biais, 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 sur cette ligne:

      public List Names = new List(); // 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 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-Comstackr-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 que cela a une fonction 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. J’ai vérifié que la fonctionnalité de saut ne fonctionnait pas, mais c’était il y a quelques années. VS a introduit une nouvelle fonctionnalité de saut graphique à la place. Il nécessite une souris ou un toucher.

  3. Voici où emacs / vi gagne. Si vous devez sauter beaucoup dans le code, les fonctionnalités de VS 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 tel 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 elle n’a rien fait pour résoudre le problème.

b) Mon clavier idéal aurait 2 rangées de touches de fonction, pas de pavé numérique, donc je pourrais rapprocher le trackball, 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 “ring” est plus efficace. VS a quelque chose dans ce sens … je l’ai utilisé pour la dernière fois, ça ne fonctionnait pas de manière fiable …

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

Solution à ce problème “source fermée”: écrivez l’intégralité du code VS en C #, puis autorisez la modification / modification du code compilé (lors de l’exécution, en enregistrant les modifications en tant que correctif éventuellement chargé au prochain démarrage) sans libérer la source. Cela peut être fait en faisant en sorte que le décompilateur affiche le code tel qu’il était lorsqu’il entrait. 180 degrés par rapport au fonctionnement des compilateurs natifs. Le binary devient alors le code source et l’exécutable à la place de ce mess des fichiers .cs et des fichiers .exe, etc. Il existe des outils tiers qui peuvent déjà le faire, donc “modding” C # exe est plutôt sortingvial mais je propose la conclusion logique: inclure même des commentaires dans les fichiers .exe et .dll. Les fichiers seront encore minuscules comparés aux applications compilées C / C ++. 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 moddé et le binary optimisé associé sont rebranchés. Même idée que dans le compilateur C # mais plus loin. Etape suivante: Ecrivez l’intégralité du système d’exploitation dans ce langage, de sorte que même lorsque Windows est une source fermée, il soit modifiable de manière sortingviale à mesure que le code source est fourni avec chaque binary. Pas de mise en place d’environnements, de compilation, de liaison. Modifiez simplement le système d’exploitation en cours d’exécution. Analogie étroite: Si vous avez écrit un navigateur Web dans Common Lisp, vous pouvez éditer le navigateur Web sans l’arrêter et créer des pages Web dans la même langue que le navigateur.