#40260 Voy buscando algo mas tipo merge o el cliente de GitHub, que con un par de atajos lo hago, aunque probaré a hacerlo por bash a ver que tal
Solo te falta:
def is_odd(number):
return not is_even(number)Y descubrirás el nombre de la página más popular entre los programadores
vim es meterle memoria muscular a los comandos y combinaciones que tenga y ya
pero si lo quieres para abrir/cerrar con cuatro cosas te vale, yo no lo recomiendo como difftool/mergetool si no lo usas normalmente, para eso te quedas usando tu editor o ide random con la funcionalidad que tenga al respecto
mas que memoria muscular yo diría que es saber sacarle potencial concatenando instrucciones. Lo básico lo sacas en 2 tardes.
a mí eso me resultó fácil; al final usar las herramientas que tenía para realizar tareas repetitivas me era evidente una vez sabía cómo moverme, pero mecanizar ese uso es lo que se me hizo difícil
que al final si te lo tomas en serio tardas una semana en sentirte cómodo (aunque, como emacs, siempre estarás aprendiendo cosas)... yo aprendí a programar y a la vez aprendí a usar vim así que me costó muuucho hacerme a ello xd
Ahora mismo uso prácticamente para todo Sublime Text y he pillado relativa soltura a sus atajos y al command palette y para diff/merge pues el Sublime Merge.
También hace un par de días me dieron un pack de licencias de JetBrains e igual pruebo alguno de los IDEs (PHP Storm y WebStorm imagino).
El tema es, por curiosidad, alternativas a ese combo (a parte de acostumbrarme a trabajar con repos) y ver con que me siento mas cómodo.
Con el emulador de vim, y mapeando tus atajos a funcionalidades nativas del editor para trabajar de la misma forma, esté picando c# en vs, java en idea, typescript en vscode o python o rust en nvim :>
sin olvidar el navegador y otros programas o entornos que soportan vi binds
Yo uso vim a diario para modificar ficheros de configuración en los propios servers donde hay desplegadas cosas, para todo lo demás VS Code y cuando me toca picar C# visual studio
yo creo que meterte en un editor modal "de vez en cuando" no tiene mucho sentido; no está nano instalado por defecto en cualquier distro desde hace mil?
A raiz de un tweet que he visto hoy os pregunto.... ¿Que monitor usáis? ¿16:9? ¿16:9 girado? ¿4:3? .... ¿Cual es el mejor monitor para trabajar con código?
Con saber wq! vas que ardes para editar leches en servidores.
#40277 Cualquiera que te permita tener "dos 1080p" abiertos a la vez.
#40276 siempre puedes editar a través de ssh con el editor que quieras, pero entre nano y vim, "sin saber usar vim", me quedo con nano de calle.
De hecho la milonga esta de git de usar por defecto vim me parece una aberración, y de gilipollas pretender perpetuar esa cultura.
#40282 pero en la documentación te guía usando vim, y en otras herramientas parecido. Gitbash te empaqueta vim si le metes la instalación completa y te "fuerza" a usarlo.
Entonces en todo caso tu queja sería hacia git bash.
En una distribución de linux git te instala git y nada mas, y te abre el editor que tengas con mo editor del sistema
en parte tienes razón pero mi lloro no deja de ser menos válido cuando en muchas distros el editor por defecto es vim (aunque eso quizás haya cambiado en los últimos años)
edit: con lo de perpetuar esa cultura me refiero a todos los docs que te guían usando vim porque sí, no a que la gente lo use o lo deje de usar que eso ya cada uno que haga lo que quiera
Que yo no quiero tener que aprenderme un set de reglas obtusas para realizar tareas elementales. Algo bien diseñado o planteado se hace evidente y su complejidad está ligada al problema que pretende solucionar.
#40288Wei-Yu:Que yo no quiero tener que aprenderme un set de reglas obtusas para realizar tareas elementales.
Pues no te las aprendas y usa el editor que te salga de las pelotas xD
#40288 Si a alguien le parece que para usar vi hay que "hay que aprender un set de reglas obtusas", quizá no debería dedicarse a hacer lo que hace. Just sayin'
