lwordl escribió:Aprovecho para preguntar, que le veis al vim para decantarse en favor a otros ide?
Mr.Gray Fox escribió:La gente que recomienda VIM ¿es por algo en particular o porque les gusta programar con una mano atada en la espalda? Dos veces he intentado darle una oportunidad, pero entre la inmensidad de atajos que tiene y lo soso que es, le dije un elegante Fuck this y volví a los brazos de Qt.
Podría hablar de lo cómodo que es no necesitar el ratón o que se puede usar a través de SSH, pero hay una treintena de editores que hacen eso. Para mí las ventajas están por este otro lado (aunque esas dos son geniales):
1) Expresiones regulares integradas en todo. Las búsquedas por defecto son expresiones regulares. Además, incluye el comando :s[ubstitute] para realizar sustituciones. No voy a cambiar el estilo de comillas o el nombre de una variable en un bloque de texto mecánicamente pudiendo usar una orden. Si por ejemplo quieres subrayar una línea para darle importancia en un comentario o en un texto plano, puedes duplicarla con yyp y convertirla en una serie de = con :s/./=/g. Si lo haces a menudo puedes añadirlo al archivo de configuración en forma de función o como atajo de teclado.
2) Diversos comandos para editar simultáneamente a lo largo de varios ficheros. :norm[al] permite ejecutar una cadena de atajos arbitaria, :g[lobal] permite ejecutar un comando sobre líneas que correspondan con una expresión regular y :bufdo permite ejecutar un comando sobre los ficheros abiertos. Si por ejemplo quiero reindentar todos los ficheros abiertos a la vez haría :bufdo norm gg=G, o si quiero borrar todos los prints de un fichero sería :%g/print/d. Esto es algo a lo que le saco provecho constantemente. Por ejemplo:
- Tengo escrito un Makefile y quiero generar la lista de objetivos falsos para las tareas. Copio el texto entero, abro un buffer temporal, lo pego, borro lo que no sean objetivos con :%g!/:/d, los ordeno con :sort, borro los que no me interesen, los empalmo todos con algo como 100J y añado .PHONY: por delante. Ya tengo la línea lista para añadirla al fichero original.
- Ahora mismo mi gestor de marcadores es un alias que abre un puñado de ficheros con vim. Si quisiera por ejemplo borrar todos los enlaces de EOL a la vez usaría :bufdo %g/elotrolado\.net/d.
- Como bash y zsh permiten abrir el comando actual en un editor abro una sesión, cojo el código fuente de una página, filtro las URLs con un script que ya tengo hecho, borro los enlaces que no me interesan con :global y ya lo tengo listo para mandárselo a wget o lo que se tercie.
3) El acceso a ficheros, lo que se empareja con la jumplist. Una búsqueda entre ficheros llena la quickfix list para saltar de un resultado a otro, gf abre el fichero especificado por la cadena de texto sobre la que tienes el cursor, o siempre puedes usar el fiel :e[dit] para abrir un fichero. Tanto esto como las búsquedas de texto dentro un fichero llenan la jumplist con referencias, que te permiten trazar tus pasos hacia delante y hacia atrás. Es como dejarte un rastro de migas de pan a lo largo de tu proyecto y despreocuparte de recordar en dónde estabas. Además gx abre cosas en el navegador, lo que explica eso de que lo use como gestor de marcadores.
4) La función de deshacer. Ya, todos los editores hacen esto, pero vim tiene la opción de guardar un historial de deshacer externo que perdura entre sesiones. Lo cuál no está mal si quieres evitar ataques si se cuelga el ordenador. Además mantiene un árbol de cambios, de forma que si vuelves atrás y realizas una acción no se pierden las ediciones posteriores. Algo a tener en cuenta con lo común que es volver hacia atrás cuarenta pasos para coger un trozo de código sin cagarla y perder el trabajo.
5) Puedes acceder a los comandos del sistema. Si puede convertir texto en texto, puedes usarlo para editar parte de un fichero en vim. tidy para limpiar el html, pandoc para traducir entre formatos o tr porque, no sé, te gusta tr. Por razones, hice un traductor para pandoc con el que convertir texto a BBCode. Desde entonces puedo abrir un campo de texto en gvim con la extensión It's All Text, escribir en Markdown y traducirlo. Sólo por poder mantener los enlaces como una lista al pie del texto vale la pena.
6) Usa programas externos que se pueden sustituir. Por si mismo usa make, grep y man entre otros, pero puedes cambiarlos por cmake, rake, ack, ag o lo que mejor te convenga. Con el bonus de que cada herramienta usa su configuración de sistema sin tener que definirla en vim. Entre esto y lo anterior, vim goza de una naturaleza modular que no te encierra dentro de un ecosistema. Lo puedes adaptar al lenguaje y al entorno en el que te encuentres. Mantener un grupo de herramientas separadas para edición, creación de tags, búsqueda, compilación, baterías de tests, creación de paquetes, etcétera; no sólo te deja cambiarlas individualmente por otras que te gusten más, también te da la libertad de deshacerte de vim por otro editor. Creo ese tipo de cosas compensan a la larga.
7) :read. Pegar un fichero a otro puede ser molesto. Copiar la salida de texto de un comando es lo peor. :read fichero inserta el contenido de un fichero bajo el cursor, lo que está bien supongo. :read !comando inserta la salida de un comando, lo que es la leche. ¿Quieres añadir una estructura de ficheros a la documentación? :read !tree ¿Necesitas añadir la lista de recursos en una función? :read !ls ./assets/.
8) Hooks. Por llamarlo de alguna manera. Puedes definir acciones para los ficheros al abrirlos, crearlos o guardarlos si cumplen ciertas condiciones. Así por ejemplo puedes borrar los espacios sobrantes en una línea. En mi caso me aprovecho de que puedes definir opciones de forma local para un fichero para desactivar las copias de seguridad de archivos temporales o para evitar estropear el indentado de los makefiles. El manual oficial hasta te sugiere usarlo como un sistema rudimentario de plantillas, rellenando un fichero nuevo con el contenido de otro. Cualquier comando que se pueda usar en una sesión de vim, se puede usar aquí.
9) vimdiff. Igual no es el mejor programa para editar diferencias entre archivos, pero sí el que más me ha gustado. Además es la opción por defecto de git para editar conflictos y consigo editar el fichero a tres bandas sin quebrarme la cabeza.
10) Puedes asignar marcas a lo largo del texto o de varios ficheros para saltar automáticamente a ellos, o todavía más chachi, para definir un rango arbitrario sobre el que ejecutar una acción. Además hay una serie de marcadores especiales, como uno que salta automáticamente a la última línea editada del fichero. Es increíble lo feliz que te puede hacer una tontería así.
11) El que más el que menos, cualquier editor de código tiene autocompletado. Lo interesante de vim es la cantidad de fuentes que se pueden especificar. Es capaz de autocompletar texto del fichero actual, de otros ficheros abiertos, de ficheros cuya ruta aparezca en los ficheros abiertos, de diccionarios, de tesauros, de correctores ortográficos y de archivos de tags. También puedes completar líneas completas, que es algo que no suelo ver en otros lados y resulta más útil de lo que aparece. Aunque un IDE específico para un proyecto tiende a superarlo en conveniencia.
12) Los atajos. Sí, sí, es una respuesta estándar, pero cuando los usas un tiempo tienen sentido. No me hago a la idea de no poder borrar hasta el final de la línea, limpiar el interior de unos paréntesis o deshacerme del interior de un bucle con un par de pulsaciones. O de borrar algo y que por defecto se pueda pegar en otra parte. O de poder saltar a un caracter arbitrario. O poder buscar y/o reemplazar sin tener que lidiar con pop-ups. O usar el punto para repetir una acción. Un día se me va a romper la tecla de tanto usarla. Al principio es alienígena, pero son mecanismos racionales cuando tienes en cuenta cómo se escribe el código.
Para mí usar otra cosa es lo que hace que sienta que tengo una mano atada a la espalda. Seguramente es como se siente alguien que usa emacs y mira al resto preguntándose cómo pueden hacer nada sin un REPL decente, sin org-mode o sin la capa de meta-programación de elisp. Usarlo como un bloc de notas con controles rarunos lógicamente es incomodísimo y vas a ser mucho más feliz en otra cosa.
Obviamente otros entornos tienen sus propias ventajas. Por ejemplo, el análisis de símbolos de un IDE específico es mil veces superior a lo que es capaz de ofrecer el estándar de ctags. A veces preparar a mano los requisitos de un proyecto para manipularlo es ridículamente complicado. No todos los proyectos son iguales y no todos los programadores tienen las mismas necesidades. La herramienta más práctica no siempre es un todoterreno como vim, y parte de su atractivo se encuentra en el entorno en el que reside. Si por ejemplo lo usas en Windows, la mitad de las ventajas desaparecen mágicamente. Y aun así usar un IDE para sus cosas especiales de IDE y vim para editar el código sigue siendo una opción viable.
Esa es, uhm, mi breve explicación sobre por qué aprender a usar vim.
) este posee muy buena integración con git para ver cambios entre ramas etc. De atom me pase a phpstorm y la verdad que me ha gustado, uno de los puntos débiles es el consumo de ram pero aparte de eso todo bien 
![[burla2]](/images/smilies/nuevos/burla_ani1.gif "burla2")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
