¿Cuáles son los pros y los contras de Vim y Emacs?

¿Cómo compararías estos editores? ¿Cuáles son los pros y los contras de cada uno?

[ nota ] Esto no debe ser respondido por aquellos que "odian a uno y aman a otro" o aquellos que no han usado ambos.

Utilizo ambos, aunque si tuviera que elegir uno, sé cuál elegiría. Aún así, intentaré hacer una comparación objetiva sobre algunos temas.

• Disponible en todas partes? Si es un administrador de sistemas profesional que trabaja con sistemas Unix, o un usuario avanzado en dispositivos integrados (enrutadores, teléfonos inteligentes con Busybox, ...), necesita saber vi (no Vim), porque está disponible en todos los sistemas Unix y la mayoría Sistemas tipo Unix, ya sean de escritorio, servidores o integrados. Para un usuario común, este argumento es irrelevante: Emacs está fácilmente disponible para cualquier sistema operativo de escritorio / servidor, y dado que admite la edición remota, es suficiente tenerlo en su máquina de escritorio de todos modos.

• ¿Hinchado? Emacs una vez se presentó humorísticamente para "Ocho megabytes e intercambiando constantemente". En este momento, en mi máquina, Google Chrome necesita tanta RAM por pestaña como Emacs necesita para 100 archivos abiertos, y ni siquiera mencionaré Firefox. En el siglo XXI, la hinchazón de Emacs es solo un mito.

  La hinchazón característica tampoco es un problema. Si no lo usa, no tiene que saber que está allí. Las características de Emacs se mantienen fuera del camino cuando no las usa y la documentación está muy bien organizada.

• Tiempo de inicio : los proponentes de Vi (m) se quejan del tiempo de inicio de Emacs. Sí, Emacs tarda en iniciarse, pero esto no es gran cosa: inicia Emacs una vez por sesión y luego se conecta al proceso en ejecución emacsclient. Entonces, el inicio lento de Emacs es principalmente un mito.

  Hay una excepción, que es cuando inicia sesión en una máquina remota y desea editar un archivo allí. Iniciar un Emacs remoto es (generalmente) más lento que iniciar un Vim remoto. En algunas situaciones, puede mantener un Emacs ejecutándose dentro de la pantalla. También puede editar archivos remotos desde Emacs, pero interrumpe el flujo si está en una sesión ssh en una terminal. (Desde XEmacs 21 o GNU Emacs 23, puede abrir una ventana de Emacs desde una instancia de X en ejecución dentro de un terminal).

  Al girar las tablas, he observado que Vim tarda mucho más en cargar que Emacs ( vim -u /dev/nullvs. emacs -q). Es cierto que esto estaba en una plataforma extraña (Cygwin).

• Curva de aprendizaje inicial: esto varía de persona a persona. El gráfico de Michael Mrozek me hizo reír. En serio, estoy de acuerdo en que la curva de aprendizaje de Vim comienza empinada, más pronunciada que cualquier otro editor, aunque esto puede reducirse utilizando gvim.

  Como he disipado un par de mitos de Emacs, permítanme disipar un mito vi: un editor modal no es difícil ni doloroso de usar. Se necesita un pequeño hábito, pero después de un tiempo se siente muy natural. Si tuviera que rediseñar vi (m), definitivamente mantendría los modos.

• Curva de aprendizaje asintótica: tanto Vim como Emacs tienen muchas características, y seguirás descubriendo nuevas después de años de uso.

• Productividad : este es un tema extremadamente difícil. Los defensores de vi (m) argumentan que puedes hacer casi todo sin salir de la fila de inicio, y eso te hace más eficiente cuando más lo necesitas. Los defensores de Emacs replican que Emacs tiene muchos comandos que no se usan con frecuencia, por lo que no garantiza un enlace de teclas, pero son muy convenientes cuando los necesita ( referencia obligatoria de xkcd ).
  _{Mi opinión personal es que Emacs finalmente gana a menos que tenga una discapacidad de escritura (e incluso entonces puede configurar Emacs para que solo requiera secuencias de teclas y no combinaciones como Ctrl+ letra). Las teclas de la fila de inicio son buenas, pero a menudo no son una gran victoria porque tienes que cambiar de modo. No creo que haya nada que Vim pueda hacer significativamente más eficientemente que Emacs, mientras que lo contrario es cierto.}

• Personalización : ambos editores son programables, y hay una gran cantidad de paquetes disponibles para ambos. Sin embargo, Vim es un editor con un lenguaje macro; Emacs es un editor escrito en Lisp con algunas primitivas ad-hoc. Emacs gana espectacularmente cuando intentas hacer algo que los autores simplemente no pensaron. Esto no sucede todos los días, pero se acumula con los años.

