Pensez-vous/écrivez-vous différemment dans vim et emacs?

Question

Dans beaucoup de scripts que j'écris, je construis souvent des programmes dans un "style fonctionnel". C'est-à-dire que je définis fondamentalement beaucoup de fonctions au début, puis j'applique ces fonctions plus tard. Il en résulte une séquence d'appels de fonction imbriqués, où je taper:

1. nom de la fonction
2. ses arguments
3. suivant Nom de la fonction
4. ses arguments

... et sur. Pour les cas où les fonctions sont "canalisées" ensemble, la sortie d'une fonction est un argument (généralement le premier, mais pas toujours) à la fonction suivante, dont la sortie est un argument à la fonction suivante, et À l'infini. En notation de préfixe, les mouvements de clé peuvent être très nerveux si vous tapez cette séquence de gauche à droite. Par exemple, comment tapez-vous la deuxième ligne de l'exemple [Python] suivant (~ mul ~ est multiplier, ~ truediv ~ est divide)?

from operator import add, mul, truediv 
print(truediv(mul(add(1,1),2),4)) 

Si je devais écrire le même ensemble d'opérations linéaire (de gauche à écrire, sans sauter autour), je suis plus susceptibles d'utiliser la notation de la composition de la fonction. Construire sur mon exemple précédent en Python, je pourrais écrire

from functional import foldr, compose, partial, flip 
print(foldr(compose,add,(partial(mul,2),partial(flip(truediv),4)))(1,1)) 

Je pense que c'est parce que j'associe chaque fonction avec ses propres arguments et préfère les taper successivement, plutôt que de remplir des arguments à une autre fonction avant l'argument La liste de la première fonction est complète (comme cela serait nécessaire pour taper le premier exemple de gauche à droite).

Je l'ai remarqué parce que je suis un utilisateur d'emacs depuis longtemps et que j'ai récemment essayé viper/vimpuse et vim. Dans emacs, je pourrais faire quelque chose comme

1. [nom de la fonction de type et arguments]
2. Ca
3. [deuxième type nom de la fonction]
4. Ce
5. [remplissage en reste d'arguments]
6. Ca
7. [deuxième type nom de la fonction]
8. Ce
9. [remplissage en reste d'arguments]

... et ainsi de suite, avec une utilisation occasionnelle de Mo, Mf, M-DEL (arrière-mot, avant-mot, mot-backward-kill) si je pagaille ou oublie quelque chose.

J'ai récemment découvert à propos de Co dans vim, qui est une bouée de sauvetage - mais je trouve que les clés équivalentes seraient

1. [nom de la fonction de type et arguments]
2. Co 0
3. [Type suivant le nom de la fonction]
4. Co
5. $ [remplir reste d'arguments]
6. Co 0
7. [deuxième type nom de la fonction]
8. C-o
9. $ [remplir en reste d'arguments]

... et le reste; les équivalents de mots en arrière, de mots en avant et de mots en arrière seraient C-o b et C-o w, et C-w. Cela m'a amené à penser que pour programmer dans vim, je devrais peut-être développer une plus grande mémoire de travail, de sorte que je puisse mettre en pause la construction d'une fonction en remplissant une autre, et ainsi de suite dans la pile. Aussi, en construisant des documents texte, je trouve que je modifie (tuer, copier, arracher) assez souvent avant même de terminer une pensée complète, ce qui n'est pas si facile pour le style opérationnel de vim de rester en mode normal, -mode, et retour au mode normal ", ce qui semble présumer que je suis capable de produire quelque chose qui vaut la peine d'être édité pendant mes incursions en mode insertion. Pour utiliser vim, je trouve que je délibère plus que je tape pour réduire la fréquence de commutation entre les modes. Est-ce parce que je suis naturellement spasmodique, ou une fois que je maîtrise ou que je commets une gamme appropriée de commandes vim pour la mémoire musculaire, je vais cesser de penser qu'ils sont si différents?

Si vous programmez à la fois dans emacs et dans vim, pensez-vous que vous pensez et construisez différemment vos programmes et blocs de texte dans chaque éditeur?

Answer 1

J'ai utilisé vi depuis le bon vieux temps de 1992 et maintenant j'utilise Emacs depuis 2001. Je n'ai pas remarqué de différence dans ma façon de penser en programmant des fonctions et des blocs de code. Les deux éditeurs ont leurs propres particularités et façons de faire, mais ils ne sont pas si forts qu'ils pourraient changer votre façon de penser et de programmer.

J'ai toujours essayé de trouver des façons de faire ce que j'ai l'intention de faire. Je ne laisse pas mon éditeur me forcer à faire quelque chose que je ne veux pas. Quand je fais la programmation procédurale d'un nouveau morceau de code, j'utilise la technique appelée "wishful thinking" qui est mentioned in Structure and Interpretation of Computer Programs:

Vous vous imaginez dans le monde parfait en ayant toutes les procédures dont vous avez besoin à votre disposition. Vous codez votre algorithme avec toutes ces fonctions utiles que vous devrez implémenter mais que vous n'avez que des prototypes pour le moment. C'est semblable à une approche descendante.