texto editores editar consola con archivos vim emacs text-editor

editar - ¿Qué mejoras de productividad específicas ofrece Vim/Emacs sobre los editores de texto GUI?



vim editor de texto (20)

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

La mayor ganancia: sin necesidad de tocar el mouse.

Para mí, lo más útil es saltar hacia adelante (o justo antes) de una letra específica o combinación de letras, o saltar hacia atrás, con un par de teclas. Saltar 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 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 es la misma condición de búsqueda.

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

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

Esto no se entiende como un troll o flamebait o algo por el estilo. He estado usando Vim como mi editor de consola de elección durante un par de meses (para editar archivos de configuración mientras estaba en mi terminal), pero no creo que pueda soportarlo por mi trabajo diario normal de escribir aplicaciones web , lo cual hago con un editor de texto GUI (cuál 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 autocompletado para ambos. Tiene resaltado de sintaxis, numeración de líneas, una interfaz con pestañas, copiar y pegar fácilmente, etc. Lo único que me falta de mi editor actual es la coincidencia de expresiones regulares, pero hay muchos editores de texto GUI que harán la búsqueda / reemplazo de expresiones regulares.

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


Como vim / emacs a menudo son utilizados por programadores y como usuarios de C # desde 2003, desde este punto de vista es justo hacer esta comparación por lo demás injusta (otro 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 teclas presionadas 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 de emacs para saltar en el código. No creo que tenga una característica exactamente así. Tiene una característica similar sin embargo. Aquí está la desventaja de VS. Hay muchas características pequeñas pero con el tiempo dejan de funcionar. La última vez que revisé la función de salto no funcionó, pero eso fue hace un par de años. VS introdujo una nueva característica gráfica de salto que he estado utilizando en su lugar. Requiere mouse o toque.

  3. Aquí es donde ganan 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 con GUI basada en el 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 estén también en posición estática. Mi dolor de muñeca se fue con el cambio a trackball. Primero probé el mouse vertical pero no hizo nada por el problema.

b) Mi teclado ideal tendría 2 filas de teclas de función, sin teclado numérico, para poder colocar la bola de seguimiento más cerca, hace que la distancia de salto sea más llevadera.

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

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

Solución a este problema de "fuente cerrada": 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 la fuente. Esto se puede hacer haciendo que el descompilador muestre el código tal como estaba al entrar. 180 grados de cómo funcionan los compiladores nativos. El binario se convierte entonces en el código fuente y el ejecutable en lugar de este desorden de archivos .cs y archivos .exe, etc. Existen herramientas de terceros que ya casi pueden hacer esto, por lo que "modificar" C # exe es bastante trivial, pero propongo llevar esto a la conclusión lógica: incluir incluso comentarios en .exe y .dll. Los archivos seguirán siendo pequeños en comparación con las aplicaciones compiladas de C / C ++. ¿Mejoramiento? También podría incluir un código preoptimizado. Cuando modder modifica el exe mientras se ejecuta la aplicación, el "AST" no modificado y el binario optimizado que lo acompaña se vuelven a enchufar. La misma idea que en el compilador de C #, pero se lleva más allá. Siguiente paso: escriba todo el sistema operativo en este idioma, de modo que incluso cuando Windows sea de código cerrado, se modifique de manera trivial ya que el código fuente viene con cada archivo binario. Sin entornos de configuración, compilación, vinculación. Simplemente modifique el SO mientras se está ejecutando. Cerrar la analogía: si escribió el navegador web en Common Lisp, podría editar el navegador web sin detenerlo y construir páginas web en el mismo idioma que el navegador.