• Más que un editor : Vim es un editor. Emacs no es solo un editor: también es un IDE, un administrador de archivos, un emulador de terminal, un navegador web, un cliente de correo, un cliente de noticias, ... Si eso es bueno o malo es un tema de debate. Pero puede usar Emacs como un mero editor (ver "hinchazón de características" más arriba).

• Como IDE : tanto Vim como Emacs tienen soporte para muchos lenguajes de programación y otros formatos de texto. Más allá de lo básico, como la coloración sintáctica y la sangría automática, ambos tienen características IDE avanzadas, como búsquedas de referencias cruzadas de código y documentación, inserciones asistidas y refactorización, control de versiones integrado y la capacidad de iniciar una compilación y saltar al primer error.

  Un dominio donde Emacs es simplemente mejor que Vim es la interacción con subprocesos asincrónicos . Ahí es cuando comienzas una compilación larga y quieres hacer algo más dentro de la misma instancia del editor mientras el compilador se está agitando. O cuando desea interactuar con un ciclo de lectura-evaluación-impresión : Emacs realmente brilla con esto, Vim solo tiene trucos torpes para ofrecer. Sin embargo, una nueva bifurcación de vim, Neovim ha demostrado haber solucionado esto e implementado otras varias correcciones de errores no implementadas en vim.

Publicaré lo que creo que son los principales beneficios de cada uno:

Emacs tiene considerablemente más extensiones para permitirle realizar tareas que solo están vagamente relacionadas con el editor de texto, como navegar por el sistema de archivos o jugar con el control de versiones, y extensiones que de ninguna manera están relacionadas con el editor de texto, como leer fuentes RSS. Si desea un entorno en lugar de solo un editor de texto, Emacs será mejor que Vim. También creo que Emacs es mucho más fácil de aprender, a pesar de lo que algunos quisieran hacer creer:

En particular, creo que un usuario novato de Emacs será más rápido que un usuario novato de Vim

Por otro lado, Vim es innegablemente más rápido. Parece que esta es una parte central del argumento, pero en mi opinión no hay competencia en absoluto; Me considero un usuario fluido de Emacs, y no soy rival para las dos personas que conozco que tienen el mismo conocimiento de Vim. El problema es que la cantidad de personas que tienen suficiente dominio de Vim para ser tan rápido es increíblemente pequeña (de las ~ 30 personas con las que hablo regularmente que usan Vim, creo que solo una es excepcionalmente buena en eso). Hay una gran brecha entre la posible ganancia de velocidad y la ganancia de velocidad real que se logra; Los usuarios de Emacs van a ser casi tan rápidos como el 99% de los usuarios de Vim, y (como dije en la sección de Emacs) los usuarios principiantes de Emacs probablemente serán más rápidos que los usuarios principiantes de Vim

Hay un sistema vidisponible en todos los sistemas Unix (o casi), sin embargo, no puede decir esto sobre ningún otro editor. Esta es la razón # 1, en mi opinión, para aprender y familiarizarse vi(tenga en cuenta 'vi' no 'vim'). Nunca he visto que Emacs esté disponible en una instalación predeterminada.

No estoy diciendo que no uses Emacs o esta es la única razón para usar Vim, pero cuando quieres poder usar sistemas Unix que no son tuyos ... vies parte del lenguaje universal.

Creo que los dos son geniales. Creo que cualquiera puede hacer casi cualquier cosa que puedas imaginar, y ambos son tan personalizables, que para cuando termines de personalizarlos, ambos son exactamente lo que quieres que sean, ni más ni menos.

Emacs se destaca para mí por estar un poco más cerca (aunque todavía no cumple) con los estándares ISO / IEC de usabilidad y coherencia para las interfaces de usuario, y por lo tanto no juega tantos trucos con sus "instintos" sobre eso vim. La vida de los instintos que has desarrollado trabajando con otros programas no funcionará en tu contra.

Vim es un modelo completamente diferente y, en muchos sentidos, es superior por sí solo en la medida en que se basa mucho menos en las secuencias Cntrl / Alt y, en cambio, solo en sus modos, lo que le permite mantener sus dificultades en la fila de inicio y escribir Más rápido. Pero vim es prácticamente único, y a menos que instale algún software de acompañamiento muy inusual (por ejemplo, Vimperator, Jumanji / Zathura, etc.), los instintos que desarrolle trabajando con vim no se transferirán a otros programas y viceversa. Dicho esto, me decidí por mí. Tienes que decidirte por uno tarde o temprano, para bien o para mal, ya que es difícil dominar ambos.

