Quels gains de productivité spécifiques Vim / Emacs offrent-ils par rapport aux éditeurs de texte GUI?
Ce n'est pas conçu comme un troll ou un appât de flamme ou quelque chose comme ça. J'utilise Vim comme éditeur de console de choix depuis quelques mois maintenant (pour éditer les fichiers de configuration depuis mon terminal), mais je ne pense pas que je pourrais le supporter pour mon normal, travail quotidien 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 de saisie automatique pour les deux. Il a une coloration syntaxique, une numérotation des lignes, une interface à onglets, 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 GUI, à part le fait qu'il est installé sur chaque ordinateur. J'aimerais 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
:.!, pour diriger la sortie d'une commande dans un tampon, est quelque chose que vous ne trouverez pas dans la plupart des éditeurs de GUI.Une interface à onglets n'est pas aussi agréable que l'interface "fenêtrée" que Vim/Emacs vous offre. Vous pouvez voir deux ou plusieurs fichiers 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 une comptabilité mentale des noms de variables et des signatures de fonction.
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.
diffetgrepintégrés (indépendant de la plateforme, vous n'avez donc pas besoin de télécharger et d'apprendre un nouvel outil à chaque fois que vous changez d'ordinateur).De nombreux éditeurs manquent au mode de blocage visuel (pour éditer les colonnes), mais je ne peux pas m'en passer. J'ai choqué et impressionné les gens au travail en utilisant juste cela, faisant quelques modifications en quelques touches que quelqu'un aurait autrement passé dix minutes à faire manuellement.
Registres multiples de copier/coller. Lorsque vous n'en avez qu'un, vous finissez par subir d'étranges contorsions pour éviter de vous encombrer le presse-papiers. Vous ne devriez pas avoir à le faire.
Le système undo/redo 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 un arbre 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 des touches simples, simples et composables. Additionnez toutes les fois que vous effectuez un surlignage de souris prudent et laborieux et Ctrl-X, puis remplacez-les tous par un
da((supprimer un ensemble de parens correspondants et tout ce qu'ils contiennent). Cela vous fait gagner plus de temps que vous ne le pensezLes petites choses, comme
*pour rechercher le mot sous le curseur, ou.pour répéter une commande, ou%pour rebondir entre une parenthèse d'ouverture et de fermeture. Beaucoup trop de ces éléments pour les énumérer.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 assez attentivement, vous constaterez que même les fonctionnalités que les 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 Sun, 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 OK, mais Vim vous offre des moyens très spécifiques et infaillibles de définir des 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ères différentes mais généralement tout aussi puissantes).
(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 en avant (ou juste avant) une lettre spécifique ou une combinaison de lettres, ou de revenir en arrière, avec quelques touches. Sauter deux fois ou dix fois dans la même condition revient simplement à le préfixer avec un chiffre.
Si vous devez répéter une modification, vous sautez en avant à 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 touche - s'il s'agit de 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 à déplacer votre main pour saisir la souris. Cela vous donne trois ou quatre fois plus de mouvements/commandes d'édition que vous le feriez si vous deviez continuer à saisir la souris.
Après quelques jours, vous vous sentirez grincheux à chaque fois que vous devrez atteindre la souris (ou appuyez sur <Down> 15 fois), lorsque vous êtes dans un éditeur GUI.
Je me suis toujours demandé pourquoi peu de gens gaga sur Vim. Voir la vidéo de l'utilisateur expérimenté de Vim 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 pas 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 de nombreux programmeurs, et écrire des macros appropriées peut être divertissant à la limite. Si vous ne faites pas tout à travers 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 l'ensemble. La raison pour laquelle ces éditeurs ont des adeptes si fervents est que le modèle d'édition qu'ils fournissent est plus puissant que les systèmes plus récents, c'est pourquoi la fourniture de "vi keybindings" ou "emacs keybindings" ne suffit pas, même si vous n'utilisez aucune fonctionnalité d'extension 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 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 conserve la trace des derniers emplacements sur lesquels la marque a été définie dans l'anneau de marque, et vous pouvez y revenir en appuyant sur une touche (ou deux, selon votre configuration). Je trouve cela extrêmement utile, d'autant plus que de nombreuses commandes Emacs qui changent votre emplacement dans le tampon définissent 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 touche pour aller en haut des ensembles de tampons (Alt- <) la marque. J'ajoute l'instruction d'importation. J'appuie sur Ctrl-u Ctrl-Espace et je suis de retour là où j'ai commencé. Je peux continuer à le faire pour revenir aux positions précédentes également. (Peut-être que je devais sélectionner du texte lors de l'ajout cette déclaration d'importation.)
L'autre différence (et plus connue) d'Emacs est le kill ring. La plupart des frappes pour supprimer le texte du tampon enregistrent le texte dans le kill ring, 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. Vous pouvez donc tuer plusieurs sections de texte d'affilée, puis les récupérer dans l'ordre. Vous pouvez également faire défiler le kill ring avec Alt-y après un coup sec, en supprimant le texte récupéré et en insérant l'entrée suivante dans le ring.
Emacs avait ces caractéristiques en 1978. Le seul autre système majeur pour les adopter dans une certaine mesure 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 langues beaucoup plus faciles à utiliser que Emacs LISP, et ont des interfaces visuelles plus agréables ... mais Emacs reste meilleur pour l'édition de texte. C'est pourquoi, une fois que vous savez l'utiliser, il est si difficile d'arrêter.
Ce n'est pas exactement une tâche spécifique, mais pour les personnes qui même pourraient être souffrant de RSI, le fait que vos mains ne quittent jamais le clavier dans vim est presque inestimable. En fait, j'ai fini par devenir gaucher sur ma souris au travail car cela me permettait de bouger moins ma main 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, IIRC, le vi original a été conçu pour accélérer l'édition des 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 en exécutant un éditeur de texte GUI et en le faisant réagir.
Pour moi, les grandes choses de la productivité sont
- Je peux faire à peu près tout depuis le clavier.
- Macros puissantes.
- Au cours de ma carrière de 20 ans 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à bien 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 à 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 sympas que les "éditeurs de texte programmeur" ont que souvent les interfaces graphiques n'ont pas.
D'après mon expérience, les principaux gains de productivité que vim et emacs (je suis moi-même une personne vim, mais emacs est sûrement similaire) sont les suivants:
Vous pouvez avoir les fonctionnalités que les IDE modernes fournissent (comme les cycles d'édition-construction-exécution à une touche et la documentation en ligne et la complétion des onglets et ainsi de suite) mais vous n'avez pas devez . 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, également parce qu'ils montraient des informations trop (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épertoires 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 c'est (ou peut-être que je suis juste chanceux), 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 contact avec d'autres personnes comme ça ). C'est peut-être un effet indirect de ces éditeurs, mais passer du temps avec d'autres personnes vim (ou emacs), 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 n autre VS ouvert si j'y travaille à ce moment-là) mais alors il serait échangé si je le laissais inactif pendant un certain temps, etc. .
Pour tout ce qui a une taille importante - 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 GUI, mais c'est vim ..
Pour les améliorations de productivité, je trouve:
- Je n'ai jamais besoin d'utiliser la souris, donc je suis plus rapide.
- la recherche, le remplacement, le copier/coller, etc. sont tous plus rapides avec les raccourcis clavier vim vs les mouvements de la souris (une fois la courbe d'apprentissage surmontée)
- Comme mentionné dans les commentaires précédents, les RSI sont considérablement réduits. Mes poignets me remercient depuis que j'ai déménagé à vim.
- 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 vraiment que de nombreuses commandes de mouvement et de manipulation de texte puissantes représentent 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 facilement prédire où ces commandes me laisseraient et pouvoir travailler à des vitesses proches de la normale. Cette expertise tordue est un avantage continu dans des conditions normales - moins de cerveaux visuels dédiés à une rétroaction graphique constante.
Les accélérateurs de recherche courants * et # Word sont parfaits pour parcourir le code. Et% pour faire correspondre les parenthèses est extrêmement utile. Bien sûr, cela ne semble pas beaucoup comparé à ctl-] mais la moitié des frappes s'additionne.
Personnellement, j'utilise winvi qui ajoute quelques grandes choses que je suis sûr que vim a aussi. Un saut rapide en mode hexadécimal fissure beaucoup de problèmes de texte "qu'est-ce qui 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 Elite 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. Il ne remplace cependant pas ltraEdit pour moi. Étant donné que de nombreux points positifs ont été répertoriés, je suppose que je vais aller à contre-courant et énumérer certains ennuis avec Vim.
- Faible gestion FTP. Je "trie" 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 assez bon.
- Bizarrerie de la console héritée des problèmes de terminal généraux qui semblent affliger Linux. J'utilise généralement PuTTY pour me connecter à ma boîte Linux (exécutant Ubuntu), et pour une raison quelconque, les touches fléchées sont mappées sur 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é sur "bn" facilement, mais pas en mode console, de tels problèmes abondent.
- Les options de recherche/remplacement sont très faibles, au niveau 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é dit que UltraEdit me donne beaucoup plus de pouvoir à la fin, même si le support réel des expressions régulières peut être beaucoup plus faible.
- Une dépendance trop forte aux dispositions du clavier américain. Un grand nombre de touches utilisées pour les fonctions principales, telles que `, ne s'impriment pas sur ma disposition de clavier danoise (et situées de façon arquée, de même avec $, et bien d'autres). Il est assez gênant d'utiliser certaines fonctions.
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 prendre le plugin CVSMenu et l'ajouter à mon éditeur pour obtenir cette fonctionnalité.
Idem avec la coloration syntaxique, le comportement avec des fichiers spécifiques, etc. Toutes sortes de choses peuvent être personnalisées dans vim.
Je ne sais pas si vous pouvez le faire aussi facilement dans les éditeurs de type GUI.
Le Bureau à distance 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.
J'étais un utilisateur Emacs desultory depuis des années. Mais je n'y suis jamais vraiment allé. Puis j'ai commencé à apprendre Clojure (mon premier LISP) et découvert ParEdit.
Et cela m'a époustouflé.
(Voir ici pour quelques exemples: https://www.youtube.com/watch?v=D6h5dFyyUX )
LISP + ParEdit est l'expérience d'édition la plus étonnante que j'ai jamais eue. Rien d'autre ne se rapproche. LISP n'est plus une langue gênante à écrire, ce qui m'oblige à me soucier d'équilibrer beaucoup de parenthèses idiotes irritantes. Avec ParEdit, la structure LISP cohérente devient un énorme bonus avec lequel travailler, car les mêmes transformations d'arbre - slurping, barfing, splitting et join - 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 en temps réel laborieuse 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 quand je le demande.
(En général, Emacs est aussi rapide qu'il le faut. Contrairement à Eclipse qui revient à 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 utilisé quelque chose comme ça auparavant. Pas simplement une macro pour ajouter un passe-partout, mais une forme dynamique et navigable.
Le plaisir final est la réalisation 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 elle-même pour travailler.
Enregistrez et relisez en VIM est incroyablement génial, que vous ne trouverez probablement pas dans les outils basés sur l'interface graphique.
Aussi incrémentation/décrémentation automatique lui donne des capacités de génération de données sans écrire de programmes pour cela.
(Mon parcours 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 FOSS , et existent depuis des décennies . Leur utilisation ne va pas décliner, ni leurs fonctionnalités ne vont casser/disparaître/changer beaucoup, vous pouvez donc compter sur la construction de votre noyau de 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 tous deux disposent de systèmes adaptés pour l'édition de 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 différentes formes qui intègrent tout type de REPL vous êtes Par exemple, je n'ai jamais rencontré de développement itératif aussi puissant que celui fourni par CIDRE .
Linting - Quel que soit le langage que vous utilisez, il existe probablement des outils linting , qu'ils soient intégrés au compilateur ou à un outil externe. Ceux-ci s'intègrent de manière transparente à 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 réputés intelligents pour accéder - et même se souvenir - à des milliers de commandes avec quelques frappes et combinaisons de touches. Ceux-ci peuvent éliminer complètement tout besoin d'utiliser une souris si vous en avez envie.
Systèmes d'aide intégrés - La documentation hors ligne de nombreux langages et de leurs API est courante à trouver intégrée dans ces éditeurs et est accessible de manière simple et similaire à les vastes et complets systèmes d'aide dont ils disposent. La saisie semi-automatique a été ajoutée pour la plupart des langues courantes. En outre, il existe une multitude d'aide à la discussion sur pratiquement tous les sujets d'aide.
Navigation - balises, paredit-likes, marques, fenêtrage, onglets, vim-Rails ' saut , et bien d'autres construits ins.
Gestionnaires de dépôts/référentiels - Emacs en a quelques-uns (elpa, melpa, marmalade) et les Vim sont bons aussi (vundle, pathogen, etc) ). Je ne connais aucune communauté autour des IDE qui offre quelque chose de comparable à ceux-ci. Je vois plus de 5 000 packages avec package-list-packages.
Au-delà de la simple édition - Emacs va plus loin avec la possibilité de lire les actualités, de naviguer sur le Web, de gérer les e-mails, de modifier les feuilles de calcul, de créer des présentations et d'organiser n'importe quoi.
Intégré tout le reste - débogueurs, synchronisation du navigateur, compilation, shells, test de fonctionnement.
Personnalisable à l'infini - 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 des couleurs pour votre plus grand plaisir!
Comme vim/emacs sont souvent utilisés par les programmeurs et en tant qu'utilisateur C # depuis 2003, à partir de ce point de vue, 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:
Je viens de compter le nombre de touches 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-completeJ'ai lu sur la fonction 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 au fil du temps, elles cessent de fonctionner. La dernière fois que j'ai vérifié que la fonction de saut ne fonctionnait pas, c'était il y a quelques années. VS a introduit une nouvelle fonction de saut graphique que j'utilisais à la place. Il nécessite une souris ou un toucher.
Voici où l'emacs/vi gagne. Si vous devez sauter beaucoup 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 dans une position très statique peut être mauvais, si c'est le cas, les souris ont également tendance à mettre vos doigts 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 rapprocher le trackball, ce qui 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 de marque" est plus efficace. VS a quelque chose dans ce sens ... la dernière fois que je l'ai utilisé, cela n'a tout simplement pas fonctionné de manière fiable ...
c) et il y a probablement une tonne de petites fonctionnalités qui rompent avec chaque version, c'est donc l'inconvénient de VS.
Solution à ce problème de "source fermée": écrivez l'intégralité des VS en C #, puis autorisez la modification/l'édition du code compilé (au moment de l'exécution, en enregistrant les modifications sous forme de correctif qui est éventuellement chargé au prochain démarrage) sans libérer la source. Cela peut être fait en faisant sortir le décompilateur du code tel qu'il était en entrant. 180 degrés par rapport au fonctionnement des compilateurs natifs. Le binaire devient alors le code source et l'exécutable à la place de ce fouillis de fichiers .cs et de fichiers .exe etc. Il existe des outils tiers qui peuvent presque déjà le faire, donc "modding" les ex # C # est plutôt trivial mais je propose de le prendre pour la conclusion logique: inclure même des commentaires dans les fichiers .exe et .dll. Les fichiers vont toujours être 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 moddé et le binaire optimisé qui l'accompagne sont rebranchés. Même idée que dans le compilateur C # mais poussée plus loin. Étape suivante: Écrivez l'intégralité du système d'exploitation dans cette langue, de sorte que même lorsque Windows est une source fermée, il peut ê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 qu'il est en cours d'exécution. Fermer l'analogie: si vous avez écrit un navigateur Web dans LISP commun, vous pouvez modifier le navigateur Web sans l'arrêter et créer des pages Web dans la même langue que le navigateur.
Un avantage que tous les éditeurs sur console ont sur les éditeurs GUI est qu'ils peuvent être exécutés dans un multiplexeur de terminal tel que écran ou tmux . Pourquoi est-ce bien?
- Il est plus rapide de passer d'une console de multiplexeur de terminal à une autre que de passer d'une console GUI à une autre à l'aide de la souris, ou même en utilisant alt-tab. En effet, les consoles peuvent être nommées et basculées 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 je dois faire du travail à 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 me suis arrêté lorsque j'ai quitté le travail.