¿Qué ganancias de productividad específicas proporciona Vim / Emacs sobre los editores de texto GUI?

Esto no está destinado a ser un troll o un cebo de fuego ni nada de eso. He estado usando Vim como mi editor de consola preferido durante un par de meses (para editar archivos de configuración mientras estoy en mi terminal), pero no creo que pueda soportarlo para mi trabajo diario normal de escribir aplicaciones web. , lo que hago con un editor de texto GUI (que no es importante).

Siento que mi editor de texto GUI puede hacer todo lo que necesito para mi trabajo. Tiene una búsqueda / reemplazo decente con historiales de autocompletar para ambos. Tiene resaltado de sintaxis, numeración de líneas, una interfaz con pestañas, fácil de copiar y pegar, etc. Lo único que le falta a mi editor actual es la coincidencia de expresiones regulares, pero hay muchos editores de texto GUI que buscarán / reemplazarán expresiones regulares.

Teniendo en cuenta lo que acabo de decir, ¿qué ventajas de productividad tiene Vim (o incluso Emacs) sobre un editor de texto GUI además del hecho de que está instalado en todas las computadoras? Me gustaría tareas específicas que sean mejores / más rápidas en Vim / Emacs o que simplemente no sean posibles con los editores de texto GUI existentes.

Para Vim:

• Vim tiene una mejor integración con otras herramientas (comandos de shell, scripts, compiladores, sistemas de control de versiones, ctags, etc.) que la mayoría de los editores. Incluso algo tan simple como :.!canalizar la salida de un comando a un búfer es algo que no encontrará en la mayoría de los editores de GUI.

• Una interfaz con pestañas no es tan agradable como la interfaz de "ventana" que le ofrece Vim / Emacs. Puede ver dos o más archivos al mismo tiempo uno al lado del otro. Cuanto más pueda ver en la pantalla, más liberará su mente para pensar en su problema en lugar de llevar una contabilidad mental de nombres de variables y firmas de funciones.

• No subestime el poder de las expresiones regulares de Vim. Hay muchas extensiones específicas de Vim para hacer coincidir una columna específica, una marca, la posición del cursor, ciertas clases de caracteres (palabras clave, identificadores), etc.

• Integrado diffe grep(independiente de la plataforma para que no necesite descargar y aprender una nueva herramienta cada vez que cambie de computadora).

• El modo de bloque visual (para editar columnas) es algo de lo que carecen muchos editores, pero no puedo vivir sin él. He sorprendido y asombrado a la gente en el trabajo usando solo esto, haciendo algunas ediciones con unas pocas pulsaciones de teclas que, de otro modo, alguien habría pasado diez minutos haciendo manualmente.

• Múltiples registros de copiar / pegar. Cuando solo tienes una, terminas pasando por extrañas contorsiones para evitar golpear el portapapeles. No debería tener que hacerlo.

• El sistema de deshacer / rehacer de Vim es inmejorable. Escriba algo, deshaga, escriba otra cosa y aún podrá recuperar lo primero que escribió porque Vim usa un árbol de deshacer en lugar de una pila. En casi todos los demás programas, el historial de lo primero que escribió se pierde en esta circunstancia.

