Yo uso un IDE (Eclipse) para desarrollar software. ¿Por qué debería cambiar a vim o emacs? [cerrado]

Mi trabajo diario es java / desarrollador web. He estado usando eclipse durante ~ 5 años. Creo que es excelente y también uso Webstorm para javascript y html / jsp.

En ocasiones necesito ssh en el servidor y perder el tiempo con los archivos de configuración; para esto uso vi y me duele. Tengo que abrir una página web que enumera la sintaxis / comandos: presione escape, luego asterisco, gire tres veces y el texto se ingresará dos líneas sobre su cursor . Es muy poco intuitivo para mí, e imagino a cualquiera que creció a finales de los ochenta y noventa.

Estas son las razones principales por las que creo que eclipse es brillante (y supongo que otros IDE), y no cambie a emacs y / o vim.

• Error al resaltar sin necesidad de volver a compilar el proyecto.
• Código de asistencia.
• Refactorización
• Llamada de apertura de la jerarquía / Declaración de apertura.
• Totalmente integrado con control de fuente.
• El depurador está incluido.
• Disponibilidad de complementos de terceros, por ejemplo, findbugs / checkstyle.

Uno de los argumentos que escucho es que con emacs / vim puede crear sus propios complementos, bueno, pero también puede hacerlo en eclipse. ¡Pero no es necesario ya que todo ya está allí! Es como decir que si compras este auto a medio construir, puedes construir el resto tú mismo.

¿Por qué las personas usan emacs / vim? ¿Las personas que lo utilizan realmente trabajan en proyectos complejos orientados a objetos en grandes organizaciones?

¿Cuáles son las razones para cambiar a vim / emacs? ¿Cómo aumentaría mi productividad si cambiara?

Use cualquier herramienta que se ajuste a sus necesidades. Conocer VIM o Emacs es algo bueno si alguna vez tiene que iniciar sesión en un servidor remoto y editar un archivo de configuración o algo similar. Conozco VIM razonablemente bien, pero no lo usaría para desarrollar en Java. Para eso están hechos Eclipse, Netbeans, etc.

Emacs y Vi todavía tienen un lugar.

• Están disponibles de forma ubicua en entornos Unix y similares a Unix, y se pueden instalar en la mayoría de las otras plataformas populares.

• Son populares y estables, por lo que aprenderlos una vez vale la pena a largo plazo.

• Se ejecutan sobre un terminal de texto, por lo que puede usarlos en sesiones telnet y ssh.

• Proporcionan modos de edición y resaltado de sintaxis para una amplia variedad de idiomas, incluidos idiomas muy nuevos y muy raros. (Esta es una de mis ventajas favoritas).

Sin embargo, la clave para comprender estos programas es saber qué problemas estaban destinados originalmente a resolver. Para Vi, esto era editar archivos de texto a través de conexiones de terminal tan lentas como 300 Baudios. En ese entorno, no desea mostrar menús o cambiar radicalmente el contenido de la pantalla si puede evitarlo.

Emacs estaba destinado a ser utilizado en un entorno más rápido. Su fortaleza era que podía cargarse una vez y nunca salir. El usuario podría realizar cualquier otra tarea que necesitara de Emacs sin salir, y a menudo de una manera más amigable que si tuviera que hacerlo desde la línea de comandos. La gente no tenía un entorno de escritorio gráfico con una ventana de Emacs abierta. Emacs le permite al usuario realizar casi cualquier tarea normal (y muchas extrañas) con solo unas pocas teclas. Cualquier cosa que no esté incorporada podría ser programada.

Obviamente, las necesidades de las personas han cambiado mucho desde que se introdujeron estos programas, pero aún tienen algunas fortalezas reales. Aprendí los conceptos básicos de ambos y los uso semanalmente. Aún así, creo que sus puntos fuertes a menudo son exagerados. Han alcanzado un estatus tan legendario que las personas no admiten sus debilidades y tienden a pensar que están haciendo algo mal si Emacs / Vi no los hace más productivos que Eclipse o Visual Studio.

Ahora al grano.

Java es un lenguaje popular con un excelente soporte en Eclipse, y lo más probable es que esté desarrollando código en un sistema operativo moderno que le permita realizar rápidamente tareas comunes y guiar a otros sin hacerlo a través de su IDE. No creo que tenga sentido que cambies.

He estado usando emacs por más de 5 años. Ya no puedo decirte las combinaciones de teclas que estoy usando, mis dedos solo las recuerdan y tengo que mirar el teclado solo para ver qué están escribiendo mis manos.

