Vsvim: cc no coloca el cursor en sangría si está en una línea vacía

Creado en 8 may. 2012 · 10Comentarios · Fuente: VsVim/VsVim

cc elimina la línea actual y coloca el cursor en modo de inserción (la opción 'autoindent' determina su posición).

VsVim no siempre coloca el cursor en la posición correcta. El único caso que logré reproducir consistentemente es que si coloca el cursor en una línea vacía, colocará el cursor en la primera columna en lugar de en la sangría.
Considere el siguiente código C # inicial ([] es el ncursor, | el icursor):

class Foo {
    public void Bar()
    [{]
    }
}

Presione o para abrir la línea a continuación:

class Foo {
    public void Bar()
    {
        |
    }
}

Ahora presione Esc :

class Foo {
    public void Bar()
    {
[ ]
    }
}

Ahora presione cc . Aquí es donde Vim y VsVim difieren: Vim colocará el cursor sangrado dentro de la barra:

class Foo {
    public void Bar()
    {
        |
    }
}

mientras que VsVim lo colocará en la línea 0:

class Foo {
    public void Bar()
    {
|
    }
}

Alternativamente, use este código:

class Foo {
    public void Bar()
    {
        throw new NotImplementedException()[;]
    }
}

Tanto en Vim como en VsVim, un solo cc colocará el cursor en la posición con sangría, pero cc<Esc>cc colocará el cursor en la columna 0 en VsVim (mientras que Vim lo colocará en la sangría derecha).

bug

Fuente

philipmat

Comentario más útil

Esta sencilla solución me da el comportamiento que espero de vim:

nmap S ddO
nmap cc S

shkm en 13 jul. 2014

👍4

Todos 10 comentarios

El comportamiento que veo en VsVim refleja lo que veo en gVim.

Creo que tenemos una configuración diferente activada. De hecho, veo una diferencia de comportamiento después del paso 'o' en la parte superior. Mi cursor aparecerá en la misma columna que { y sin sangría como la tuya.

¿Puedes ejecutar :set y pegar la salida?

jaredpar en 9 may. 2012

autoindent parece ser una de esas opciones que he configurado en mi vimrc, que luego source en vsvimrc.

hlsearch
ignorecase
incsearch
scrolloff=5
smartcase
vimrc="C:\Users\pmateescu\_vsvimrc"
vimrcpaths="C:\Users\pmateescu;C:\Users\pmateescu"
autoindent
number
tabstop=4

¿VsVim tiene en cuenta la configuración de sangría en VS? Si es así, aquí están los míos (en Opciones -> Editor de texto -> C # -> Formato):

Sangría (sangría del contenido del bloque, caso, etiquetas, no sangra las llaves de apertura / cierre)

class MyClass
{
    public void Method()
    {
        goto MyLabel;
MyLabel:
        return;
    }
}

Bajo nuevas líneas tengo todo revisado
Espaciado: todo sin marcar excepto "Establecer otras opciones de espaciado" - Insertar espacio después de las palabras clave en las declaraciones de flujo de control; "Establecer espacio para delimitadores" -: después de dos puntos para la base, después de la coma, después del punto y coma en para, antes de dos puntos para la base; "Establecer espaciado para operadores": antes y después.

No sé si esto tampoco importa, pero tengo la sangría configurada en Inteligente, tamaño 4, Mantener pestañas.

HTH

philipmat en 9 may. 2012

Sí, la sangría automática parece ser la diferencia. Una vez que configuré eso + lo guardé como un archivo .c, pude obtener el comportamiento que estaba viendo.

Eché un vistazo rápido al código y parece ser un problema con líneas vacías. El código no respeta autoindent cuando la línea eliminada estaba vacía, lo que aparentemente debería.

En general, VsVim prefiere la sangría de Visual Studio sobre la sangría de Vim. Esto se puede anular desactivando la opción vsvim_useeditorindent .

En general, esto funciona. Desafortunadamente, en 2010, aunque no todos los lenguajes proporcionan buenas API para servicios de sangría. C # tiene lo mejor, VB prácticamente no tiene y C ++ es una tirada de dados. Creo que mejora en VS11, pero aún no he jugado lo suficiente para ver cuánto.

Intentaré exprimir esta corrección en 1.3

jaredpar en 9 may. 2012

Jugué un poco más y este comportamiento en realidad está fuera de cindent y no autoindent . Ésta es una de las razones por las que tardé tanto en reproducir el problema. Estaba experimentando con archivos de texto donde tenía autoindent habilitado. Esto solo repros en archivos C con cindent en.

jaredpar en 14 may. 2012

Tienes razón, logré reproducirlo también después de que lo mencionaste con vim -U NONE -u NONE -cmd 'set cindent' index.cs

En configuraciones normales, Vim parece estar configurando automáticamente cindent cuando se encuentra en archivos tipo C (se muestra en :setl tanto en C # como en JS).
Sin embargo, el mismo comportamiento - eliminar la sangría en <Esc> , volver a sangrar en cc - parece ocurrir en archivos que no son cindent : me apareció tanto en CSS como en HTML, pero en esos casos podría haber sido el efecto de indentexpr específicos.

philipmat en 14 may. 2012

@philipmat
@jaredpar

Hola chicos, me encontré con el mismo problema.
¿Está arreglado en la última versión?
Salida después de :set

backspace="indent,eol,start"
hlsearch
ignorecase
incsearch
autoindent

lookforit en 8 jul. 2014

@lookforit en este momento no. Este comportamiento es en realidad parte de cindent que no es compatible con VsVim en este momento.

jaredpar en 8 jul. 2014

Esta sencilla solución me da el comportamiento que espero de vim:

nmap S ddO
nmap cc S

shkm en 13 jul. 2014

👍4

Esto aún sería bueno tenerlo. Mi sensación intuitiva es que el 'cc' para borrar una línea y comenzar a editar debe comenzar en el mismo nivel de sangría que la creación de una nueva línea. ¿Existe un razonamiento interno de Vim / VS de que esto no debería ser así? Puedo abordarlo como una incursión en el trabajo con el proyecto.

wellspun en 13 jul. 2018

La solución a este problema fue superficialmente nada más que "hacer por cc lo que o ya estaba haciendo" (razón por la cual la solución de

VsVim ya estaba haciendo lo correcto para la llamada "sangría vim", el tipo de sangría que usa VsVim cuando no hay un servicio de idiomas disponible. Para agregar pruebas para este problema, tuve que agregar infraestructura a las pruebas para simular un servicio de idiomas. Entonces, la desconexión fue que todas las pruebas existentes usan "sangría vim" pero el 99% de los usuarios están usando "sangría de host", es decir, están editando archivos donde Visual Studio proporciona un servicio de sangría.

Para complicar aún más el problema, hubo un error que nadie informó con "vim indent" en el que no funcionaba correctamente cuando las pestañas no se estaban expandiendo (consulte el número 2302). Nuevamente, desde un punto de vista práctico, nadie usa "vim indent", por lo que, después de reflexionar, esto no es tan sorprendente.