• Moverse, copiar, pegar y eliminar texto es increíblemente rápido en Vim. Los comandos son simples, pulsaciones de una sola tecla y componibles. Sume todas las veces que hace un resaltado cuidadoso y laborioso del mouse y Ctrl-X, luego reemplácelos todos con unda( (elimine un conjunto de paréntesis coincidentes y todo lo que contienen). Ahorra más tiempo del que piensas

• Las pequeñas cosas, como *buscar la palabra debajo del cursor, o .repetir un comando, o %saltar entre un par de apertura y un cierre. Demasiados de estos para enumerarlos.

• Lenguaje de scripting incorporado y potente mapeo de teclas y capacidad de macros para que el editor pueda ampliarse de cualquier forma que necesite. Toneladas de guiones ya escritos y descargables.

Si observa lo suficientemente de cerca, encontrará que incluso las características que otros editores también tienen, Vim a menudo lo hace mejor. Todos los editores tienen resaltado de sintaxis, pero Vim tiene un archivo de sintaxis para casi todos los formatos de archivo bajo el sol, a menudo con muchas opciones de configuración, y es muy simple escribir el suyo. Muchos editores manejan diferentes codificaciones de archivos, pero Vim le brinda formas muy específicas e infalibles de configurar codificaciones de archivos y convertir entre ellas. Lo primero que me impresionó de Vim es lo perfectamente que maneja las opciones de sangría de tabuladores / espacios y los saltos de línea de Unix / DOS en comparación con otros editores con los que tuve problemas en ese momento.

Muchos de estos puntos se aplican igualmente bien a Emacs (de formas diferentes pero generalmente igualmente poderosas).

(vim es mi veneno; estoy seguro de que emacs ofrece ganancias similares)

La mayor ventaja: no es necesario tocar el mouse.

Para mí, lo más útil es saltar hacia adelante (o justo antes) una letra específica o combinación de letras, o saltar hacia atrás, con un par de pulsaciones de teclas. Saltar hacia adelante por la misma condición dos o diez veces, es simplemente una cuestión de prefijarlo con un número.

Si tiene que repetir una edición, salte hacia adelante hasta ese lugar (2-3 pulsaciones de teclas), luego presione "." para repetir la última edición. Saltar hacia adelante (o hacia atrás) es más fácil (una pulsación de tecla) si se trata de la misma condición de búsqueda.

Básicamente, con un pequeño tiempo de espera, puede aprender diez o veinte atajos de teclado que significan que no tiene que seguir moviendo la mano para agarrar el mouse. Eso le da tres o cuatro veces más movimientos / comandos de edición que lo que haría si tuviera que seguir agarrando el mouse.

Después de unos días, se pondrá de mal humor cada vez que tenga que alcanzar el mouse (o presionar <Down>15 veces), cuando esté en un editor de GUI.

Siempre me pregunté por qué poca gente estaba loca por Vim. Vea el video del usuario avanzado de Vim en acción:

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

Si su editor actual puede hacer lo que está haciendo, ¡no hay necesidad de cambiar! :)

Además, lea este http://www.viemu.com/a-why-vi-vim.html

Después de ver el video y leer ese artículo, no tuve más remedio que comenzar a aprender VIM. Ha pasado casi un año desde que me cambié a VIM y no puedo imaginarme usando nada más.

Creo que uno de los poderes reales de un editor de texto dedicado es la edición de macros. La repetición es dolorosa para muchos programadores, y escribir macros adecuadas puede ser muy entretenido. Si no está haciendo todo a través del teclado, la creación de macros requerirá un conjunto adicional de comandos en lugar de hacer uso de los que ya está usando.

Soy semi-competente con combinaciones de teclas vi, pero prefiero Emacs en general. La razón por la que estos editores tienen seguidores tan fervientes es porque el modelo de edición que proporcionan es más poderoso que los sistemas más nuevos, por lo que proporcionar "combinaciones de teclas vi" o "combinaciones de teclas emacs" no es suficiente, incluso si no está utilizando ninguna función de extensión. o personalizaciones para emacs o vi.

Solo voy a hablar del modelo de Emacs porque lo entiendo mejor. El modelo común para la edición de texto hoy en día implica un búfer de texto, en el que se puede insertar, eliminar, seleccionar y cortar / copiar / pegar texto en el portapapeles del sistema.

Los búferes de Emacs, por supuesto, pueden soportar estas operaciones. Junto con el seguimiento de la posición del cursor para cada ventana en la que están visibles, también realizan un seguimiento de las "marcas" realizadas en ellas. El texto entre el "punto" (posición del cursor) y la "marca" se denomina "región" y corresponde aproximadamente a la selección en los editores convencionales.

