tutorial - vim the ubiquitous text editor

¿Vale la pena invertir tiempo en aprender a usar Emacs? (29)

¿Mi productividad realmente aumentará?

Durante los primeros días / semanas, absolutamente no.

Después de dejar de leer el tutorial cada vez que quiera editar algo, seguro ...

Emacs es más "potente" que vim, su motor de scripting es mucho más flexible y hay muchos más scripts, modos y gustos basados en emacs.

Dicho eso, es todo lo contrario ... Si pasaras la misma cantidad de tiempo mejorando tu conocimiento de vim, podrías ser igual de productivo ...

Tal vez no sea productivo de la misma manera: diría que vim es más rápido para editar archivos, emacs es mejor para hacer todo lo demás (una vez más, diría cosas como flymake-mode , las vinculaciones de VCS son más rápidas de usar que las vim). equivalente)

Justo al frente: no quiero comenzar una guerra religiosa.

He usado vi durante todo el tiempo que puedo recordar, y las pocas veces que he intentado recoger a Emacs he estado tan perdido que me he dado por vencido rápidamente. Mucha gente encuentra a Emacs muy poderoso, sin embargo. Su programabilidad es algo legendaria. Principalmente estoy haciendo el desarrollo de Solaris + Java, y me gustaría hacer una simple pregunta: ¿aumentará mi productividad si invierto tiempo para familiarizarme con Emacs? ¿La funcionalidad que ofrece sobre Vim va a ser restituida en incrementos de productividad en un plazo razonable?

Repito: no quiero una respuesta de "mi editor es mejor que el tuyo". Solo quiero una respuesta sí o no sobre si vale la pena invertir el tiempo o no. ¿Mi productividad realmente aumentará?

¿Qué tan rápido escribes? Si cazas y picas, entonces emacs no es para ti. Si es rápido, puede ayudar a no tener que agarrar el mouse todo el tiempo.

Amo emacs y lo uso todos los días.

Dicho esto, no creo que el costo de aprenderlo se recupere por ganancias de productividad en el futuro.

Si está programando Java, necesita un buen IDE. Emacs va de una manera justa hacia ser uno, pero aceptémoslo, IDEA et al lo vencieron. (emacs probablemente inspiró muchos de esos IDEs, pero esa es otra historia).

Dependiendo de cómo codifique, puede ver un aumento de productividad. Para el fondo, también soy un usuario de vim desde hace mucho tiempo, pero aprendí emacs hace aproximadamente 2 años, y ahora los uso intercambiablemente.

Lo que me llevó al punto de aprender realmente emacs fue su capacidad útil para tener una gran cantidad de archivos abiertos a la vez, y para cambiar fácilmente entre ellos. Estaba en el medio de presentar una función que agregaba y tocaba una gran cantidad de clases. (Esto era C ++, por lo que normalmente había dos archivos por clase.) Como todavía estaba reafirmando la interfaz, normalmente estaría en el medio de actualizar un archivo cuando me daría cuenta de que necesitaba cambiar otro.

Con gvim, era más fácil abrir una nueva ventana para cada archivo, que comenzaba a hacerse difícil de manejar. Con Emacs, sin embargo, era simple abrir un nuevo archivo en la misma ventana (Ctrl-x, Ctrl-f). Una vez que Emacs tiene un archivo abierto, es muy fácil cambiar entre los búferes abiertos (Ctrl-x, Ctrl-b).

Dando un paso más allá, una sola sesión de emacs puede abrir muchas ventanas, así que, además de dividir la ventana verticalmente, podría decidir, sin interrumpir el trabajo en un archivo, abrir otra al lado, dejándome trabajar de manera efectiva de lado a lado. de lado manteniendo al mismo tiempo cada ventana en el ancho predeterminado de 80 caracteres.

Todavía hay algunas cosas que me resultan más sencillas en vim (por ejemplo, modo de selección de bloque, grabación de macros simple, modo diff) y cosas que son más fáciles en Emacs (alineación de líneas, gestión de archivos / búfer, gestión de ventanas / pantallas). Por lo tanto, me encuentro alternando entre los dos (y algunas veces utilizando ambos simultáneamente), dependiendo de la tarea de edición que anticipe.