Yo uso ambos de forma regular. Veo Emacs como un editor "en vivo", mientras que uso Vim para tareas rápidas y únicas. Superficialmente, Emacs está mucho más hinchado que Vim, por lo que realmente no es tan conveniente "Arrancar" como Vim, pero también encuentro que las filosofías de la interfaz de usuario de una a otra apoyan este paradigma. Emacs está mucho más construido para mantenerte dentro, haciendo las cosas agradables y cómodas para que no tengas que irte, mientras que vim es mucho más "Unixy" y se ve a sí mismo como parte de un cinturón de herramientas más grande.

Muchas personas huyen de Emacs debido a su gran dependencia de los bits bucky , pero esta es una razón bastante tonta para mí. El verdadero poder que tiene Emacs sobre Vim es la personalización, y con el poder de Viper, etc., esto realmente no es un problema. Ciertamente, Vim-Script proporciona su propio nivel de personalización, y si, por ejemplo, su lenguaje de programación favorito no cuenta con un resaltador de sintaxis apropiado, sin duda podría preparar uno, pero Emacs es, en última instancia, una máquina de alojamiento independiente, y en Al final puedes hacer mucho, mucho más jugando con él. Simplemente no hay herramientas como gnus o org-mode en Vim, por nombrar algunas. En pocas palabras, Emacs no es solo un editor, es prácticamente un maldito sistema operativo.

Para manipular texto, diría que están exactamente a la par.

Pondré mi valor de $ 0.02, ya que pasé algunos años usando emacs y XEmacs y luego me mudé a vim. Para ser justos, en realidad había usado vi bastante alrededor de 1990-1992, así que estaba familiarizado con su interfaz de usuario.

Emacs

• Emacs ha sido descrito como un sistema lisp que se utilizó para escribir un editor, y hay algo de verdad en esto. Puede implementar prácticamente todo lo que desee en elisp si desea tomarse su tiempo para comprender el entorno. No puedo decir que alguna vez lo haya sabido tan bien, pero de vez en cuando hice cosas frígidas. Emacs y Xemacs no son totalmente compatibles a este nivel, por lo que los scripts de terceros pueden ejecutarse en uno pero no en el otro.

• Se ha observado que RMS y algunos otros piratas informáticos prominentes de Emacs tuvieron que retirarse de la programación debido a problemas con OOS, donde Bill Joy, Bram Moolenaar y varias otras luminarias vi todavía lo hacen. Emacs es duro con tus dedos meñiques.

• Emacs es un sistema mucho más católico que vi, y es visto como un ejemplo canónico de envoltura de software . Junto con Netscape, esta es una de las contribuciones de jwz para probar esta ley.

Una cosa única que hice con xemacs una vez fue hacer que se ejecutara en una máquina y abrir una sesión x en un xterminal (en realidad, un viejo Sun 3/60 reutilizado) en una habitación diferente contra el mismo búfer en la misma instancia en ejecución.

Pros: Extensible, más potente que cualquier otro editor conocido por el hombre, integración madura con casi todas las principales herramientas de programación de software libre.

Contras: ergonomía cuestionable, elisp no es fácil de aprender.

Empuje

Descargo de responsabilidad: pasé de usar emacs a vim hace unos 10 años y habitualmente uso vim en sistemas basados ​​en Windows y Unix / Linux.

• Vi y sus descendientes tienen una muy buena función de macro de teclado para automatizar las tareas de edición. La instalación de secuencias de comandos en vim no es tan sofisticada como elisp, pero puede compilarla con soporte para Python, Tcl, Perl y quizás algunos otros sistemas. Solo ocasionalmente he escrito scripts (fuera de los archivos .vimrc) para vim.

• Vim tiene una huella más pequeña que emacs, pero esto no es gran cosa en estos días.

• La documentación y la ayuda en línea de Vim son bastante buenas. Emacs tiene bastante buena documentación en línea, pero no creo que sea tan completa como la de vim.

• Vim hereda la peculiar interfaz de usuario modal de vi, pero ahora tiene la capacidad de comportarse como un editor sin modificaciones, ya que puede navegar en modo de inserción. En Windows puede comportarse de manera bastante similar a una aplicación de Windows.

Pros: Buena macro instalaciones teclado, pasablemente buena extensibilidad y de secuencias de comandos, pero no tan bueno como Emacs. Los editores derivados de Vim o vi son estándar en la mayoría, si no en todas, de las distribuciones Linux o Unix. Posiblemente mejor ergonomía.

Contras: la interfaz de usuario modal se siente extraña para las personas acostumbradas a las IU de Windows. Menos de un problema con vim en estos días.