Creo que uno de los poderes reales de un editor de texto dedicado es la edición macro. La repetición es dolorosa para muchos programadores, y escribir macros adecuadas puede ser 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 utilizar los que ya está utilizando.


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

  • Puede tener las funciones que proporcionan los IDE modernos (como ciclos de edición, compilación y ejecución con una sola pulsación, documentación en línea y completación de pestañas, etc.) pero no es necesario. La ganancia de productividad? Usted ve solo todo lo que quiere ver. En mi experiencia, los IDE no hacían que las personas fueran más productivas, también porque mostraban demasiada información (todo tipo de navegadores). Este "poder extra, cuando lo necesitas, pero no antes" es una 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.

  • Según mi experiencia (aquí solo puedo hablar de vim), el usuario medio de vim es un buen ingeniero de software. No sé por qué eso es (o tal vez tengo suerte), pero tal vez las personas que tomaron la barrera de acostumbrarse a una herramienta "vieja" como emacs o vim tienen la dedicación correcta (y el contacto con otras personas como esa ) Tal vez es un efecto indirecto de estos editores, pero salir con otras personas 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 problemas de ingeniería de software (o informática) . Estos editores parecen atraer cierto tipo de personalidad. :-)


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

La segunda razón es que podríamos extender nuestros Vims y Emacs para realizar todas las tareas específicas del proyecto desde la búsqueda de bases de datos de una manera especial para resaltar y completar automáticamente nuestro metalenguaje propio.


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

Otra ventaja pequeña 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. Es cierto que hoy en día no ocurre tanto, pero si tienes una conexión lenta, buena suerte ejecutando un editor de texto gui y teniendo que responder.


Grabar y reproducir en VIM es increíblemente impresionante, que es muy poco probable que encuentre en herramientas basadas en GUI.

También el incremento / disminución automática le da capacidades de generación de datos sin escribir programas para ello.


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

Y eso me dejó sin palabras.

(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 para escribir, lo que me obliga a preocuparme por equilibrar muchos paréntesis tontos e irritantes. Con ParEdit, la estructura consistente de Lisp se convierte en una gran ventaja para trabajar, ya que las mismas transformaciones de árbol (sorber, barrer, dividir y unir) funcionan en todas partes, tanto en las estructuras de control como en las de datos. Y ParEdit me impide cometer errores estúpidos. Se vuelve casi imposible hacer errores de sintaxis.

Y a diferencia de Eclipse, esto 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 en cola).

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

El placer final es la constatación de que si quiero extender esto por mi cuenta, tener más de estas herramientas de productividad de alto nivel, tengo el poder de Lisp para trabajar con ellas.


La "ganancia de productividad" que obtengo al usar un clon ligero de emacs para programas pequeños es que se inicia como un rayo engrasado. Normalmente puedo eliminar un programa de prueba rápido en C # antes de que Visual Studio haya terminado de cargar una solución de "recinto de seguridad".

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 un tamaño significativo, o si no conozco la API que estoy usando bastante bien, un IDE es el camino a seguir, IMO.


