Vsvim: cc não coloca o cursor no recuo se estiver na linha vazia

Criado em 8 mai. 2012  ·  10Comentários  ·  Fonte: VsVim/VsVim

cc exclui a linha atual e coloca o cursor no modo de inserção (a opção 'autoindent' determina sua posição).

O VsVim nem sempre coloca o cursor na posição correta. O único caso que consegui reproduzir consistentemente é que se você colocar em uma linha vazia, o cursor colocará o cursor na primeira coluna em vez de no recuo.
Considere o seguinte código inicial C # ([] é o ncursor, | o icursor):

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

Pressione o para abrir a linha abaixo:

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

Agora pressione Esc :

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

Agora pressione cc . É aqui que o Vim e o VsVim diferem: o Vim colocará o cursor recuado dentro da barra:

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

enquanto o VsVim o colocará na linha 0:

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

Como alternativa, use este código:

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

Tanto no Vim quanto no VsVim, um único cc colocará o cursor na posição recuada, mas cc<Esc>cc colocará o cursor na coluna 0 do VsVim (enquanto o Vim o colocará no recuo à direita).

bug

Comentários muito úteis

Essa solução simples me dá o comportamento que espero do vim:

nmap S ddO
nmap cc S

Todos 10 comentários

O comportamento que vejo no VsVim reflete o que vejo no gVim.

Acho que alternamos uma configuração diferente. Na verdade, vejo uma diferença de comportamento após o passo 'o' no topo. Meu cursor aparecerá na mesma coluna que { e não recuado como o seu estava.

Você pode executar :set e colar a saída?

autoindent parece ser uma daquelas opções que defini no meu vimrc, que então source no vsvimrc.

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

O VsVim leva em consideração as configurações de indentação no VS? Se sim, aqui estão os meus (em Opções -> Editor de Texto -> C # -> Formatação):

  1. Indentação (indentação do conteúdo do bloco, caixa, rótulos, não indente as chaves de abertura / fechamento)
class MyClass
{
    public void Method()
    {
        goto MyLabel;
MyLabel:
        return;
    }
}
  1. Em Novas Linhas, tenho tudo verificado
  2. Espaçamento: tudo desmarcado exceto "Definir outras opções de espaçamento" - inserir espaço após as palavras-chave nas instruções de fluxo de controle; "Definir espaçamento para delimitadores" -: após dois pontos para base, após vírgula, após ponto e vírgula em para, antes de dois pontos para base; "Definir espaçamento para operadores": antes e depois.

Não sei se isso também importa, mas defini o recuo como Smart, tamanho 4, Manter guias.

HTH

Sim, autoindent parece ser a diferença. Depois de definir isso e salvá-lo como um arquivo .c, pude obter o comportamento que você estava vendo.

Deu uma olhada rápida no código e parece haver um problema com linhas vazias. O código não respeita autoindent quando a linha excluída estava vazia, o que aparentemente deveria.

Em geral, o VsVim prefere o recuo do Visual Studio ao invés do Vim. Isso pode ser anulado desativando a opção vsvim_useeditorindent .

Isso geralmente funciona. Infelizmente, em 2010, embora nem todas as linguagens ofereçam boas APIs para serviços de recuo. C # tem o melhor, VB praticamente não tem e C ++ é um jogo de dados. Eu acredito que fica melhor no VS11, mas ainda não brinquei o suficiente para ver o quanto.

Vou tentar espremer essa correção em 1.3

Brincando um pouco mais, esse comportamento é, na verdade, desviado de cindent e não autoindent . Esse é um dos motivos pelos quais demorei tanto para reproduzir o problema. Eu estava experimentando em arquivos de texto onde autoindent estava habilitado. Isso apenas repros em arquivos C com cindent ativado.

Você está certo, eu consegui reproduzi-lo também depois que você mencionou com vim -U NONE -u NONE -cmd 'set cindent' index.cs

Em configurações normais, o Vim parece estar configurando cindent automaticamente quando em arquivos C-like (aparece em :setl em C # e JS).
No entanto, o mesmo comportamento - remover recuo em <Esc> , recuar novamente em cc - parece acontecer em arquivos não cindent : apareceu para mim em CSS e HTML, mas, nesses casos, pode ter sido o efeito de indentexpr .

@philipmat
@jaredpar

Olá pessoal, encontrei o mesmo problema.
Está corrigido na versão mais recente?
Saída após :set

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

@lookforit no momento não. Este comportamento é na verdade uma parte de cindent que não é suportado pelo VsVim neste momento.

Essa solução simples me dá o comportamento que espero do vim:

nmap S ddO
nmap cc S

Isso ainda seria bom ter. Minha sensação intuitiva é que o 'cc' para limpar uma linha e começar a editar deve começar no mesmo nível de recuo da criação de uma nova linha. Existe um raciocínio interno do Vim / VS de que não deveria ser assim? Posso encarar isso como uma incursão no trabalho com o projeto.

A solução para este problema era superficialmente nada mais do que "fazer por cc tudo o que o já estava fazendo" (é por isso que a solução alternativa de

O VsVim já estava fazendo a coisa certa para o chamado "recuo do vim", o tipo de recuo que o VsVim usa quando não há serviço de idioma disponível. Para adicionar testes para esse problema, tive que adicionar infraestrutura aos testes para simular um serviço de linguagem. Portanto, a desconexão foi que todos os testes existentes usam "vim indent", mas 99% dos usuários estão usando "host indent", ou seja, estão editando arquivos onde o Visual Studio fornece um serviço de indentação.

Para complicar ainda mais o problema, havia um bug que ninguém nunca relatou com "vim indent", onde não funcionava corretamente quando as guias não estavam sendo expandidas (consulte o problema # 2302). Novamente, de um ponto de vista prático, ninguém usa "vim indent", portanto, refletindo, isso não é tão surpreendente.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

ogirginc picture ogirginc  ·  6Comentários

drhoda picture drhoda  ·  7Comentários

DanielKeogh picture DanielKeogh  ·  3Comentários

kkorus picture kkorus  ·  7Comentários

deevus picture deevus  ·  4Comentários