Normalmente uso Vim, pero ambos son grandes editores.

Aprender a usar vi fue desagradable, pero lo superé y aprendí a que me gustara. Mis momentos más frustrantes fueron cuando la tecla de bloqueo de mayúsculas estaba activada. Puede probar con gVim, pero una de las mayores ventajas de vi y Emacs es la capacidad de hacer cosas ordenadas mientras mantiene las manos en el teclado, y es probable que gVim lo mantenga usando el mouse. (Aprender a jugar juegos roguelike al mismo tiempo me dio práctica con las teclas de movimiento del cursor, pero a veces me obligó a tratar de moverme diagonalmente en los documentos).

Emacs es probablemente más accesible. No tiene modo, y no te vas a joder presionando la tecla de bloqueo de mayúsculas. La idea de controlar el editor escribiendo letras con la tecla de control presionada no debería ser demasiado extraña para los usuarios avanzados modernos, aunque las claves reales para hacer las cosas parecerán salvajes y arbitrarias para el usuario típico de Windows / Mac OS X. Nuevamente, las versiones que le permiten usar el mouse le hacen pocos favores a largo plazo.

Ambos requieren cierto nivel de experiencia para usar de manera efectiva. A diferencia, por ejemplo, del Bloc de notas, no puede simplemente sentarse y editar.

Ambos son configurables, aunque para mi dinero escribir extensiones en el mismo Lisp en el que está escrito el editor hace que la experiencia sea más fluida. (Emacs, como se distribuye normalmente, no es realmente un editor. Es un entorno Lisp adaptado para el procesamiento de texto, con una gran cantidad de software preescrito, incluido un editor. De ahí la broma "Emacs hace un shell decente, pero podría usar un mejor editor ")

Normalmente uso Vim porque, después de un entrenamiento extenso, se siente más fácil. Esto puede deberse a las ventajas en el sistema de modo, donde hay un gran número de comandos disponibles con un dedo cerca de las filas de inicio, o "síndrome del pato bebé", que se aplica mucho a los editores: una vez que aprende uno bueno, generalmente se queda lo.

No te equivocarás tampoco.

La razón principal por la que no uso vi / vim es porque es modal. La razón principal por la que uso vi es que está disponible en casi todas partes.

Creo que el comentario "vim es modal" anterior es incorrecto. Vim tiene comandos. Puede hacer "11a Ahora es el momento para todos los hombres buenos ..." y terminar con 11 nuevas líneas de texto idénticas en su archivo. Eso es un comando, no un modo. Pero en realidad hay una diferencia muy básica entre los comandos de Vim y los comandos de Emacs. No estoy completamente seguro de poder describirlo, pero Eric Fischer incorporó la edición de líneas al estilo de Emacs en un controlador TTY hace más de 10 años, y obtuvo un artículo publicado al respecto:

http://www.usenix.org/event/usenix99/full_papers/fischer/fischer.pdf

Descubrió que la edición de línea de estilo Emacs era fundamentalmente diferente del estilo vi.

Entonces, Emacs tiene la ventaja de que muchas otras cosas (bash, gnuplot, zsh, ksh y otras que no se me ocurren) terminan implementando la edición de líneas al estilo de Emacs.

Debo señalar que personalmente uso Vim todo el tiempo. Solo soy un usuario ocasional de Emacs.

Como no se ha establecido explícitamente, agregaré que no hay un mejor entorno de programación (Lisp in a box, SLIME, etc.) que una distribución de Emacs ligeramente modificada. Todas mis necesidades de programación (99%) son atendidas desde Vim, pero para todas esas bibliotecas y rutinas de Lisp que escribo, tengo que encender Emacs para hacer algo productivo.

Yo uso Vim / gVim.

Solía ​​usar Emacs, pero descubrí que gVim generalmente funciona más rápido en máquinas más lentas, además, debido a su requisito POSIX, vi está disponible en casi todas partes.

Cuando uso Vim o gVim, uso mucho el mouse, creo que es excelente.

Comencé a usar Emacs, porque era más fácil de usar para un usuario novato. Descubrí que el uso de nano es bastante propenso a errores por alguna razón, y en algún momento me di cuenta de que estoy mucho más cómodo con el uso de vi.

En este momento, es una mezcla. También uso Eclipse y gedit con bastante frecuencia. Vim, sin embargo, sigue siendo mi editor favorito y más utilizado.