La diferencia es que Emacs realiza un seguimiento de las últimas ubicaciones en las que se estableció la marca en el anillo de marcas, y puede regresar a ellas con una pulsación de tecla (o dos, según su configuración). Encuentro esto extremadamente útil, especialmente porque muchos de los comandos de Emacs que cambian su ubicación en el búfer establecen la marca en su ubicación anterior. Un ejemplo es cuando estoy editando un módulo de Python y necesito agregar una declaración de importación en la parte superior del archivo. La pulsación de tecla para ir a la parte superior del búfer (Alt- <) establece la marca. Agrego la declaración de importación. Presiono Ctrl-u Ctrl-Espacio y vuelvo a donde empecé. También puedo seguir haciendo esto para volver a las posiciones anteriores. (Tal vez necesitaba seleccionar algo de texto al agregar esa declaración de importación).

La otra diferencia (y más conocida) de Emacs es el kill ring. La mayoría de las pulsaciones de teclas para eliminar texto del búfer guardan el texto en el kill ring, que luego se puede recuperar con el comando "yank" (Ctrl-y). La característica esencial es que los comandos de yank posteriores recuperan el texto muerto más antiguo. Por lo tanto, puede eliminar varias secciones de texto seguidas y luego recuperarlas en orden. También puede recorrer el círculo de la muerte con Alt-y después de un tirón, eliminando el texto recuperado e insertando la siguiente entrada en el anillo.

Emacs tenía estas características en 1978. El único otro sistema importante que las adoptó hasta cierto punto es NeXTStep (y ahora heredado por Cocoa). Otras herramientas proporcionan más funciones para tareas específicas, pueden extenderse en lenguajes mucho más fáciles de usar que Emacs Lisp y tienen interfaces visuales más agradables ... pero Emacs sigue siendo mejor en la edición de texto. Por eso, una vez que sepa cómo usarlo, es tan difícil dejar de fumar.

Esta no es exactamente una tarea específica, pero para personas que incluso podrían estar sufriendo de RSI, el hecho de que sus manos nunca abandonen el teclado en vim es casi invaluable. De hecho, terminé volviéndome zurdo con el mouse en el trabajo porque me permitió mover menos la mano para alcanzar el mouse (mi teclado en casa no tiene un teclado numérico, por lo que puedo mantenerlo a la derecha).

Otro pequeño beneficio fue que, IIRC, el vi original fue diseñado para acelerar la edición de archivos a través de una conexión remota terriblemente lenta. De acuerdo, eso no sucede tanto hoy, pero si tiene una conexión lenta, buena suerte ejecutando un editor de texto de interfaz gráfica de usuario y que responda.

Para mí las cosas de la gran productividad son

• Puedo hacer casi todo desde el teclado.
• Macros potentes.
• En mis 20 años de carrera con 9 sistemas operativos, las combinaciones básicas del teclado no han cambiado. Puedo utilizar casi cualquier sistema y ya conozco el editor.
• Ya se ha agregado prácticamente cualquier característica que pueda desear en un editor de texto.

Una cosa que realmente me gusta de vim es el comando "repetidor". Básicamente, al presionar .en el modo de comando, repite su última acción. Este es solo un ejemplo de características realmente interesantes que tienen los "editores de texto para programadores" y que a menudo no tienen las GUI.

En mi experiencia, las principales ganancias de productividad que brindan vim y emacs (yo mismo soy una persona vim, pero emacs seguramente es similar) son:

• Usted puede tener las características que proporcionan entornos de desarrollo modernos (como ciclos de una sola pulsación de tecla run-edit-acumulación y documentación en línea y terminación de pestaña y otras cosas), pero no tiene que . ¿La ganancia de productividad? Ves solo lo que quieres ver. En mi experiencia, los IDE no hicieron que las personas fueran más productivas, también porque mostraban demasiada información (todo tipo de navegadores). Esta "potencia extra, cuando la necesita, pero no antes" es una gran ganancia de productividad en mi humilde opinión.

• Los editores son muy populares entre los programadores, lo que significa que hay enormes repositorios de scripts, libros y grupos de usuarios disponibles.