Para Vim:

  • Vim tiene una mejor integración con otras herramientas (comandos de shell, scripts, compiladores, sistemas de control de versiones, etiquetas, etc.) que la mayoría de los editores. Incluso algo simple como :.! , para 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 bonita como la interfaz "en ventana" que Vim / Emacs le ofrece. Puede ver dos o más archivos al mismo tiempo, uno al lado del otro. Mientras más pueda ver en la pantalla, más liberará su mente para pensar sobre su problema en lugar de hacer una contabilidad mental de nombres de variables y firmas de funciones.

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

  • Integrated diff and grep (plataforma independiente) por lo que no necesita descargar y aprender una nueva herramienta cada vez que cambia de computadora.

  • El modo de bloque visual (para editar columnas) es algo que muchos editores no tienen, pero no puedo vivir sin él. He impresionado y atemorizado a la gente en el trabajo usando solo esto, haciendo algunas ediciones en unas pocas pulsaciones de tecla que alguien de otra manera habría pasado diez minutos haciendo manualmente.

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

  • El sistema de deshacer / rehacer de Vim es inmejorable. Escriba algo, deshaga, escriba algo más, y aún puede recuperar lo primero que escribió porque Vim usa un árbol de deshacer en lugar de una pila. En casi cualquier otro programa, la historia de lo primero que escribió se pierde en esta circunstancia.

  • Moverse, copiar, pegar y borrar texto es increíblemente rápido en Vim. Los comandos son simples, presionan una sola tecla y son compostables. Sume todas las veces que haga un punteo del mouse cuidadoso y laborioso y Ctrl-X, luego reemplácelos con un da( (elimine un conjunto de parens que coincidan y todo lo que contiene). Ahorra más tiempo del que pensaría

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

  • Lenguaje de scripting incorporado y potente mapeo de teclas y capacidad macro para que el editor se pueda extender de la forma que necesite. Toneladas de scripts ya escritos y descargables.

Si te fijas bien, verás 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 de escribir el suyo. Muchos editores manejan bien las diferentes codificaciones de archivos, pero Vim te brinda formas muy específicas e infalibles de configurar las codificaciones de archivos y convertirlas. Lo primero que me impresionó de Vim es lo perfectamente que maneja las opciones de sangría de tab / espacio 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 (en formas diferentes pero usualmente igualmente poderosas).


Para mí, la gran productividad es

  • Puedo hacer casi todo desde el teclado.
  • Potentes macros.
  • En mis 20 años de carrera usando 9 sistemas operativos, las conexiones básicas del teclado no han cambiado. Puedo saltar sobre casi cualquier sistema y ya conozco mi camino alrededor del editor.
  • Casi todas las características que pueda desear en un editor de texto ya se han agregado.

Siempre me pregunté por qué pocas personas se preocupaban por Vim. Vea el video de Vim power user 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 esto 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 cambié a VIM y no puedo imaginarme usando cualquier otra cosa.


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

Solo voy a hablar sobre el modelo de Emacs porque lo entiendo mejor. El modelo común para la edición de texto en la actualidad consiste en un buffer de texto, en el que el texto se puede insertar, eliminar, seleccionar y cortar / copiar / pegar en el portapapeles del sistema.

Los búfers de Emacs, por supuesto, pueden admitir 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 llama "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 marca, y puede volver a ellas con una pulsación de tecla (o dos, según su configuración). Encuentro esto extremadamente útil, especialmente porque muchos 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 al principio 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-Space y regreso donde comencé. Puedo seguir haciendo esto para volver a las posiciones anteriores también. (Tal vez tenía que seleccionar un texto al agregar esa declaración de importación.)

La otra (y más conocida) diferencia de Emacs es el anillo de muerte. La mayoría de las teclas para eliminar texto del búfer guardan texto en el anillo de muerte, que luego se puede recuperar con el comando "yank" (Ctrl-y). La característica esencial es que los comandos de extracción subsiguientes recuperan el viejo texto eliminado. Entonces puedes matar varias secciones de texto en una fila y luego recuperarlas en orden. También puede recorrer el anillo de sacrificio 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 para adoptarlas en cualquier medida es NeXTStep (y ahora heredado por Cocoa). Otras herramientas proporcionan más funciones para tareas específicas, se pueden extender en idiomas 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 sabes cómo usarlo, es muy difícil dejarlo.


Una cosa que realmente me gusta de vim es el comando "repetidor". Básicamente, presionando . en modo comando, repite tu última acción. Este es solo un ejemplo de las características realmente geniales que tienen los "editores de texto de programador" que a menudo las GUI no tienen.


Una ventaja que todo editor basado en consola tiene sobre los editores de GUI es que pueden ejecutarse en un terminal multiplexor como screen o tmux . ¿Por qué es esto bueno?

  • Es más rápido cambiar de una consola multiplexor 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 se cambian escribiendo algunos caracteres del nombre.
  • Si sus sesiones de editor están en las consolas de un multiplexor terminal, puede acceder a ellas desde cualquier máquina. Si necesito hacer algo de trabajo desde casa, puedo entrar en mi caja, conectar el multiplexor terminal ya en ejecución a mi sesión ssh y estar justo donde lo dejé cuando salí del trabajo.

Ya sabes, por vi, creo que todo se reduce a tener un modo de inserción y comando. Si bien puede parecer un retroceso a un momento en el que no se podía depender del cursor o de las teclas especiales, lo que realmente significa es que muchos comandos potentes de movimiento y maniuplación de texto son un número mínimo de pulsaciones de teclas. La codificación productiva no se trata de la introducción masiva de texto (la predeterminada en los editores "modernos"), sino de una explosión de texto masivo seguido de pequeños ajustes considerables e incluso períodos más largos de navegación.

Esto vino a primer plano para mí personalmente usando vi sobre una red de campus de alta latencia. Puede obtener fácilmente 10 o 15 caracteres antes de la respuesta. Con vi podía predecir cómodamente esos comandos que me dejarían y poder trabajar a velocidades casi normales. Esta experiencia retorcida es un beneficio continuo en condiciones normales: menos capacidad mental visual dedicada a la retroalimentación gráfica constante.

Los aceleradores de búsqueda de palabras comunes * y # son excelentes para pasar el código. Y% para encontrar paréntesis es extremadamente útil. Claro, apenas parece mucho en comparación con ctl-], pero la mitad de las teclas se suma.

Personalmente, uso winvi, que agrega un par de cosas importantes que estoy seguro que vim también tiene. Un salto rápido al modo hexadecimal rompe una gran cantidad de problemas de texto "¿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 el contenido. Esto equivale a una habilidad de pirateo 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.


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 con resaltado de sintaxis, comportamiento con archivos específicos, etc. Todo tipo de cosas se pueden adaptar en vim.

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


Yo uso 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.

  • Débil manejo de FTP "Ordeno" una gran cantidad de sitios, y no ser capaz de navegar y editar archivos en un servidor FTP remoto es una gran deficiencia para mí. NWRead no es lo suficientemente bueno.
  • La rareza de la consola hereda de los problemas generales de la terminal que parece plagar a Linux. Usualmente utilizo PuTTY para conectarme a mi caja de Linux (ejecutando Ubuntu), y por alguna razón, las teclas de flecha se correlacionan con A / B / C / D en el modo de inserción (y con todo el soporte de color). En gVim, ctrl-tab se puede asignar a "bn" fácil, pero no en el modo de consola, tales problemas abundan.
  • Las opciones de búsqueda / reemplazo son muy débiles, en cuanto a la interfaz. Tener que escribir todo en una sola línea, simplemente no es lo suficientemente bueno. Siento que el diálogo mucho más elaborado en decir UltraEdit me da mucho más poder al final, incluso si el soporte de expresión regular real puede ser mucho más débil.
  • Demasiada confianza en los diseños de teclado de EE. UU. Muchas teclas que se usan para funciones primarias, como `, no son de impresión en mi distribución de teclado danés (y se ubican de forma arcaica, igual que con $, y muchas otras). Hace que sea bastante incómodo usar algunas funciones.

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

Para mejoras de 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 vim keybindings vs 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 dado las gracias desde que me mudé a vim.
  4. es liviano y rápido

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

Longevidad : Vim / Emacs son FOSS , y han existido por décadas. Su uso no va a disminuir, ni sus características van a romper / desaparecer / cambiar mucho, por lo que puede confiar en la construcción de todo su núcleo de herramientas de carrera en torno al dominio de un solo editor.

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

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

Deshilachamiento : cualquier lenguaje que uses 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 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 algunas combinaciones de teclas 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 encontrar integrada en estos editores, y se puede acceder de manera similar a los sistemas de ayuda amplios e integrales que ofrecen. La finalización automática se ha agregado para la mayoría de los idiomas comunes. Además, hay mucha ayuda para debatir sobre prácticamente cualquier tema de ayuda.

Navegación : etiquetas, marcas de crédito, marcas, ventanas, pestañas, jumping vim-rails y muchas más incorporaciones.

Gestores / repositorios de paquetes : Emacs tiene algunos (elpa, melpa, mermelada) y los de Vim también (vundle, patógeno, etc ). No conozco ninguna comunidad alrededor de IDEs 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 va más lejos 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 de navegadores, 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 en ambos. ¡Modifique los temas y comportamientos de color para su deleite!