¿Piensas/escribes de manera diferente en vim y emacs?

Question

En muchas secuencias de comandos que escribo, a menudo construyo programas en un "estilo funcional". Es decir, básicamente defino muchas funciones al principio y luego las aplico. Esto se traduce en una secuencia de llamadas a funciones anidadas, en el que escribo a cabo:

1. nombre de la función
2. sus argumentos
3. siguiente nombre de la función
4. sus argumentos

... y así en.

Para los casos en que las funciones se "interconectan" juntas, la salida de una función es un argumento (generalmente el primero, pero no siempre) para la siguiente función, cuyo resultado es un argumento para la siguiente función, y indefinidamente. En la notación de prefijo, los movimientos de tecla pueden ser muy nerviosos si escribe esta secuencia de izquierda a derecha. Por ejemplo, ¿cómo escribirías la segunda línea del siguiente ejemplo de [Python] (~ mul ~ es multiplicar, ~ truediv ~ es dividir)?

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

Si tuviera que escribir el mismo conjunto de operaciones de forma lineal (de izquierda a escribir, sin saltar), estoy más probable que utilice la notación de la composición de funciones. Sobre la base de mi ejemplo anterior en Python, podría escribir

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

Creo que esto se debe a que asocio cada función con sus propios argumentos y prefiere escribir a cabo de forma sucesiva, en lugar de llenar los argumentos a otra función antes del argumento la lista para la primera función está completa (como se necesitaría para escribir el primer ejemplo de izquierda a derecha).

Lo noté porque he sido un usuario de emacs durante mucho tiempo y recientemente probé viper/vimpuse y vim. En emacs, podría hacer algo como

1. [nombre de función y los argumentos]
2. Ca
3. [siguiente tipo de nombre de función]
4. Ce
5. [llene resto de argumentos]
6. Ca
7. [siguiente tipo de nombre de la función]
8. Ce
9. [llene resto de argumentos]

... y así sucesivamente, con el uso ocasional de Mb, Mf, M-DEL (backward-word, palabra hacia adelante, hacia atrás-kill-word) si me lío arriba u olvida algo.

Hace poco se enteraron de Co en vim, que es un salvavidas - pero me parece que las claves equivalentes serían

1. [nombre del tipo de función y argumentos]
2. Co 0
3. [Tipo siguiente nombre de la función]
4. Co $
5. [rellenar resto de argumentos]
6. Co 0
7. [siguiente tipo de nombre de función]
8. C-O $
9. [llene resto de argumentos]

... y el resto; Los equivalentes de palabra hacia atrás, palabra directa y palabra de destino hacia atrás serían C-o b y C-o w, y C-w.

Esto me hizo pensar que para programar en vim, puede que tenga que hacer crecer una memoria de trabajo más grande, de modo que pueda detener la construcción de una función cuando complete otra, y así sucesivamente hasta la pila. Además, en la construcción de documentos de texto, me parece que edito (matar, copiar, tirar) con bastante frecuencia incluso antes de terminar un pensamiento completo, que no es tan fácil para el estilo operativo de vim de "permanecer en modo normal, ráfaga de texto en inserción -mode, y de vuelta al modo normal ", que parece suponer que soy capaz de producir algo que valga la pena editar durante mis incursiones en modo inserción. Para usar vim, me parece que delibere más mientras escribo para reducir la frecuencia de cambio de modo. ¿Esto es porque soy naturalmente espástico, o una vez que domino o comprometo un rango adecuado de comandos de teclas vim para la memoria muscular, dejaré de pensar que son tan diferentes?

Si programa tanto en emacs como en vim, ¿se encuentra pensando y construyendo sus programas y bloques de texto de manera diferente en cada editor?

Answer 1

Utilicé vi desde los buenos tiempos de 1992 y ahora uso Emacs desde 2001. No he notado ninguna diferencia en mi forma de pensar al programar funciones y bloques de código. Ambos editores tienen sus propias peculiaridades y formas de hacer las cosas, pero no son tan fuertes que puedan cambiar su forma de pensar y cómo se programa.

Siempre he tratado de encontrar formas de hacer lo que pretendo hacer. No dejo que mi editor me obligue a hacer algo que no quiero. Cuando hago la programación de procedimiento de una nueva pieza de código, utilizo la técnica llamada "ilusión" que es mentioned in Structure and Interpretation of Computer Programs:

Te imaginas en el mundo perfecto teniendo todos los procedimientos que necesitas a tu disposición. Codifica su algoritmo con todas las funciones útiles que necesitará implementar, pero que solo tiene prototipos por el momento. Es similar a un enfoque de arriba hacia abajo.