• En mi experiencia (solo puedo hablar en nombre de vim aquí) el usuario medio de vim es un ingeniero de software bastante bueno. No sé por qué es eso (o tal vez solo tengo suerte), pero tal vez las personas que tomaron la barrera de acostumbrarse a una herramienta 'antigua' como emacs o vim tienen la dedicación adecuada (y el contacto con otras personas como esa ). Tal vez sea un efecto indirecto de estos editores, pero salir con otras personas de vim (o emacs) en, por ejemplo, IRC resultó ser bastante interesante, ya que las mismas personas también estaban bastante interesadas en todo tipo de cuestiones de ingeniería de software (o ciencias de la computación). . Estos editores parecen atraer cierto tipo de personalidad. :-)

La "ganancia de productividad" que obtengo por usar un clon ligero de emacs para programas pequeños es que se inicia como un rayo engrasado. Por lo general, puedo ejecutar un programa de prueba rápida en C # antes de que Visual Studio haya terminado de cargar una solución "sandbox".

Por supuesto, podría dejar Visual Studio abierto (u otro VS abierto si estoy trabajando en él en ese momento) pero luego se cambiaría si lo dejara inactivo por un tiempo, etc.

Para cualquier cosa de cualquier tamaño significativo, o si no conozco la API que estoy usando bastante bien, un IDE es el camino a seguir, en mi opinión.

Yo uso gvim para Windows, así que técnicamente es un editor de texto GUI, pero es vim ..

Para mejorar la productividad, encuentro:

1. Nunca tengo que usar el mouse, por lo tanto, soy más rápido.
2. buscar, reemplazar, copiar / pegar, etc.son más rápidos con combinaciones de teclas vim frente a los movimientos del mouse (una vez que se superó la curva de aprendizaje)
3. Como se mencionó en los comentarios anteriores, los RSI se reducen significativamente. Mis muñecas me han agradecido desde que me mudé a vim.
4. es ligero y rápido

Ya sabes, para vi creo que se trata de tener un modo de inserción y comando. Si bien puede parecer un retroceso a una época en la que no se podía depender del cursor o de las teclas especiales, lo que realmente significa es que muchos comandos poderosos de movimiento y manipulación de texto son una cantidad mínima de pulsaciones de teclas. La codificación productiva no se trata de la entrada de texto masivo (el valor predeterminado en los editores "modernos") sino de una ráfaga de texto masivo seguida de pequeños ajustes considerables e incluso períodos de navegación más largos.

Esto pasó a primer plano para mí personalmente al usar vi en una red de campus de alta latencia. Fácilmente podría obtener 10 o 15 caracteres antes de la respuesta. Con vi pude predecir cómodamente dónde me dejarían esos comandos y podría trabajar a velocidades casi normales. Esta pericia retorcida es un beneficio continuo en condiciones normales: menos capacidad intelectual visual dedicada a la retroalimentación gráfica constante.

Los aceleradores de búsqueda de palabras comunes * y # son excelentes para hojear el código. Y el% para hacer coincidir los paréntesis es extremadamente útil. Seguro, apenas parece mucho comparado con ctl-] pero la mitad de las pulsaciones se suman.

Personalmente, uso winvi, que agrega un par de cosas importantes que estoy seguro de que vim también tiene. Un salto rápido al modo hexadecimal resuelve muchos problemas de texto de "qué diablos está pasando". Y el manejo completamente flexible de los finales de línea es un regalo del cielo que se ha convertido en una característica esperada para un editor de texto. Finalmente, puede abrir cualquier archivo sin importar su contenido. Esto equivale a una habilidad de piratería de élite de primer orden.

En Unix puede capturar rápidamente la salida del programa o incluso filtrar secciones de su archivo a través de comandos externos. Una función extremadamente poderosa pero creo que subutilizada.

