Los modos son la característica asesina de vim? En serio?

Autor de la publicación original en ruso: varanio

Es posible que haya leído un artículo reciente que sugiere que vim es excelente a diferencia de los IDE , debido a su velocidad de escritura supuestamente baja.

Recordemos que el mensaje principal de ese artículo fue que la característica asesina de vim consiste en sus modos que eclipsan todo lo demás. Dicho esto, el autor reconoció que IntelliJ IDEA y otros IDE proporcionan teclas de acceso rápido y otra experiencia de usuario que se puede usar fácilmente. Sin embargo, dado que carecen de modos, se supone que vim es la primera opción de todos.

Luego, el autor sugiere que en lugar de presionar ctrl+arrows para moverse entre las palabras, es más fácil presionar Esc, e y luego volver al modo de edición i . Es comprensible que todo este problema se deba a que el autor encuentra inconveniente mantener ctrl .

Sé que los artículos que critican a VIM obtienen muchos votos negativos, pero solo tengo que hablar.

¿Sus líneas de código son tan largas que su dedo se cansa presionando la tecla hasta el punto donde realmente necesita modos? Puedo obtenerlo cuando está escribiendo una constante larga; en este caso, puede presionar Bloq Mayús y escribir su nombre. Incluso entonces, apenas presiono esta tecla más de una vez al año. Pero cambiar de modo de un lado a otro para avanzar un par de palabras, y mucho menos para llamar a la característica asesina de ese vim, parece un poco exagerado.

Por cierto, en IntelliJ IDEA, puede cambiar el caso de una palabra (o el texto seleccionado) con una tecla, por lo que tampoco es necesario usar Bloq Mayús.

Admito que vim puede ser bueno para editar archivos de configuración en un servidor remoto. Además, vim puede ser excelente para nuevos idiomas con los que JetBrains aún no ha jugado. Escribir complementos personalizados es más fácil para vim (pero en el 99% de los casos no los necesitará con un IDE adecuado). Quizás, es más conveniente para editar textos largos. ¡Pero eso es irrelevante para la codificación industrial estándar!

Debo mencionar de inmediato varios puntos aquí.

Vim se puede convertir en una especie de IDE instalando complementos y aprendiendo teclas de acceso rápido para operar esos complementos


De hecho puede, pero ¿por qué alguien se molestaría?

Parece un desafío extraño teniendo en cuenta que los IDE lo tienen todo y con una experiencia mucho más fácil de usar. ¡No tendrá que usar un mouse, lo prometo!

Permítanme explicar el asunto con la edición sin mouse usando un ejemplo. Primero abro IntelliJ IDEA y creo un nuevo archivo.

Presiono p, y el IDE me solicita inmediatamente una sugerencia del paquete de palabras. Todo lo que necesito hacer es presionar Enter para poner el paquete de palabras en el texto dentro del editor.

Luego presiono c , y el IDE sugiere clase a la vez.