Utilizo gVim y Emacs lo suficientemente bien como para ser productivo, aunque no soy experto en ninguno. Una cosa que puedo decir con certeza es que Vim y gVim se ejecutan más rápido en mi computadora portátil con Windows 7 (que tengo que usar en el trabajo). Emacs, en el cuadro de Windows, tiene la extraña costumbre de "pausar" durante un minuto y dejar de responder, incluso mientras continúa aceptando la entrada del teclado, antes de escupir todo lo acumulado en el búfer del teclado. Esto no sucede en Mac OS o Linux. Sin embargo, me encuentro usando Vim o gVim la mayor parte del tiempo en todas las plataformas para no tener que parar y pensar en qué editor estoy usando y ajustando. Dicho esto, en un entorno puramente * nix, probablemente me quedaría con Emacs porque encuentro que la edición sin modo es un poco más natural.

En pocas palabras: en mi opinión, ambos editores son lo suficientemente potentes como para manejar todas y cada una de las necesidades de edición de texto. La elección debe basarse en consideraciones prácticas (como detalles de implementación de la plataforma) y estilo de trabajo.

La principal diferencia entre Emacs y Vim es ergonómica. Hay síndrome del túnel carpiano, CTS, como sabes. Emacs es muy "peligroso" si tiene CTS y provoca CTS. Vim: no, puedes leer sobre esta diferencia en muchos lugares. Por ejemplo, en Vim puede editar texto solo con un dedo. En Emacs, no puedes :)

Yo uso vi/ nvi(NO vim) porque es simple y discreto.

vimama los pitidos tanto que es más difícil y poco obvio que se apague. Tuve que quitar físicamente el altavoz interno de la PC antes de encontrar esa referencia enterrada sobre cómo hacerlo :)

set vb t_vb=

Además, no uso el color de sintaxis, el gris sobre el negro para mí es el más hermoso.

Y tal vez soy demasiado estúpido para descubrir esa forma enredada de múltiples teclas presionadas emacs, la única combinación de tres teclas que recuerdo es CTRL-ALT-DEL.

"¿Cuáles son los pros y los contras de Vim y Emacs?" - ja!

Sobre todo dejaré los pros a otros.

Los inconvenientes de ambos son que ambos son de la vieja escuela. He usado probablemente 50 editores diferentes a lo largo de los años, desde editores de línea básicos, hasta editores codificados de ensamblaje súper rápido (VEDIT para uno), hasta editores de GUI sofisticados, algunos mejores que otros. Incluso escribí mi propio editor especial llamado ForthStar y lo adapté para editar un árbol de hojas de btrieve, con múltiples índices para búsquedas poderosas, como encontrar instantáneamente las últimas hojas que acabo de editar, o encontrar rápidamente componentes de código, o padres hoja o niños

Creo que tanto vi como emacs son más religión que músculo. Las mentes creativas que los construyeron han avanzado en gran medida, y el nuevo apoyo carece del coraje y la habilidad para reinventarlos.

Sí, Emacs puede hacer mucho, pero es lento por lisp, un lenguaje hermoso y ahora en gran parte obsoleto.

Ambos están atrapados en diseños de teclado difíciles. Emacs podría ajustarse un poco al usuario, como mínimo al reconocer que hay una tecla Alt en lugar de la antigua Meta. Y al igual que WordStar, reconozca que mantener a CA CB directamente de CA B cuando la escritura rápida no merece la pena. Es mejor simplemente tener uno que sea activado por cualquier combinación de teclas. Sí, puedes alterar las combinaciones de teclas, pero qué desastre tienes más tarde.

Vi es inteligente, pero carece de una poderosa búsqueda y reemplazo como en Notepad ++ que le muestra lo que encontró, le permite expandirlo y aplicarlo selectivamente, en color, solo por mencionar una innovación.

Casi cualquier otra interfaz gráfica de usuario en estos días permite hacer zoom con la rueda del mouse. La GUI de Emacs no parece hacer que esto funcione. ¿Y dónde está el agradable saludo griego que tiene Kate?

Mi diseño de teclado favorito a lo largo de los años fue el diamante cursor de Wordstar. Al menos era fácil de aprender y tenía sentido de inmediato. El que más odié fue WordPerfect, que aumentó la complejidad y parece haberse basado en parte en emacs.

Seamos realistas, la mayor parte del mundo tiene GUI en estos días. Y les guste o no, los editores de texto están algo atascados en su edad.

Creo que sería mejor tener un editor universal que pudiera cambiar fácilmente entre emacs, vi, wordstar o cualquier diseño clave, y sin perder los comandos más poderosos que tiene para ofrecer. Los programadores reales tienen que usar una variedad de herramientas de edición. ¿Por qué no tener un editor que satisfaga nuestras necesidades para hacer el trabajo en lugar de obligarnos a su manera de hacer las cosas?