Utilizo Vim con bastante frecuencia. Sin embargo, no reemplaza a UltraEdit para mí. Dado que se han enumerado muchos aspectos positivos, supongo que iré contra la corriente y enumeraré algunas molestias con Vim.

• Manejo de FTP débil. "Ordeno" muchos sitios, y no poder navegar y editar archivos fácilmente en un servidor FTP remoto es una gran deficiencia para mí. NWRead no es suficientemente bueno.
• La rareza de la consola heredada de los problemas generales de la terminal que parece plagar Linux. Yo suelo usar PuTTY para conectarme a mi caja de Linux (con Ubuntu) y, por alguna razón, las teclas de flecha se asignan a A / B / C / D en el modo de inserción (y todos los problemas de soporte de color). En gVim, ctrl-tab se puede asignar a "bn" fácilmente, pero no en el modo de consola, estos problemas abundan.
• Las opciones de búsqueda / reemplazo son muy débiles en cuanto a interfaz. Tener que escribir todo en una sola línea no es suficiente. Siento que el diálogo mucho más elaborado en, digamos, UltraEdit me da mucho más poder al final, incluso si el soporte real de expresiones regulares puede ser mucho más débil.
• Demasiado fuerte dependencia de los diseños de teclado de EE. UU. Muchas de las teclas que se utilizan para funciones primarias, como `, no se imprimen en mi distribución de teclado danés (y están ubicadas en el arca, lo mismo que $, y muchas otras). Hace que sea bastante incómodo utilizar algunas funciones.

Escritorio remoto muestra rápidamente solo la aplicación nativa de Windows. Intentamos usar Eclipse para desarrollar en Unix. ¿Y sabes qué? Ni siquiera fue posible.

La segunda razón es que podríamos extender nuestro Vims y Emacs para hacer todas las tareas específicas del proyecto desde la exploración de DB de una manera especial para resaltar y autocompletar nuestro propio metalenguaje.

Yo diría que una de las grandes ventajas es la extensibilidad del editor vim. Si quiero que algo funcione con CVS, puedo tomar el complemento CVSMenu y agregarlo a mi editor para obtener esa funcionalidad.

Lo mismo ocurre con el resaltado de sintaxis, el comportamiento con archivos específicos, etc. Todo tipo de cosas se pueden personalizar en vim.

No estoy tan seguro de poder hacer eso tan fácilmente en los editores de tipo GUI.

Grabar y reproducir en VIM es inmejorablemente impresionante, lo que es muy poco probable que encuentre en herramientas basadas en GUI.

Además, el incremento / decremento automático le brinda capacidades de generación de datos sin necesidad de escribir programas para ello.

Había sido un usuario inconexo de Emacs durante años. Pero nunca me metí realmente en eso. Luego comencé a aprender Clojure (mi primer Lisp) y descubrí ParEdit.

Y eso me voló la cabeza.

(Vea aquí algunos ejemplos: https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit es la experiencia de edición más increíble que he tenido. Nada más se acerca. Lisp ya no es un lenguaje incómodo de escribir, lo que me obliga a preocuparme por equilibrar muchos paréntesis tontos e irritantes. Con ParEdit, la estructura Lisp coherente se convierte en una gran ventaja para trabajar, ya que las mismas transformaciones de árbol (sorber, vomitar, dividir y unir) funcionan en todas partes, en estructuras de control y estructuras de datos por igual. Y ParEdit evita que cometa errores estúpidos. Es casi imposible cometer errores de sintaxis.

Y a diferencia de Eclipse, esta no es una laboriosa verificación en tiempo real que siempre se ejecuta en segundo plano, quemando mi procesador. No cuesta nada ... ParEdit simplemente hace el cambio estructural correcto cuando lo pido.

(En general, Emacs es tan rápido como debe ser. A diferencia de Eclipse, que es como escribir pegamento).

Lo siguiente que descubrí fue Yasnippet ( http://emacswiki.org/emacs/Yasnippet ). Una vez más, no había usado nada como esto antes. No es simplemente una macro para agregar texto estándar, sino una forma dinámica y navegable.

El placer final es darme cuenta de que si quiero extender esto yo mismo, para tener más de estas herramientas de productividad de alto nivel, tengo el poder de Lisp para trabajar.

(Mi experiencia es de algunos años con Visual Studio y otros IDE, luego 15 años de Vim y los últimos 6 meses con Emacs).

Longevidad : Vim / Emacs son FOSS y han existido durante décadas. Su uso no disminuirá, ni sus características se romperán / desaparecerán / cambiarán mucho, por lo que puede confiar en construir el núcleo de su caja de herramientas de carrera en torno al dominio de un solo editor.

Acceso remoto / ubicuo en terminales : aunque ambos tienen buenos sistemas para editar archivos remotos, también puede instalarlos en cualquier sistema en el que inicie sesión.

Desarrollo impulsado por REPL : ambos tienen modos "SLIME" en varias formas que integran cualquier tipo de REPL con el que esté trabajando. Por ejemplo, nunca me he encontrado con un desarrollo iterativo tan poderoso como el proporcionado por CIDER .

Linting : sea cual sea el lenguaje que esté utilizando, probablemente tenga algunas herramientas de linting , ya sea integradas en el compilador o en una herramienta externa. Estos se integran perfectamente con Emacs / Vim, mostrando sus errores de codificación casi en tiempo real.

Gramática de los comandos mnemotécnicos : aunque ambos requieren algo de tiempo para aprender, estos editores cuentan con famosos sistemas inteligentes para acceder, e incluso recordar, miles de comandos con unas pocas pulsaciones y combinaciones de teclas. Estos pueden eliminar por completo cualquier necesidad de usar un mouse si así lo desea.

Sistemas de ayuda integrados : la documentación fuera de línea de muchos idiomas y sus API es común encontrarla incorporada en estos editores, y es accesible de formas igualmente simples a los amplios y completos sistemas de ayuda que ofrecen. Se ha agregado la función de autocompletar para la mayoría de los idiomas comunes. Además, hay una gran cantidad de ayuda para la discusión sobre prácticamente cualquier tema de ayuda.

Navegación : etiquetas, me gusta de paredit, marcas, ventanas, pestañas, saltos de vim-rails y muchos más elementos integrados.

Gestores de paquetes / repositorios : Emacs tiene algunos (elpa, melpa, mermelada) y los de Vim también son buenos (vundle, patógeno, etc. ). No conozco ninguna comunidad alrededor de IDE que ofrezca algo comparable a estos. Veo más de 5,000 paquetes con package-list-packages .

Más allá de la edición : Emacs llega más lejos aquí con la capacidad de leer noticias, navegar por la web, administrar el correo electrónico, editar hojas de cálculo, crear presentaciones y organizar cualquier cosa.

Todo lo demás integrado: depuradores, sincronización del navegador, compilación, shells, ejecución de pruebas.

Infinitamente personalizable : Elisp es un lenguaje muy poderoso para extender / modificar Emacs. VimL es el equivalente de Vim. Hay libros escritos sobre ambos. ¡Modifique los temas y comportamientos de color para su deleite!

Una ventaja que tienen todos los editores basados ​​en consola sobre los editores de GUI es que se pueden ejecutar en un multiplexor de terminal como screen o tmux . ¿Por qué es bueno esto?

• Es más rápido cambiar de una consola multiplexora de terminal a otra que cambiar de una consola GUI a otra usando el mouse, o incluso usando alt-tab. Esto se debe a que las consolas se pueden nombrar y cambiar escribiendo algunos caracteres del nombre.
• Si sus sesiones de editor están en las consolas de un multiplexor de terminal, puede acceder a ellas desde cualquier máquina. Si necesito trabajar desde casa, puedo usar SSH en mi caja, conectar el multiplexor de terminal que ya está en ejecución a mi sesión SSH y estar justo donde lo dejé cuando dejé el trabajo.

Como vim / emacs suelen ser utilizados por programadores y como usuario de C # desde 2003, a partir de este punto de vista de sesgo, es justo hacer esta comparación injusta (otra podría ser VS C ++ con Visual Assist X vs C ++ en vim / emacs):

Para C # y Visual Studio:

1. Acabo de contar la cantidad de pulsaciones de teclas para esta línea:

       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. Leí acerca de la función emacs para saltar en el código. No creo que tenga una característica exactamente como esa. Sin embargo, tiene una característica similar. Aquí está la desventaja de VS. Hay muchas funciones pequeñas, pero con el tiempo dejan de funcionar. La última vez que verifiqué que la función de salto no funcionaba, eso fue hace un par de años. VS introdujo una nueva función de salto gráfico que he estado usando en su lugar. Requiere mouse o toque.

3. Aquí es donde gana emacs / vi. Si tiene que saltar mucho en el código, las características de VS para esto no existen o no se han probado lo suficiente.

El problema con la navegación GUI basada en mouse es que

a) al igual que sentarse en una posición muy estática, puede ser malo, si es así, los ratones tienden a hacer que sus dedos también estén en una posición estática. Mi dolor de muñeca desapareció con el cambio a trackball. Primero probé el mouse vertical pero no solucionó el problema.

b) Mi teclado ideal tendría 2 filas de teclas de función, sin teclado numérico, por lo que podría colocar el trackball más cerca, lo que hace que la distancia de salto sea más soportable.

Sin embargo, en última instancia, si desea saltar entre algunos lugares específicos, está claro que el "anillo de marca" es más efectivo. VS tiene algo en ese sentido ... la última vez que lo usé, simplemente no funcionó de manera confiable ...

c) y es probable que haya un montón de pequeñas características que se rompen con cada lanzamiento, por lo que esta es la desventaja de VS.

Solución a este problema de "código cerrado": escriba el VS completo en C # y luego permita modificar / editar el código compilado (en tiempo de ejecución, guardando los cambios como parche que se carga opcionalmente en el próximo inicio) sin liberar el código fuente. Esto se puede hacer haciendo que el descompilador genere el código tal como estaba al entrar. 180 grados de cómo funcionan los compiladores nativos. El binario luego se convierte en el código fuente y el ejecutable en lugar de este lío de archivos .cs y archivos .exe, etc. Existen herramientas de terceros que casi pueden hacer esto ya, por lo que "modificar" C # exe es bastante trivial, pero propongo llevar esto a la conclusión lógica: incluya incluso comentarios en el .exe y .dll. Los archivos seguirán siendo pequeños en comparación con las aplicaciones C / C ++ compiladas. ¿Mejoramiento? También puede incluir código optimizado previamente. Cuando el modder modifica el exe mientras la aplicación se está ejecutando, el "AST" no modificado y el binario optimizado que lo acompaña se vuelven a conectar. La misma idea que en el compilador de C # pero llevada más lejos. Siguiente paso: escriba todo el sistema operativo en este idioma, de modo que incluso cuando Windows sea de código cerrado, pueda modificarse trivialmente ya que el código fuente viene con cada binario. Sin configurar entornos, compilar, vincular. Simplemente modifique el sistema operativo mientras se está ejecutando. Analogía cercana: si escribió un navegador web en Common Lisp, podría editar el navegador web sin detenerlo y crear páginas web en el mismo idioma que el navegador. se puede modificar trivialmente ya que el código fuente viene con cada binario. Sin configurar entornos, compilar, vincular. Simplemente modifique el sistema operativo mientras se está ejecutando. Analogía cercana: si escribió un navegador web en Common Lisp, podría editar el navegador web sin detenerlo y crear páginas web en el mismo idioma que el navegador. se puede modificar trivialmente ya que el código fuente viene con cada binario. Sin configurar entornos, compilar, vincular. Simplemente modifique el sistema operativo mientras se está ejecutando. Analogía cercana: si escribió un navegador web en Common Lisp, podría editar el navegador web sin detenerlo y crear páginas web en el mismo idioma que el navegador.