Hace unos años comencé a usar Eclipse, y no hay posibilidad de que vuelva a usar emacs libremente. Disculpa la memoria muscular, a pesar de que te faltan viejos C-x r SPC 1, Eclipse me hace mucho más productivo y eso es lo que cuenta.

No, no creo que deba cambiar , pero debe dedicar un par de horas a aprender los conceptos básicos de vim para que no tenga que buscarlo más.

¿Por qué debería cambiar a vim o emacs?

Lo más probable es que no debas cambiar . Vim es un editor de texto excelente y potente, pero no es un sustituto de un IDE, ¡y no debería serlo! Eclipse es muy bueno en su subconjunto de cosas específicas de IDE, y vim es muy bueno en su subconjunto de cosas específicas de edición de texto. Cada uno tiene su propio enfoque diferente.

Sé que hay complementos que amplían la funcionalidad de vim para que pueda hacer muchas de las mismas cosas específicas de IDE que puede hacer un IDE. Pero todavía no es la principal fortaleza de vim, y un IDE casi siempre podrá hacerlo mejor. Porque eso es en lo que se centran.

Lo que hago en mi trabajo diario es usar Visual Studio y vim para editar C #. Funciona muy bien para mí, y nunca cortaría uno de ellos para confiar exclusivamente en el otro.

En lo que respecta a emacs, no soy un experto, pero no creo que pueda competir con las características IDE de Eclipse cuando se trata de Java (corríjame si me equivoco). Si está desarrollando en lisp, entonces ciertamente puede considerarse un IDE excelente, pero no creo que tenga el mismo soporte para Java.

Entonces, si desea usar un editor de texto más potente junto con Eclipse, definitivamente le recomendaría que aprenda vim o emacs. Pero como un suplemento, no como un reemplazo . Realmente puede dar sus frutos a largo plazo, aunque ninguno de ellos tenga una curva de aprendizaje particularmente fácil:)

Aquí hay una buena lectura larga sobre las fortalezas de vim. Y aquí hay una lista de algunos buenos trucos que puedes hacer.

Básicamente, lea esto (PDF) para ver por qué Emacs es poderoso. Una vez que conoce a Lisp, es casi trivialmente fácil escribir extensiones para él (tengo varios flujos de trabajo de control de origen y despliegues a través de un complemento que escribí para mí mismo llamado employer-mode). En cuanto a lo que enumeras arriba;

• Error al resaltar sin necesidad de volver a compilar el proyecto. No tiene sentido para todos los idiomas. Puede integrar fácilmente REPLsmuchos idiomas en él. En este momento, no tengo ruby, python, haskell, common lisp, schemey erlangtoda forma de gancho en emacs. Por cierto, el complemento de JavaScript js2-modetiene una "compilación" incremental completa, por lo que resalta cosas como errores de sintaxis para usted, por lo que ciertamente es posible, pero no es la norma
• Código de asistencia. hay un complemento para eso llamado autocomplete.el, creo, revisa el wiki de Emacs
• Refactorización Supongo que te refieres a "refactorización automatizada", que no tiene sentido en todos los idiomas. Probablemente existe para algunos, pero no lo sé.
• Llamada de apertura de la jerarquía / Declaración de apertura.
• Totalmente integrado con control de fuente. Tiene git-modeincorporado a partir de Emacs 22.3, no estoy seguro acerca de otro control de fuente
• El depurador está incluido. Idioma por idioma aquí. Generalmente, si tiene integración REPL, también tiene un depurador Emacs, pero no es universal
• Disponibilidad de complementos de terceros, por ejemplo, findbugs / checkstyle. no sé acerca de esos específicos, pero hay muchos complementos para ello, desde el por qué no es útil en el paquete base hasta el completamente frívolo

Dicho esto, si no te gusta Lisp y no tienes la intención de aprenderlo, honestamente no puedo recomendar Emacs. La ganancia que obtiene es aprender sobre la creación de herramientas y aplicar esos principios para aumentar su propia productividad, no obtener un montón de modificaciones estándar y unirlas.

Veo dos opciones aquí:

• Use Nano en su lugar: esto es exactamente como el Bloc de notas en Windows para Linux. Al no requerir combinaciones de teclas de acceso rápido, simplemente escribe nano somefile.confy tiene un buen editor. Incluso puede agregar resaltado de sintaxis
• Mantenga el programa localmente y sincronícelo a través de SCP con el servidor. Lo hago cuando necesito trabajar en un sitio web pequeño pero no tengo suficientes recursos para ejecutar Apache localmente. Simplemente abro WinSCP, saco los directorios que quiero y uso "Mantener actualizados los archivos remotos". Los cambios generalmente se reflejan en segundos
• Use un complemento en su editor / IDE para trabajar "directamente" con el archivo remoto. Antes de preocuparme por el control de revisión, simplemente encendí Notepad ++ (mi editor preferido) y usé NppFTP para trabajar en los archivos. NppFTP es más rápido que la opción WinSCP ya que Npp le dice inmediatamente cuándo se guarda un archivo, que se carga inmediatamente. Sin embargo, como dije, pierdes el control de la revisión. Estoy seguro de que hay un complemento para Eclipse que puedes usar