Si todavía no estás seguro, te sugiero probarlo. Ejecutar a través del tutorial de Emacs y luego usarlo para escribir el código de una mañana o un día, apoyándose fuertemente en la ayuda. Si todavía no te gusta lo que ves, quédate con vim. Independientemente de lo que el editor ponga sobre la mesa, su familiaridad y conocimiento de la herramienta serán, de lejos, el factor más importante en su productividad.

Dos veces intenté aprender Emacs. Simplemente no se ajusta al funcionamiento de mi cerebro, por lo que no lo uso.

Emacs (o vim) no es significativamente mejor que vim (o Emacs). Ambos tienen muchas opciones para agregarles que les permiten hacer cosas increíbles. No tengo dudas de que cualquier cosa que se pueda hacer en Emacs también se puede hacer en Vim, pero no de manera estándar.

Prueba Emacs. Vea si encaja mejor. Es una situación sin perder.

Emacs proporcionará un aumento de productividad si está dispuesto a aprender y personalizarlo para satisfacer sus necesidades. La mayoría de las personas no lo son. Para aumentar su productividad, debe utilizar la herramienta para algo más que una simple edición: la mayoría de las personas nunca pasa de una edición simple.

Aquí hay una prueba rápida: ¿ha personalizado su administrador de ventanas para que su entorno sea más eficiente (adaptado a sus necesidades)? Si es "no", entonces probablemente no obtendrá el ROI aprendiendo emacs.

Dicho esto, si está desarrollando Java, Eclipse es la respuesta estándar, por lo que su pregunta es bastante discutible.

En la misma línea de no buscar una guerra religiosa (pero adelante y vencerme si cree que debe hacerlo), ¿por qué siente que la única opción para vi es emacs? ¿Es el sistema operativo en el que se desarrolla o solo las opciones que exploró?

El panorama de desarrollo de Java goza actualmente de algunos de los mejores IDEs (tanto gratuitos como pagados), si no el mejor cuando se trata de edición de código y soporte de refactorización. IDlliJ IDEA incluso tiene un plugin de vi que puede ayudarte a sentirte más como en casa, por ejemplo (no estoy seguro si algo similar está disponible para Eclipse). Si bien el cambio de herramientas implica una curva de aprendizaje, el tiempo invertido en hacerlo puede valer la pena si el salto es lo suficientemente grande.

Estaba muy contento con mi Vim, pero una vez que escuché sobre org-mode , comencé a aprender Emacs. org-mode podría ser una buena razón para aprender Emacs.

Estoy de acuerdo con Alan Storm: "porque los patrones y las metáforas utilizadas en Emacs pueden no alinearse con tu cerebro"

Este es un factor muy importante. Diferentes cerebros se adaptan de manera diferente a diferentes interfaces.

