Vsvim: cc не помещает курсор в отступ, если на пустой строке

Созданный на 8 мая 2012  ·  10Комментарии  ·  Источник: VsVim/VsVim

cc удаляет текущую строку и переводит курсор в режим вставки (опция 'autoindent' определяет его позицию).

VsVim не всегда помещает курсор в нужное положение. Единственный случай, который мне постоянно удавалось воспроизвести, - это если вы cc на пустой строке, он поместит курсор в первый столбец, а не на отступ.
Рассмотрим следующий начальный код C # ([] - ncursor, | icursor):

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

Нажмите o чтобы открыть строку ниже:

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

Теперь нажмите Esc :

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

Теперь нажмите cc . В этом разница между Vim и VsVim: Vim поместит курсор с отступом внутри панели:

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

а VsVim поместит его в строку 0:

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

В качестве альтернативы используйте этот код:

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

И в Vim, и в VsVim один cc поместит курсор в позицию с отступом, но cc<Esc>cc поместит курсор в столбец 0 в VsVim (в то время как Vim помещает его в правый отступ).

Самый полезный комментарий

Этот простой обходной путь дает мне поведение, которое я ожидаю от vim:

nmap S ddO
nmap cc S

Все 10 Комментарий

Поведение, которое я вижу в VsVim, отражает то, что я вижу в gVim.

Я думаю, что у нас переключены другие настройки. Я действительно вижу разницу в поведении после шага «о» наверху. Мой курсор появится в том же столбце, что и { без отступа, как у вас.

Можете ли вы запустить :set и вставить результат?

autoindent похоже, является одним из тех параметров, которые я установил в моем vimrc, которые я затем source в vsvimrc.

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

Учитывает ли VsVim настройки отступа в VS? Если да, то вот мои (в разделе Параметры -> Текстовый редактор -> C # -> Форматирование):

  1. Отступ (отступ для содержимого блока, регистра, меток, без отступа открывающих / закрывающих фигурных скобок)
class MyClass
{
    public void Method()
    {
        goto MyLabel;
MyLabel:
        return;
    }
}
  1. Под New Lines я все проверил
  2. Интервал: все не отмечено флажком, кроме «Установить другие параметры интервала» - вставлять пробел после ключевых слов в операторах потока управления; «Установить интервал для разделителей» -: после двоеточия для базы, после запятой, после точки с запятой для, перед двоеточием для базы; «Установить интервалы для операторов»: до и после.

Я не знаю, имеет ли это значение, но у меня установлен отступ Smart, размер 4, Keep tabs.

HTH

Да, кажется, что в autoindent есть разница. Как только я установил это + сохранил его как файл .c, я смог получить поведение, которое вы видели.

Бросил беглый взгляд на код, и похоже, что это проблема с пустыми строками. Код не уважает autoindent когда удаленная строка была пустой, что, по-видимому, должно быть.

В общем, VsVim предпочитает отступ Visual Studio над отступом Vim. Это можно изменить, отключив параметр vsvim_useeditorindent .

В основном это срабатывает. К сожалению, в 2010 году не все языки предоставляют хорошие API для служб отступов. У C # все самое лучшее, у VB их практически нет, а у C ++ - игра в кости. Я считаю, что в VS11 все становится лучше, но еще не поигрался, чтобы увидеть насколько.

Попробую втиснуть это исправление в 1.3

Поигрался еще немного, и это поведение фактически связано с cindent а не с autoindent . Это одна из причин, по которой мне потребовалось так много времени, чтобы воспроизвести проблему. Я экспериментировал с текстовыми файлами, где у меня был включен autoindent . Это только воспроизведение в файлах C с cindent on.

Вы правы, мне тоже удалось воспроизвести это после того, как вы упомянули об этом с помощью vim -U NONE -u NONE -cmd 'set cindent' index.cs

В обычных настройках Vim автоматически устанавливает cindent в C-подобных файлах (отображается в :setl как в C #, так и в JS).
Однако такое же поведение - удаление отступа на <Esc> , повторный отступ на cc - похоже, происходит в файлах, отличных от cindent : проявилось для меня как в CSS, так и в HTML, но в тех случаях это могло быть следствием определенного indentexpr .

@philipmat
@jaredpar

Привет, ребята, я столкнулся с той же проблемой.
Исправлено ли это в последней версии?
Вывод после :set

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

@lookforit на данный момент нет. Такое поведение на самом деле является частью cindent которая в настоящее время не поддерживается VsVim.

Этот простой обходной путь дает мне поведение, которое я ожидаю от vim:

nmap S ddO
nmap cc S

Это все равно было бы неплохо. Я интуитивно чувствую, что «cc» для очистки строки и начала редактирования должна начинаться с того же уровня отступа, что и создание новой строки. Есть ли внутренние аргументы Vim / VS, что этого не должно быть? Я могу взяться за это как на вторжение в работу над проектом.

На первый взгляд решение этой проблемы было не чем иным, как «сделать для cc все, что o уже делал» (поэтому обходной путь

VsVim уже делал правильные вещи для так называемого «vim indent», типа отступа, который VsVim использует, когда нет доступной языковой службы. Чтобы добавить тесты для этой проблемы, мне пришлось добавить в тесты инфраструктуру для имитации языковой службы. Таким образом, несоответствие заключалось в том, что все существующие тесты используют «vim indent», но 99% пользователей используют «host indent», то есть редактируют файлы, в которых Visual Studio предоставляет сервис отступов.

Чтобы еще больше усложнить проблему, была ошибка, о которой никто никогда не сообщал с «vim indent», когда она не работала правильно, когда вкладки не раскрывались (см. Проблему № 2302). Опять же, с практической точки зрения никто не использует «vim indent», так что если подумать, это не так уж и удивительно.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

ogirginc picture ogirginc  ·  6Комментарии

jaredpar picture jaredpar  ·  5Комментарии

drhoda picture drhoda  ·  7Комментарии

kalebpederson picture kalebpederson  ·  6Комментарии

LariscusObscurus picture LariscusObscurus  ·  4Комментарии