Espero que esto ayude

Personalmente, me gusta Vim porque es extremadamente bueno en la edición de texto, es decir, muy ergonómico (las combinaciones de teclas no fuerzan demasiado mis manos y no necesito usar tanto el mouse) y eficiente para usar una vez que dominas (lo que por supuesto tomará tiempo y paciencia, ya que no es el editor más intuitivo para principiantes).

Sin embargo, preferiría Eclipse para el desarrollo de Java a gran escala debido a las muchas características que están fácilmente disponibles. Por supuesto, hay algunos complementos que pueden hacer que Eclipse sea un poco más tolerable.

Si estás contento con Eclipse, entonces no cambies.

Si puede usar Eclipse en cualquier lugar que necesite, no cambie.

Si su proyecto / empresa usa Eclipse casi exclusivamente, no cambie.

Si rara vez necesita algo más, imprima una hoja de trucos para uno de los editores y sáquelo del cajón cuando lo necesite, y luego vuelva a usar Eclipse.

Vea la (misma) pregunta en SO: https://stackoverflow.com/questions/1346820/what-are-the-efficiencies-afforded-by-emacs-or-vim-vs-eclipse

En cuanto a responder, "¿Las personas que lo usan realmente trabajan en proyectos complejos orientados a objetos en grandes organizaciones?" - Sostén tu sombrero, hijo, pero la respuesta es "sí". He trabajado en proyectos con decenas de millones de líneas de código utilizadas en la ruta crítica de diseño de la CPU que ejecuta la computadora que está utilizando para hacer esta pregunta. Y la gente probó Eclipse pero descubrió que era demasiado lento y torpe (aunque, ciertamente, no estábamos usando Java).

Tanto emacs como vim son editores muy configurables y potentes, y ambos proporcionan grandes ganancias de productividad una vez que se comprenden los conceptos básicos.

Vi gana con lo que son esencialmente operaciones basadas en conjuntos. Por ejemplo, cambiar todas las instancias de "foo" a "bar" en una definición de clase es de una sola línea.

Emacs es igualmente poderoso, pero tienes que aprender Emacs Lisp para usarlo en todo su potencial.

En cualquier caso, solo vale la pena cambiar si planea usar emacs o vi para todo .

La mejor herramienta (a corto plazo) es aquella con la que eres muy competente.

Las personas usan tecnología de más de 30 años porque son muy competentes con ella. Desarrollaron su flujo de trabajo y hábitos en torno a estas herramientas. Si está más familiarizado con un IDE moderno como Eclipse, no hay muchas razones para cambiar. Aprender a usar Eclipse de manera más eficiente es una mejor inversión de su tiempo (por ejemplo, use Mylyn ).

Actualmente estoy tratando de cambiar de NetBeans a vim. Aprender vim requiere tiempo y práctica, pero veo sus ventajas, llamémoslas "editores de GUI" para ciertos casos.

Pero, a diferencia de usted, estoy codificando principalmente Ruby, y no necesito toda esa magia negra generadora de código, de autocompletado y refactorización de mi código que ofrecen NetBeans y Eclipse. Si estuviera codificando Java o C #, ciertamente no trataría de cambiar en absoluto.

Como usuario de emacs desde hace mucho tiempo, encuentro que emacs es bastante cómodo como entorno de edición y desarrollo (y, en cierta medida, también se integra con el proceso de compilación, el control de versiones, la búsqueda rápida sensible al contexto y similares, por lo que supongo que eso califica como un "IDE").

También me siento realmente cómodo con el uso de editores similares a vi y vi (comencé a usar ed, porque pensé que emacs era demasiado complejo; en retrospectiva, eso es al revés, pero me dio una base sólida para el aprendizaje futuro de vi). Utilizo vi principalmente para "pequeñas ediciones rápidas", principalmente en máquinas remotas donde no está instalado emacs.

Para su "en ocasiones necesito ssh en el servidor y jugar con los archivos de configuración; para esto uso el escenario vi", recomendaría un pequeño conjunto de comandos y algunas ideas generales sobre vi:

• Vi no es modal, tiene los comandos "a" (agregar), "A" (agregar al final de la línea), "i" (insertar) e "I" (insertar al inicio de la línea), tomando el texto para insertar como argumento y señalando "fin de comando" con Esc
• h, j, k y l son teclas de movimiento. PUEDE funcionar usando las teclas de flecha, pero como la secuencia típica del estilo VT "Soy una tecla de flecha" comienza con Esc, esto romperá el comando de inserción de texto en el que no está pensando
• : Linum te mueve a la línea Linum , la línea 1 es la línea superior y la línea $ es la inferior
• . es el comando "repetir último comando" (ver el primer punto)

No debería llevar más de una hora o dos jugar con vi para estar en el "Puedo editar con confianza un archivo de texto, pero es posible que no sea eficiente con él" y eso es tan bueno como probablemente necesitarás. . De lo contrario, cualquier editor que no se preocupe por la conversión automática entre pestañas y espacios debería ser "lo suficientemente bueno" para sus propósitos. Si Eclipse está instalado en todos sus servidores remotos, realmente no veo que usarlo sea un gran problema.

Soy mucho un chico Emacs. Lo uso para toda mi programación y aliento activamente a mis compañeros de trabajo a usarlo también (y me ignoran activamente). Lo encuentro mucho más productivo que cualquier IDE, y nunca cambiaría.

A menos que esté escribiendo Java o C # (e imagino que hay otros lenguajes en esta categoría). Tienen bibliotecas tan grandes de cosas con nombres largos, que las ganancias que obtengo al usar Emacs se pierden por completo al tratar de recordar todo.

Ciertamente te animo a probar vim y / o Emacs. Pero es probable que termines de nuevo en Eclipse para Java.

No tengo ningún problema con los diversos editores de UNIX disponibles, pero solo los uso como protesta. No, como digo, porque tengo un problema con ellos, sino porque si tengo que usarlos significa que nuestro proceso de implementación es de alguna manera insuficiente.

Probablemente esto merezca un poco más de contexto: trabajo en soluciones de comercio electrónico a gran escala, todo lo que rige el funcionamiento de nuestros sistemas se genera mediante un proceso de compilación / implementación con un solo clic. Tenemos una variedad de entornos de prueba, por lo que en cualquier momento puedo hacer un cambio a través de Eclipse, verificarlo en cvs y activar una compilación / implementación para demostrar que mi solución ha funcionado. Entonces, si estoy pirateando en 'vi', es porque no podemos esperar el cambio de 1 hora de una implementación o porque la implementación no cubre los archivos que estoy editando y debe extenderse para hacerlo así que (de lo contrario, estaré pirateando vi la próxima vez que el archivo en cuestión necesite cambiar)

Personalmente, ambos programas me llevan por la pared. El problema con Eclipse es que es lento como un moco cuando estás trabajando en un proyecto grande y es cuando no está haciendo 'DGLP Indexing' o lo que sea. quieres actualizar tu repositorio? tienes 15 minutos? Ah, y qué tal ese ingenioso truco donde Ctrl-C algo de texto y luego Ctrl-P en algún lugar, pero en lugar de ir a donde quisieras, abre un archivo completamente diferente y pasa sobre otra cosa y te preguntas si no estaba allí. en primer lugar. Ah, ¿y mencioné trabajar con eclipse en un proyecto grande en una VPN? Prácticamente imposible.

En cuanto a vim, es agradable y rápido, suponiendo que conoces la multitud de combinaciones de teclas completamente sin sentido para que haga algo y buena suerte si te encuentras en un modo desconocido por accidente. Además, con vim tienes que conocer la estructura completa del directorio de proyectos en tu cabeza para poder abrir los archivos correctos. La principal ventaja de Vim es que, en teoría, puede crear código más rápido porque es todo clave, pero en realidad no me importa cuánto texto estoy escribiendo, no es el volumen de texto lo que importa, es la calidad del código y, a menudo, la calidad el código requiere mirar decenas de archivos durante horas hasta que descubras exactamente lo correcto para escribir (que generalmente es muy corto).

Lo que deseo es que alguien escriba un programa de línea de comandos, como vim, que en realidad tenga una estructura de directorio como eclipse en el lateral o algo desde lo que pueda expandir / colapsar y abrir archivos. ¿Alguien sabe algo como esto?

Si no está satisfecho con VIM o EMACS, puede buscar en esa máquina otros editores de texto. Puede haber algún sabor de nedit o gedit o somesuch que pueda usar que tendrá comandos más familiares (ctrl x, c, v y s hacen lo que esperaría, por ejemplo).

Probablemente tenga más de dos opciones en su distribución, vale la pena echarle un vistazo.