Algunas de las funciones principales, y fácilmente disponibles, que realmente me encantan de Emacs, y las considero como potenciadores de la productividad:
1. instalación "yank-pop": cada corte / copia se guarda en una pila para que luego pueda elegir qué pegar (no sé si vi / Vim tiene esto, pero la mayoría de los IDEs de Java no)
2. Mapeo de navegación con la tecla Ctrl: esto le permite navegar por su archivo sin mover las manos para usar las teclas de flecha. (La vinculación de claves en otros editores ayuda, por supuesto)
3. disponible en casi todas las plataformas (también para vi / Vim por supuesto) - ya sea GUI o basado en texto (los IDEs de Java también están disponibles en la mayoría de las plataformas pero solo en modo GUI, y son significativamente más grandes y deben instalarse por separado mientras que Emacs está generalmente más ampliamente disponible: sistemas BSD / * nix / Linux / Mac
4. Prefiero que mi editor permanezca fuera del camino hasta que lo necesite, la pantalla espartana de Emacs me obliga a pensar antes de escribir.
5. Las teclas de navegación básicas de Emacs están disponibles de forma universal: en mi sistema operativo Mac, puedo usar estas teclas en terminal, mac mail, etc.

En definitiva, si la filosofía de Emacs te atrae, harás un esfuerzo extra para aprenderla. Y te recompensará.

Generalmente, emacs es más poderoso que vi. Podrías hacer muchas más cosas en emacs.

La documentación de Emacs es un bosque. Vine de Emacs a Vim cuando me di cuenta de cuán organizada es la documentación de Vim y cuán codificables son muchas de las características. No sé qué se esconde en el camino de un experto en Emacs, pero le advertiré que aprender a hacer algo útil en ello lleva mucho tiempo, y no lo hará mejor en nethack. Quédate con Vim.

Textmate es un Emacs mejor para Mac, aunque eso no lo ayudará con Solaris. Eclipse es genial y tiene muchos complementos.

La respuesta corta a tu pregunta es "SÍ". Más detalles a continuación.

Utilicé vi casi exclusivamente de 1980 a 1991. La única vez que no usé vi fue cuando estaba lidiando con una instalación mínima de Unix que era demasiado pequeña para incluir vi, así que tuve que volver a la que es la subconjunto mínimo de la funcionalidad de edición sobre la que se construyó el vi original.

Desde aproximadamente 1985 en adelante, otros programadores donde trabajaba cantaban constantemente las alabanzas de emacs. Pero cada vez que trato de aprenderlo no llegaría muy lejos. Pasaría una hora revisando el emacs turorial (Ch t) y para el final de todo lo que sabría sería cómo insertar y modificar el texto y moverse por la pantalla. Podría hacer mucho más con vi de lo que había aprendido en esa hora con emacs que no podía hacer el cambio. Tres meses después encontraría tiempo para pasar otra hora y terminaría revisando el mismo material. Emacs tiene una curva de aprendizaje con una "L" mayúscula. No fue hasta que hice un contrato donde todos usaban emacs que finalmente decidí que necesitaba dedicar más de una hora para aprenderlo. Después de pasar un poco más de un día sin hacer nada más que trabajar en el tutorial y la documentación incluida, finalmente llegué al punto en el que podía hacer cosas con emacs que no podía con vi. Desde entonces, nunca he querido regresar. Todavía puedo escribir comandos vi mientras duermo, pero puedo hacer mucho más con emacs.

Comprende que estoy comparando emacs y vi, no vim. Nunca supe las extensiones que vim ha agregado a vi, y es probable que muchas de ellas sean funciones copiadas de emacs. Si es así, y si ya eres hábil con vim, emacs puede no tener tantas ventajas para ti.

Entre las cosas de las que dependo todo el tiempo en emacs están:

Cuando usas emacs, todo se trata como texto. Esto significa que puede manipular cualquier dato en cualquier búfer con casi los mismos comandos. Y en los casos en que un búfer está en un modo donde algunos de los comandos estándar no están disponibles, puede copiar texto en otro búfer que se ejecuta en modo fundamental y usar los comandos estándar allí.
Emacs proporciona un entorno multi- "ventana" visualizable en un terminal de celda de caracteres. En los días previos a los gráficos de mapas de bits y las ventanas reales, emacs se escribió para simular un comportamiento similar a una ventana utilizando nada más que caracteres ascii y posicionamiento del cursor. Probablemente estés pensando, "Eso es historia antigua. ¿Por qué debería importarle eso a nadie hoy?" Todavía uso esa capacidad todos los días. Uso una empresa de alojamiento web que me permite acceso SSH. De modo que puedo iniciar sesión en un host Linux a través de Internet y ejecutar comandos de shell. Si bien es bastante poderoso, es mucho más poderoso poder dividir mi emulador de terminal en "ventanas" usando emacs, ejecutar shells en varias de esas "ventanas", editar archivos en otras ventanas, y ver y editar directorios en otros ". ventanas ".
De hecho, cuando dije "ventana" en el párrafo anterior, realmente quise decir "buffer". La emulación de ventanas de caracteres de Emacs de Windows es una forma de dividir la pantalla de bienes raíces. Un búfer de emacs está asociado con el contenido (un archivo, un shell bash, un directorio, texto arbitrario no asociado con un archivo, etc.) que pueden o no mostrarse actualmente. Para ver lo que hay en un búfer, selecciona una ventana y le dice qué búfer desea ver. Entonces puede estar trabajando mucho más de lo que tiene espacio en la pantalla para mostrar. Es más o menos análogo a lo que se hace en una GUI de gráficos de mapa de bits moderna cuando se indica / des-iconifica una ventana.
Ya he aludido al hecho de que puedes ejecutar un intérprete de comandos dentro de un buffer de emacs. Puede tener tantos búferes ejecutando shells como desee. Puede copiar y pegar texto entre un búfer de shell y un archivo de texto, o comparar una porción de texto entre un búfer de caparazón y un archivo de texto usando exactamente las mismas secuencias de teclas que usaría para copiar texto o comparar texto entre dos diferentes archivos de texto En realidad, esto es cierto para la mayoría de los tipos de almacenamientos intermedios, no solo para los almacenamientos intermedios y almacenamientos intermedios asociados con los archivos.
Cuando utiliza el comando de emacs para abrir un archivo, pero lo que ha seleccionado es en realidad un directorio, el búfer se ejecuta en modo directo (editor de directorio). En este modo, una sola pulsación de tecla se abrirá a lo que apunta el cursor actualmente, ya sea un archivo o subdirectorio. Un búfer en modo directo es un administrador de archivos: un terminal de celda de caracteres orientado de forma analógica a Finder en Mac o Windows Explorer.
Una de las funciones de emacs que uso casi constantemente es "comparar-ventanas". En gran medida, prefiero esto a las herramientas de comparación de "GUI" de línea de comandos o GUI, como las integradas en Eclipse. Diff o Eclipse comparan archivos completos y muestran qué líneas son diferentes. Pero, ¿qué sucede cuando tienes dos líneas diferentes que se ven muy similares? Considera lo siguiente:
¿Cuál es la diferencia entre esta línea y la otra?
¿Cuál es la diferencia entre esta línea y la otra?
¿Cuánto tiempo te tomaría detectar la diferencia? (Sugerencia: ASCII y el apóstrofo Unicode se parecen mucho).
A diferencia de diff y Eclipse, que solo muestran las líneas que difieren, la función "compare-windows" de emacs es interactiva. Posiciona el cursor en cada una de las dos ventanas una al lado de la otra en un punto donde el contenido de la ventana es el mismo. Ejecute "compare-windows", y el cursor en cada ventana se moverá al primer carácter que difiera. Vuelva a colocar el cursor en una de las ventanas hasta el punto donde es igual a la otra ventana, y vuelva a ejecutar "compare-windows" para encontrar la siguiente diferencia. Esto facilita la comparación de subparticiones de archivos.
Otra cosa con la que uso regularmente "comparar-ventanas" para comparar las sumas de comprobación. Muchos proyectos de software distribuyen un tarball de la aplicación en una página que también incluye un hash MD5 del tarball. Entonces, ¿cómo se compara el hash MD5 en la página de distribución con el hash MD5 calculado a partir del archivo descargado? Emacs lo hace trivial.
Primero copie el hash MD5 de la página web en un nuevo buffer de emacs. Luego, después de descargar el archivo .tar.gz, ejecute:
md5sum archivodescargado.tar.gz
en un buffer de shell. Con esos dos búferes visualizados en las ventanas de emacs lado a lado, coloque el cursor en cada ventana al comienzo de la suma de comprobación y ejecute "compare-windows". Si son iguales, el cursor en cada ventana se colocará al final de cada suma de comprobación.
En el punto anterior, di el ejemplo de ejecutar "comparar-ventanas" en las líneas:
¿Cuál es la diferencia entre esta línea y la otra?
¿Cuál es la diferencia entre esta línea y la otra?
"comparar-ventanas" dejará el cursor posicionado en el apóstrofo en cada línea. Entonces, ahora sabes qué personajes difieren. Pero, ¿qué personajes son? Escriba los dos comandos de pulsación de teclas CTRL-x =, y emacs mostrará el carácter, su valor ascii en octal, decimal y hex, el desplazamiento del carácter desde el principio del archivo y el desplazamiento del carácter desde el comienzo de la línea. Como ASCII es una codificación de 7 bits, todos los caracteres ASCII tienen su bit de orden alto desactivado. Una vez que vea que el valor del primer apóstrofo es 0x27 y el segundo es 0x92, es obvio que el primero está en el conjunto de caracteres ASCII y el segundo no.
Emacs fue uno de los primeros IDEs, tal vez el primero. Tiene modos para idiomas específicos. Los encuentro útiles para imponer sangrías consistentes en mi código para hacerlo más legible. También hay una función incorporada para compilar y depurar código. No utilizo tanto la funcionalidad de compilación porque cuando escribía para un lenguaje compilado como C, estaba acostumbrado a hacerlo en un intérprete de comandos. La funcionalidad de depuración fue muy buena para C y C ++. Se integró gdb con el editor de tal manera que obtuviste prácticamente la misma funcionalidad que las capacidades de depuración ahora en Eclipse, pero no desperdiciaste la pantalla como lo hacen los modernos IDE basados en GUI. En teoría, la integración del depurador debería ser fácil de aplicar a prácticamente cualquier otro idioma, pero no he comprobado para ver con qué otros idiomas funciona actualmente.
Emacs le permite crear macros diciéndole cuándo comenzar a recordar lo que está escribiendo y cuándo detenerse. Esto es extremadamente poderoso para las tareas que realiza con frecuencia.
Emacs es infinitamente extensible si sabes Lisp. Pero a pesar de que nunca aprendí Emacs Lisp, todavía encuentro a Emacs como una de las herramientas más poderosas que he usado.
Emacs key-bindings. Seré el primero en admitir que las vinculaciones de teclas de Emacs son malas. Pero es mucho más poderoso que cualquier otra cosa que he usado, estoy dispuesto a soportar las ataduras de las teclas.
En una veta de humor, hace años el autor de Emacs, Richard Stallman (también creador de la GPL, fundador del proyecto GNU y fundador de FSF) ridiculizó a aquellos que tratan a vi vs. emacs como una guerra santa. Inventó el personaje "Saint IGNUcius" de la Iglesia de Emacs. Con ese disfraz, Stallman comentó: "A veces la gente me pregunta si es un pecado en la Iglesia de Emacs usar el otro editor de texto vi. Bueno, es cierto que vi vi vi es el editor de la bestia, pero usando una versión gratuita de vi no es un pecado, es una penitencia ". (Ver http://stallman.org/saint.html . También hay una linda foto suya, pero como soy nuevo en , no me deja publicar más de una URL. Vaya al mismo dominio, pero trae el archivo saintignucius.jpg)

No (y he usado ambos).

I''ve been using emacs for years, I''m a convert from VIM, and I love it to bits.

But any productivity gains from having a better, programmable editor will be totally wiped out by the enormous amount of head-fucking that it takes to get the hang of emacs. It was designed as a console editor, and its idea of interface is not yours.

And even when you''ve got it completely, your extra productivity will mainly be expressed in the extra emacs lisp you can write.

¿A quien le importa? It''s great fun, and lisp is the dogs! If you want to ''get things done'', then forget about programming. You can always hire programmers to ''do'' ''things''.

The only circumstance under which I''d recommend learning emacs for productivity reasons is if you''re a lisp/scheme/clojure programmer. It makes such a good lisp environment that then the few seconds it will save you every time you want to do anything will quickly add up to a real gain. And elisp (which stands in relation to lisp as excel macros stand to ALGOL) will seem much less alien if you already use a real lisp.

If you do give it a try, use it on a virtual console where it feels more like a sane way to arrange an editor. Only when that makes sense try to use it under a window system, which will fight with it.

No quiero una guerra santa, pero responda una pregunta muy subjetiva con una respuesta de sí / no.

Sí, es posible que vea un aumento de la productividad debido a la potente funcionalidad.

No, no verá un aumento de productividad porque los patrones y las metáforas utilizadas en emacs pueden no alinearse con su cerebro.

Prefiero emacs a vi, pero me siento cómodo en ambos.

Hay algunas cosas que puede hacer en emacs que lo hacen más poderoso que vi, pero no todas están relacionadas con la programación. (¿Puedes enviar un correo electrónico o leer noticias desde vi? No, pero ¿a quién le importa?) Si te sientes cómodo con lisp (no lo soy), es posible que puedas escribir complementos, modos y cosas para hacer tu vida. más fácil, pero es probable que sea colorante de sintaxis y corchete coincidente y ojos dulces así.

Dejaré de divagar ahora. ¿Su productividad aumentará usando emacs? No.

Actualización : ver mi comentario a continuación. Desde que publiqué esto, me he encontrado con que el uso de emacs me ha hecho más productivo que usar vi.

Quiero investigar emacs aún más, pero simplemente no puedo usarlo durante largos períodos de tiempo; me duele las manos ¿Estoy haciendo algo horriblemente mal?

Su productividad aumentará si decide dedicar tiempo a programar su editor de texto. De los dos editores, emacs presenta un mejor marco o personalización constante. Si no programa su editor de texto, simplemente quédese con lo que sea cómodo.

Una buena razón para aprender Emacs es porque otros programas también usan combinaciones de teclas de Emacs. Puede usar combinaciones de teclas de Emacs en un aviso bash, por ejemplo, o cualquier otra cosa usando la línea de lectura de GNU. Es bueno aprender el movimiento básico y la eliminación de palabra / línea y deshacer / rehacer acordes en Emacs para que pueda usarlos en otros programas. Su productividad aumentará en esas otras herramientas incluso si nunca vuelve a usar Emacs.

Conozco a Vim y Emacs, y Vim se adapta mejor a mi cerebro y mis hábitos. Pero otras personas afirman lo mismo sobre Emacs. Nunca sabes por ti mismo a menos que lo intentes. No toma tanto tiempo aprender Emacs lo suficientemente bien como para ver si te va a gustar.

Utilicé Vim durante 10 años antes de profundizar en Emacs hace 2 años. Tengo un recuerdo razonablemente reciente de cómo mi curva de productividad se modificó con el tiempo.

Mis puntos son todos condicionales, YMMV dependiendo de tus puntos fuertes y experiencia.

Si ha utilizado Unix y la línea de comando el tiempo suficiente para estar familiarizado con Ca, Ce, Cn, Cp, Ck, Cy, etc., ya que funcionan en el shell, no pasará mucho tiempo para pasar a utilizar esas mismas vinculaciones (el valores predeterminados) en Emacs. Recientemente descubrí que XCode usa estos enlaces también.

Si se siente cómodo con un editor siempre en ejecución, atendiendo buffers (como las pestañas del navegador) y viviendo en la aplicación (como lo haría con las aplicaciones Web2.0 en el navegador), Emacs probablemente mostrará mejoras de productividad inmediatas.

Si generalmente trabaja en proyectos de muchos archivos relacionados, esta persistencia paga algunos beneficios adicionales al mantener el contexto de ese búfer. Cada memoria intermedia está contextualizada en su archivo abierto, lo que permite el uso conveniente de diversas herramientas de aumento de la productividad para ese proyecto (como grep-find, eshell, run-python y slime). Esto, junto con la finalización del texto, yasnippets, etc. comienzan a parecerse a una pequeña fracción como un IDE, aunque ad-hoc y muy individualizado por su configuración. Esto es aparte de los servicios más civilizados de Emacs IDE como ECB.

Mi productividad tuvo un impacto inicial cuando escribí "jjjkkk" constantemente Esc-Esc-Esc-Esc durante la primera semana más o menos. La semana siguiente, comencé a usar cuidadosamente las teclas de navegación derecha. Luego descubrí el archivo de configuración ... Honestamente, si hubiera tenido el kit de inicio de Emacs desde el principio, habría dicho que mi productividad volvió lentamente a la paridad durante la 3ª-4ª semana, pero bajé por el archivo de configuración agujero de conejo. Sin embargo, un compañero de trabajo mío acaba de hacer una transición de vim a emacs y acaba de agarrar el Starter Kit y él está en camino. La primera semana y parece cómodo y disfrutando de todos los beneficios sorpresa (esa sensación probablemente durará una década).

Finalmente, si comete errores, obtendrá inmediatamente productividad (y confianza) del kill circular / yank-ring y undo-ring. También soy un fanático de los resúmenes específicos de cada región.

Mi respuesta corta es Sí, vale la pena tomar 3-4 semanas de una disminución de la productividad para aprender Emacs. Incluso si decides que prefieres un combo simplificado de utilidad de Unix sobre Emacs para el desarrollo, obtendrás una educación ampliamente aplicable más allá del editor.

[Descargo de responsabilidad: personalmente , prefiero Vim. Descargo de responsabilidad: siga leyendo.]

Vim sobresale en lo pequeño: haciendo que el movimiento y la acción separen conceptos y proporcionen recursos para repeticiones complejas, puede realizar operaciones de edición increíblemente potentes en solo una breve secuencia de teclas. Puedes hacer cosas fácilmente en Vim en el curso normal de la edición, lo que requeriría que desplegaras scripts en Emacs. Además, la mayor parte de la energía que utilizas viene de la caja, por lo que incluso si tienes amplias personalizaciones .vimrc , es probable que puedas trabajar productivamente con cualquier instalación de Vim.

Emacs sobresale en grande: mapeando todos sus conceptos de interfaz de usuario directamente a construcciones y conceptos básicos en Elisp, resulta muy fácil introducir características para tipos específicos de archivos o circunstancias, lo que hace que Emacs sea algo así como un texto y mucho más estructurado forma programable de Excel. Esto supone que va a pasar mucho tiempo personalizando su entorno para sus necesidades y preferencias personales. Por supuesto, Emacs hace todo lo posible para que sea más fácil permanecer dentro de ese entorno para todo y cualquier cosa que desee hacer.

En definitiva, ninguno es superior. Ofrecen diferentes estilos, y dependiendo de tus inclinaciones, uno u otro se adaptarán mejor a tus necesidades personales y tu forma de pensar. Siempre es útil conocer ambos (más editores), por supuesto. Pero no vas a ser apreciablemente más productivo de una manera u otra.

vi es un cuchillo de cocina.

vim es un cuchillo de chef realmente agradable, afilado y equilibrado.

Emacs es un sable de luz.

La mayoría de las veces, mi trabajo requiere que pique vegetales. Ocasionalmente, tengo que enfrentarme a todo un ejército de robots.

He estado usando Emacs durante 20 años. Estoy escribiendo Emacs ahora mismo con un widget llamado "It''s All Text" que me permite aspirar y guardar texto en Firefox. Puedo ir muy rápido en Emacs. Soy significativamente menos productivo sin eso.

Esto es muy debatible, pero también creo que aprender Emacs puede enseñarle una cantidad sorprendente acerca de la programación.

vim y emacs, son los editores más capaces y lo han sido durante bastante tiempo. Si conoce uno realmente bien, dudo que gane tanto en el proceso ...

Sin embargo, siempre es una buena idea buscar qué complementos están disponibles, ya que un par de complementos nuevos pueden hacer maravillas por la productividad.

/ Johan

Disclaimer: I''m ignorant. I''ve been an emacs user for about 4 years, and vim user for about 6 months, maybe more like 15 if you count all the times I''ve tried to learn it and hated it. (The writing vs moving mode distinction kills me. Every time. So if it doesn''t kill you then my opinion might be completely worthless.) That said, I think my opinion is actually interestingly different from the 26 others that I''ve seen on here, so I''m going to voice it. :Disclamer

My opinion:

Emacs is better for typing, especially large-scale "I''m writing a new feature and it will be a while before I even try to see if it runs".
Vim is better for editing, especially quick edits.

When I need to understand and hack in 8 files simultaneously, Emacs'' properties as a tiling window manager with multi-buffer (buffers have a 1.2:1 correspondence to files, they''re often the same thing, but aren''t necessarily) regexp-search (and replace) are incredible.

If I don''t like some small thing because of git diff in the shell (I don''t use emacs'' VC features very often, although when I do I love them) I open it with vim and get the hell out faster than I could hit Alt-TAB .

The fact that Emacs'' editing commands are more readily available while typing make typing much faster than it is in Vim. Ctrl+a is much faster than ESC ^ i , and you don''t have the cognitive load of "do I want a or i or o or O ..." which, god, I hate thinking about. And same for all the other movement commands commands.

I type faster, much faster, in Emacs. That means things like Org Mode (which I use for everything: TODO lists, bug tracking, notes, long emails, documentation...) make more sense (to me) in Emacs than they would in Vim.

And, Elisp is incredible, even though it sucks. It totally makes up for Emacs'' broken regular expressions: you can use the full power of emacs everywhere , including in a multi-file regexp-replacement. And in text snippets .

I like Emacs, you can extend it by your needs- in my eyes, any system which you can extend by yourself is award-worthy.

I really see no reason to switch. I''ve used vi for a long time and am quite comfortable with it; about every six months I would install emacs to give it a go, then quickly just switch back. Yes there were things I much preferred about vi, but the main reason I never stuck with it is because the time investment to fully learn another editor when I already know an extremely capable one isn''t worth it.
I''m reminded of this rather dated study.

In my opinion, SLIME is about the only reason to switch to emacs if you''re already proficient with vi.

If you are concerned about the health of your hands choose Vim.

I suffered from a bout of RSI in the past, and I found one of the main culprits was "chording" ie holding down many keys at the same time. Emacs uses chording extensively whilst VIM uses single letter commands chained in quick succession. This puts much less strain on your hands as the muscles don''t have to twist and contort to perform commands in the editor. Injury due to RSI can ruin your productivity so in your calculations be sure to account for this.

In an earlier answer, Aristotle Pagaltzis wrote: "Vim excels in the small ... You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs."

I switched to Emacs after over a decade of exclusively using vi, and initially I would have agreed with the claim, "You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs." But then I discovered that by using Emacs'' macro capability and a large repeat count, I could easily make Emacs do pretty much everything that vi had made easy, and a great deal more.

Emacs'' macro functionality involves three commands:

C-x ( start remembering keystrokes C-x ) stop remembering keystrokes C-x e replay the remembered keystrokes

For example, in vi if I wanted to find all <a> tags in an HTML file and add a target attribute, I might do something like the following:

:g/^<a/s/>/ target="_blank">/

This example is not perfect, since it assumes that all <a> tags are on a line by themselves. But it''s good enough for illustrating how one accomplishes the equivalent task in two different editors.

To achieve the same effect easily in emacs, here''s what I do:

1. C-x ( 2. M-C-s <a/> 3. C-b 4. C-s > 5. C-b 6. target="_blank" 7. C-x ) 8. C-u 10000 C-x e

Here''s a description of what each keystroke above does:

1. start remembering keystrokes 2. regex search for <a. Note that the "/>" after the "a" is not HTML. It''s emacs regex notation for end-of-word. 3. back up one character - as a side-effect this gets you out of search mode 4. search for the next ">" 5. back up over the ">" 6. enter space as an attribute-delimiter followed by the target="_blank" attribute 7. stop remembering keystrokes 8. replay the remembered keystrokes 10,000 times or until the search fails

It looks complicated, but it''s actually very easy to type. And you can use this approach to do lots of things that vi can''t do, without ever dropping down to Lisp code.

Since vi/Vim and Emacs are pretty close in terms of what they can or cannot do, productivity with these two editors comes from experience in using it.

In my opinion, being a programmer it won''t take you long to get the general idea about Emacs once you start using it. Others can only say so much, you got to try it out for yourself to know it.

As for me, I use both. It''s like taking more than one weapon to a war, use the right one in the right circumstances. ;)