Habr el nombre de la clase (por ejemplo, Habr ), Habr la llave rizada { , y el IDE completa automáticamente la llave de cierre justo detrás del cursor.

Luego escribo pu, y el IDE entiende que probablemente sea público. Escribo H y presiono Enter para obtener Habr, porque el IDE ya lo tiene y quiero crear un constructor.

Procedo a escribir el cuerpo del constructor, por ejemplo, llamo al método init (), que aún no está allí. Mi IDE lo resalta con color rojo, lo que indica que este método no existe. Una vez que presiono alt-ENTER , el IDE insertará el fragmento de código en el lugar correcto:

  private void init() { } 

Si new Habr(5) dentro de este método (la palabra Habr también se solicitó, por supuesto), es decir, si trato de llamar a un constructor no existente, IntelliJ IDEA subrayará ese bit de inmediato, así que solo presiono <alt-ENTER> y elija qué es exactamente lo que quiero hacer: si es agregar un argumento int al constructor o agregar un nuevo constructor con un parámetro int. Elijo la última opción, y el IDE agrega inmediatamente un nuevo constructor después de la primera:

 public Habr(int i) { } 

No mencionaré la sangría automatizada y otras características que lo ayudan a editar el código, ya que, naturalmente, están presentes.

Esto es lo que obtuve al final:

 package x; class Habr { public Habr() { init(); } public Habr(int i) { } private void init() { new Habr(5); } } 

Todo lo que hice fue literalmente presionar un par de teclas y la <alt-ENTER> acceso <alt-ENTER> .
No instalé ningún complemento.
No tuve que entrenar durante un mes para poder hacer esto.

NUNCA TOCÉ EL RATÓN (utilicé Caps Lock aquí no porque quisiera gritar como un loco, sino porque fue divertido probar la función).

No cambié a ningún modo y no tuve que recuperar ninguna combinación de teclas o perillas. El único que usé fue <alt-ENTER> (pero eso era algo dependiente del contexto, una especie de tecla de acceso rápido para "resolver problemas").

Si odia usar el mouse, puede navegar por el código con teclas de acceso rápido especiales, como saltar a la clase, archivo, método, número de línea, etc.

Puede seleccionar texto presionando repetidamente <ctrl-W> para seleccionar la palabra actual, el texto actual entre llaves, etc.

Vim te permite saltar a un personaje en particular. Por ejemplo, puede llegar a una letra x en la línea de texto sin tocar el mouse. Sin embargo, un IDE también le brinda esta oportunidad presionando <ctrl-f> y escribiendo el fragmento de texto requerido. Esto también es una especie de modo por cierto. Se llama el modo de búsqueda, duh!

Tampoco necesito el mouse para saltar a la llamada a la función correcta y luego, nuevamente sin el mouse (presionar ctrl-b ), para saltar a la descripción de esta función.

Vim tiene varias características de edición únicas que faltan en IDE


  • Ir al siguiente / anterior párrafo.
    Sí, parece una función útil para un IDE. Sino más bien para editar artículos para Habr que para la codificación real.
  • Moverse al siguiente personaje espacial.
    Bueno, puedes llamarlo una característica útil, pero no demasiado genial. La presión repetida de las ctrl+arrows producirá el mismo efecto.
  • Saltar media página arriba / abajo.
    Todavía no he decidido si necesito este para algo.
  • Saltar a la primera / última / línea media en la pantalla.
    Realmente no veo para qué es esto. Es decir, puede ser útil en algún momento, pero de ninguna manera es una característica asesina.
  • Es posible eliminar exactamente N líneas de código.
    Sí, claro, hago esto todos los días. Todo el mundo necesita eliminar exactamente 19 líneas de código de vez en cuando, ¿verdad?

No soy de ninguna manera un vim guru, por lo que puede haber pasado por alto algunos aspectos clave. Por favor comparte tus pensamientos en la sección de comentarios. Sí, por supuesto, hay millones de complementos además de eso. Pero los IDE también los tienen, y en cantidades comparables.

Resumen


Aquí está mi propia conclusión de esto. Me mantendré alejado de vim cuando se trata de edición de código, no importa lo que digas. No estaba muy impresionado con el uso de modos en lugar de mantener ctrl o incluso ctrl-alt-shift . Los IDE le brindan más funciones listas para usar, sin la necesidad de pasar un tiempo aprendiendo y asignando teclas de acceso rápido . La mayoría de las tareas diarias se pueden lograr con un IDE aprendiendo solo un par de teclas de acceso rápido. Incluso puede omitirlos por completo si está satisfecho con el mouse.

Hace tiempo que se estableció que un programador tarda más tiempo en aprender el código que en escribirlo. Entonces, si usará su mouse o no, no hace una gran diferencia. Sin embargo, permítanme reiterar que IDEs le permite hacer casi todo (si no todo) sin usar el mouse.

Vim funcionará mejor que nano para editar de forma remota archivos de configuración en un servidor, siempre que se cumplan las siguientes condiciones:

  1. Necesitas tener un buen agarre de vim.
  2. Necesita editar cantidades industriales de archivos de configuración para sentir la ventaja. Si solo necesita hacer cambios en un archivo de configuración una o dos veces al mes, nano o cualquier cosa funcionará bien.

Puedes comenzar a rechazarme o, mejor aún, ofrecer tus contraargumentos :).

Source: https://habr.com/ru/post/es436004/


All Articles