Unix как IDE: Работа с текстом

http://blog.sanctum.geek.nz/unix-as-ide-editing/
  • Перевод
Текстовый редактор — это основной инструмент для любого программиста, вот почему вопрос его выбора становится причиной яростных дебатов. Unix традиционно тесно связан с двумя своими многолетними фаворитами, Emacs и Vi, и их современными версиями GNU Emacs и Vim. Эти редакторы имеют очень разный подход к редактированию текста, но при этом сравнимы по мощи.

Поскольку я отношусь к секте Vim, далее мы обсудим неисчерпаемые возможности этого редактора, а также инструменты командной строки, вызываемые прямо из Vim для расширения встроенной функциональности. Некоторые из обсуждаемых дальше принципов могут быть применимы и для Emacs, но не для простых редакторов, вроде Nano.

Это будет очень поверхностный обзор, поскольку возможности Vim в деле программирования поистине неисчислимы, и при этом все равно он получится довольно длинным. Команда Vim :help известна среди новичков как качественный и полезный источник информации, поэтому не пренебрегайте ей.

Определение типа файла



Vim имеет множество настроек, влияющих на его поведение. Например, легко настроить подсветку кода в зависимости от типа загружаемого файла. Таким образом, в частности, можно установить стиль отступов, соответствующий нормам используемого языка программирования. Эту настройку лучше поместить одной из первых в вашем .vimrc файле.

if has("autocmd")
    filetype on
    filetype indent on
    filetype plugin on
endif


Подсветка синтаксиса



Даже если вы работаете с 16-цветным терминалом, смело включайте подсветку в вашем .vimrc файле:

syntax on


Цветовые схемы стандартного 16-цветного терминала внешне не слишком хороши, но решают поставленные перед ними задачи, если подцепить правильные синтаксические файлы. Есть огромное множество цветовых схем, поэтому не составит труда настроить их под себя, а 256-цветный терминал или gVim дадут еще более широкие возможности. Хорошие синтаксические файлы подсветят ошибки ярким красным цветом фона.

Нумерация строк



Если вы привыкли к нумерации строк в традиционных IDE, то включить ее можно, набрав:

set number


Можно попробовать такой трюк, если у вас Vim не старее 7.3, и вы хотите нумеровать строки не абсолютно, а по отношению к текущей:

set relativenumber


Тег-файлы



Vim очень хорошо работает с данными, генерируемыми утилитой ctags. Это позволяет быстро найти все вхождения нужного идентификатора в пределах проекта, или перейти прямо к объявлению переменной с места ее использования в коде, даже если она находится в другом файле. Для больших проектов на C, содержащих множество файлов, можно сэкономить огромное количество впустую потраченного времени, и это, возможно, теснее всего сближает Vim с мейнстримными IDE.

Вы можете запустить :!ctags -R в корневой директории проекта на одном их поддерживаемых языков, и в результате получите тег-файл с определениями и ссылками на расположение идентификаторов в вашем проекте. По готовности тег-файла искать использование тега в проекте можно так:

:tag someClass


Команды :tn и :tp позволяют перемещаться между вхождениями тега по всему проекту. Встроенный механизм тегов покрывает большую часть наиболее используемых возможностей, но если хочется более навороченных фишек, вроде окна со списком тегов, можно установить очень популярный плагин Taglist. Плагин Unimpaired за авторством Tim Pope тоже содержит несколько важных командных переназначений.

Вызов внешних программ



Есть 2 основных метода вызова внешних команд из сессии Vim:
  • :!<command>! — используется в случаях, когда нужно сохранить вывод программы в буфер
  • :shell — Запустить shell как дочерний процесс Vim. Подходит для интерактивного выполнения команд.


Третий способ, здесь подробно не обсуждаемый, подразумевает использование плагинов вроде Conque для эмуляции shell прямо в буфере Vim. Сам я пробовал его в действии, но плагин показался мне непригодным к использованию. Возможно, дело просто в неверном авторском замысле (см. :help design-not).

Vim — это не консоль и не операционная система. У вас вряд ли получится запустить консоль внутри Vim или использовать его для управления отладчиком. У него другая модель использования: применяйте его в качестве компонента командной строки или как составную часть IDE.

Lint-подобные программы и проверка синтаксиса



Проверка синтаксиса или компиляция через вызов внешней программы (например, perl -c, gcc) может быть запущена из редактора при помощи !: commands. Если редактируется файл Perl, то можно выполнить следую команду:

:!perl -c %

/home/tom/project/test.pl syntax OK
Press Enter or type command to continue


Символ "%" — это знак подстановки файла, загруженного в текущий буфер. Результатом является текстовый вывод команды, если таковой имеется, под введенной командной строкой. Если нужно вызывать внешнюю программу постоянно, то лучше замапить ее как команду, или даже как комбинацию клавиш в файле .vimrc. Ниже мы определим команду :PerlLint, вызываемую из нормального режима при помощи \l:

command PerlLint !perl -c %
nnoremap <leader>l :PerlLint<CR>


Для многих языков есть еще один способ сделать то же самое, прибегнув к помощи встроенного в Vim окна quicklist. Установить настройку makeprg для типа файла, включив туда вызов модуля, формирующего читабельный для Vim вывод:

:set makeprg=perl\ -c\ -MVi::QuickFix\ %
:set errorformat+=%m\ at\ %f\ line\ %l\.
:set errorformat+=%m\ at\ %f\ line\ %l


Предварительно нужно установить нужный модуль через CPAN. По завершении можно вводить команду :make и проверять синтаксис файла. Если найдены ошибки, можно открыть окно quicklist (:copen), проверять их описание и перемещаться между ними при помощи :cn и :cp.


Подобные трюки аналогично работают с выводом gcc, да и вообще с любой программой проверки синтаксиса, которая оперирует в результатах своей работы именами файлов, номерами строк и сообщениями об ошибках. Точно так же можно работать и с веб-ориентироваными языками вроде PHP, и с JSLint для Javascript. Существует также отличный плагин Syntastic, предназначенный для так же целей.

Чтение вывода других команд


Чтобы вызвать команду и направить ее вывод прямо в текущий буфер, используется :r!. Для примера, чтобы получить быстрый список содержимого директории, можно напечатать:

:r!ls


Командами, конечно, дело не ограничивается; при помощи :r можно считывать считывать любые файлы, например, открытые ключи или шаблонные тексты:

:r ~/.ssh/id_rsa.pub
:r ~/dev/perl/boilerplate/copyright.pl


Фильтрация вывода через другие команды



Если смотреть на заговолок шире, то речь пойдет вообще о фильтрации текста в буфере через внешние команды. Поскольку визуальный режим Vim отлично подходит для работы с данными, разбитыми на столбцы, нередко имеет смысл применить команды column, cut, sort или awk.

Для примера можно отсортировать весь файл по второму столбцу следующей командой:

:%!sort -k2 -r


Можно выводить только третью колонку выбранного текста, где строка совпадает с шаблоном "/vim/":

:'<,'>!awk '/vim/ {print $3}'


Можно расположить ключевые слова в строках с 1 по 10 по колонкам:

:1,10!column -t


Любой текстовый фильтр или команда могут быть применены таким образом в Vim, и это на порядок увеличивает размах возможностей текстового редактора. При этом буфер Vim рассматривается как текстовый поток, а уж на этом языке легко общаются все классические утилиты.

Встроенные альтернативы



Стоит отметить, что для самых распространенных операций, таких как сортировка и поиск, Vim имеет встроенные методы :sort и :grep. Они полезны, если Vim используется под Windows, однако даже близко не сравнимы с адаптивностью консольных вызовов.

Сравнение файлов



Vim имеет инструмент сравнения vimdiff, позволяющий не только смотреть различия в разных версиях файла, но и разрешать конфликты через трехстороннее слияние, заменять разницу между кусками текста командами :diffput и :diffget. Vimdiff вызывается из командной строки для по крайней мере двух файлов вот так:

$ vimdiff file-v1.c file-v2.c




Контроль версий



Запускать методы контроля версий можно прямо из Vim, и этого чаще всего достаточно. При этом нужно помнить, что "%" — всегда место подстановки файла из текущего буфера:

:!svn status
:!svn add %
:!git commit -a


Действующий чемпион по Git-функциональности — это плагин Fugitive за авторством Tim Pope, который я настоятельно рекомендую всем, кто использует Git совместно с Vim. Более подробное освещение истории и основ систем контроля версий в Unix ищите в 7 части данной серии статей.

Большая разница



Программисты, привыкшие к графическим IDE, нередко считают Vim игрушкой или пережитком. Отчасти причиной служит тот факт, что Vim привыкли видеть в качестве средства редактирования конфигурационных файлов на сервере, а вовсе не как удобный текстовый редактор командной строки. Его встроенные инструменты так хорошо совмещаются с внешними Unix-командами, что нередко способны удивить даже опытных пользователей.

Продолжение следует...

Unix как IDE: Введение
Unix как IDE: Файлы
Unix как IDE: Работа с текстом
Unix как IDE: Компиляция
Поделиться публикацией

Похожие публикации

Комментарии 34

    –18
    Озадачен. Тогда и Виндоус — IDE. Просто там для редактирования текста другие редакторы используются.
    +3
    Возможно кому-то пригодится github.com/amix/vimrc
      +3
      Частенько представлял себя в фантазиях эдаким брутальными девелопером, который хардкорит на стареньком ноуте в чем-то вимоподобном. А потом просыпаюсь и занимаюсь скучной работой в IDE, где меня возможности нумерации строк, подсветки и почти все из данной статьи интересует меньше всего. Все-таки в акрониме Integrated Development Environment гораздо больше смысла и я снова увидел все то же самое, что в туторах вроде vim.wikia.com/wiki/Use_Vim_like_an_IDE, которые делают из vim'а продвинутый редактор, но не IDE.
        +1
        Давно переехал на емакс, но всё ещё использую vimdiff для сравнения файлов. Очень уж он хорош.
          0
          По какой причине переехали?
            0
            Толчком был org-mode, а дальше одно-другое и как-то засосало :)
          +1
          Где структуры классов? Где code complete? Где отладка? Где рефакторинг? Где многое другое необходимое для современной IDE?
          Я считаю что хоть как настраивай vim — IDE из него не получить, и прежде всего потому что это — редактор (пусть и с подсветкой и прочим), а не интегрированная среда разработки, мне кажется у статьи просто неверный заголовок.
          А по содержанию 'Консоль *nix как средство разработки' — очень даже хорошо и интересно.
            +1
            Если же читать первый пост и представить что vim-редактор, а добавление остальных программ превращает все это в IDE, то тоже не получается. IDE — _интегрированная_ среда разработки, а в представленном виде это набор несвязанных инструментов.
              +1
              Это зависит от языка программирования, для Ruby например автодополнение довольно бессмысленно. Отладка есть, рефакторинг — а под этим каждый что-то свое понимает? Все что нужно, можно прикрутить.
                +1
                Почему это бессмысленно? В RubyMine постоянно пользуюсь автодополнением, можно посмотреть подходящие методы и документацию к ним прямо из окошка дополнения, впоследствии, если есть сомнения, как он работает, можно и к исходнику перейти по Ctrl-click, не только своему, но в использованном gem'e.
                Также можно быстро перейти к перекрытому методу в суперклассе, быстро перемещаться между соответствующими контроллером, тестами, моделью и вьюхами, запустить только тот тест, в котором находится курсор, по щелчку мыши в логе теста или сервера сразу перейти к нужному месту в коде, да много чего… Слабо представляю, как это всё можно сделать в виме, да ещё чтобы было удобно пользоваться. Жаль только vim плагин глючный.
                  0
                  RubyMine отличная IDE, но у нее есть и свои проблемы. Запускается более «неспешно», идеальное автодополнение имхо просто невозможно с метапрограммированием, динамическими методами, манки патчингом… Не работает без иксов (это я не к тому, что на продакшене код в живую нужно править, но через ssh хочется подключаться к вагрант виртуалке). Быстро перемещаться по проекту между экшенами-моделями-вьюхами и в виме можно, был какой-то плагин (вроде в сборке от Akita). То есть, вим не IDE, но в большинстве случаев это и не требуется, и огромный плюс — быстрый набор текста, большая скорость работы, работает и стоит везде на *nix'ах. Имхо, конечно. Кстати, а зачем запускать «только тот тест, что нужно»? У меня висит запущенный Guard в консоли постоянно, тест исправил — он его сразу прогнал.
                    +1
                    >Запускается более «неспешно»

                    извините, к IDE такие требования слышать смешно ) Да и зачем закрывать? Нет, если писать на Ruby время от времени, то IDE просто не нужна и дальше спорить не о чем.

                    >идеальное автодополнение имхо просто невозможно с метапрограммированием, динамическими методами, манки патчингом…

                    Идеального не будет, да, в мире вообще мало идеальных вещей, но то что есть, работает гораздо лучше, чем ничего. То, что вы перечислили, — это весьма мощные средства, у вас что, большая часть кода таким образом написана?

                    >Не работает без иксов (это я не к тому, что на продакшене код в живую нужно править, но через ssh хочется подключаться к вагрант виртуалке)

                    можно добавить сервер в deployment и включить ему автоаплоад. Заодно получите локальную историю правок и отсутствие тормозов, если связь плохая. Кстати, удалённый дебаг тоже есть, для любителей )
                    А вообще я как-то отвык в обход vcs работать.

                    >Кстати, а зачем запускать «только тот тест, что нужно»? У меня висит запущенный Guard в консоли постоянно, тест исправил — он его сразу прогнал.

                    тесты я запускаю в RubyMine, потому что там удобно прямо из консоли в исходник переходить на нужную строку. Там есть аналог guard, но поскольку RM сохраняет файл постоянно, я его отключил. В общем, можете не учитывать как плюс.

                    Вообще, у меня сложилось впечатление, что вы больше говорите о работе с большим количеством мелких проектов или скриптов, чем с небольших количеством больших. Тут да, командной строки и вима с небольшим количеством плагинов будет достаточно. Но навешивать на последний кучу плагинов (им же ещё хоткеи придумывать, да и текстовый режим не резиновый), пытаясь сделать ультра-IDE имхо не стоит того.
                      0
                      извините, к IDE такие требования слышать смешно ) Да и зачем закрывать? Нет, если писать на Ruby время от времени, то IDE просто не нужна и дальше спорить не о чем.

                      Скорее я неправильно выразился. Не только медленней запускается, но и работает также более медленно, часто что-то обновляет, индексирует. Это немного раздражает.
                      То, что вы перечислили, — это весьма мощные средства, у вас что, большая часть кода таким образом написана?

                      Рельсы именно так и написаны, а я работаю с ними. Да и вообще, руби и метапрограммирование — это как одно целое.
                      можно добавить сервер в deployment и включить ему автоаплоад. Заодно получите локальную историю правок и отсутствие тормозов, если связь плохая. Кстати, удалённый дебаг тоже есть, для любителей )
                      А вообще я как-то отвык в обход vcs работать.

                      Я немного не о том говорил, работали с вагрантом? Рубимайн не дружит с ним (пока, обещали добавить). vcs при этом никуда не девается.
                      ообще, у меня сложилось впечатление, что вы больше говорите о работе с большим количеством мелких проектов или скриптов, чем с небольших количеством больших. Тут да, командной строки и вима с небольшим количеством плагинов будет достаточно.

                      Почему же в сообществе снискали такую популярность саблайм, вим, тексмейт? Райан Бейтс тоже над мелкими скриптами работает?)) Ничего не имею против RubyMine, вещь просто потрясающая. Просто хотел обратить внимание на то, что у вима есть свои неоспоримые достоинства.
                        +1
                        >Скорее я неправильно выразился. Не только медленней запускается, но и работает также более медленно, часто что-то обновляет, индексирует. Это немного раздражает.

                        Меня как-то не раздражает, может потому что оперативки 3 гига выделил, или проекты меньше… Зато поиск работает очень быстро, как и навигация по кодовой базе.

                        >Рельсы именно так и написаны, а я работаю с ними. Да и вообще, руби и метапрограммирование — это как одно целое.

                        Я тоже работаю с рельсами, и автодополнение там замечательно работает )

                        >Я немного не о том говорил, работали с вагрантом? Рубимайн не дружит с ним (пока, обещали добавить). vcs при этом никуда не девается.

                        Не работал. То есть у вас код прямо на виртуалке и хранится? Или я что-то не понимаю? В принципе можно замапить в папке через SSH и работать как с локальным проектом, я думаю.

                        >Почему же в сообществе снискали такую популярность саблайм, вим, тексмейт? Райан Бейтс тоже над мелкими скриптами работает?))

                        Я и не говорил, что в вим и других редакторах нельзя писать сложные программы. Я лишь говорю, что у IDE есть преимущества, которых нет у простых редакторов, если их постоянно использовать, обратно вернуться будет крайне сложно, я, например, не представляю как вернуться опять на вим. Евангелистом RubyMine я не являюсь, просто высказал своё мнение, буду совсем не против, если вы останетесь при своём )
                          0
                          >Я немного не о том говорил, работали с вагрантом? Рубимайн не дружит с ним (пока, обещали добавить). vcs при этом никуда не девается.

                          Не работал. То есть у вас код прямо на виртуалке и хранится? Или я что-то не понимаю? В принципе можно замапить в папке через SSH и работать как с локальным проектом, я думаю.

                          Да, прямо на виртуалке. Мапить нет нужды, это происходит автоматом… Но команды-то все рубимайн должен исполнять на виртуалке (запуск рейк тасков, установка гемов, все остальное). А он пытается это делать на хост машине. Посмотрите скринкаст, офигительно удобная штука: railscasts.com/episodes/292-virtual-machines-with-vagrant
                          Евангелистом RubyMine я не являюсь, просто высказал своё мнение, буду совсем не против, если вы останетесь при своём )

                          Само собой, сколько людей — столько мнений :)
                  0
                  Самая банальная возможность рефакторинга — изменить название переменной/метода. Это не то же, что и ручное Find/Replace, поскольку стандартные средства той же VS не переименовывают такие же переменные из других методов (т.е. в одном методе Method1 есть переменная var1 и в методе Method2 есть переменная var1. После рефакторинга имени var1 на var2 в методе Method1 есть переменная var2, а в Method2 — var1). Преимущества рефакторинга — тратится меньше времени, нет ошибок связанных с переименованием не той переменной и т.д.

                  Т.е. работа введется на уровне кода, а не текста.
                  0
                  Да, вы правы, очень многое зависит именно от языка. Я нашел любопытную статью, в которой автор сравнивает необходимость использования IDE в Java и Scala.
                  linexp.ru/forum/ide-ne-nuzhna
                  По большей части он прав, и IDE часто лишь обертка для не слишком удачного языка.
                +2
                Кстати, а как сейчас ctags умеет распознать шаблонные конструкции? Т.е. например я напишу что-то вроде:
                typedef boost::ptr_vector<foo> FooVector;
                FooVector::iterator it; 
                it->?
                
                ctags поможет виму подсказать, что здесь должны методы и переменные класса foo? Ну или более простой пример с смарт поинтером:
                typedef std::shared_ptr<foo> fooPtr; 
                fooPtr f; 
                f->?
                

                Как дела с поддержкой С++11? Наиболее важное конечно с точки зрения редактора новое ключевое слово auto вместо явного определения типов.

                Как насчет семантической подсветки кода — поля класса, локальные, глобальные, статические переменные, параметры функции можно ли отдельным цветом раскрасить? А неактивные участки кода закрасить (#if 0, #ifndef SOME_DEFINE, etc), в зависимости от установленных значений макросов где-нибудь в конфигурации?

                Еще вот сейчас очень модно стало использовать статические аналазиторы, что насчет их интеграции?
                  +3
                  ctags поможет виму подсказать, что здесь должны методы и переменные класса foo?

                  Вроде нет и наврятли когда-то сможет. Но не всё так плохо и ctags всё ещё удобно использовать для навигации, а для автодополнения есть плагины использующие clang/libclang, ещё был где-то плагин использующий gcc sence. Аналогичный ответ насчёт C++11, разве что надо сказать, что ctags не поддерживает C++11 и может не видеть некоторые методы.

                  Как насчет семантической подсветки кода — поля класса, локальные, глобальные, статические переменные, параметры функции можно ли отдельным цветом раскрасить?

                  Можно, используя ctags генерируются синтаксические файлы, которые затем грузятся. Вроде есть несколько таких плагинов (называется TagHighlight или как-то близко к этому).

                  А неактивные участки кода закрасить (#if 0, #ifndef SOME_DEFINE, etc), в зависимости от установленных значений макросов где-нибудь в конфигурации?

                  И для этого есть плагин (ifdef.vim), правда он не поддерживает сложные условия (с логическими операторами).

                  Еще вот сейчас очень модно стало использовать статические аналазиторы, что насчет их интеграции?

                  Об этом же было в тексте статьи, где про проверку синтаксиса. Или имеется в виду анализ сразу всего с просмотром результатов? Если да, то для большинства анализаторов должна быть возможность разгрузить файл с результатами в Vim с помощью ключа -q, если такой возможности нет (формат отчёта не стандартные файл: строка: сообщение), то можно написать конвертер.
                  –1
                  Его встроенные инструменты так хорошо совмещаются с внешними Unix-командами, что нередко способны удивить даже опытных пользователей"

                  Ага, включение подсветки синтаксиса и нумерации строк это прям то, чем сейчас можно удивить. Особенно после статьи с WebStorm 5 и их LiveEdit (не говоря о куче других вещей, которые vim и не снились, просто потому что это редактор, а не IDE).
                    +2
                    я не очень то люблю vim, но просто не пойму о каких вещах вы говорите, какие именно вещей нет в вим. Подозреваю что они там точно есть просто вы о них не знаете. )
                      0
                      Да я не говорю что vim плохой редактор, просто функции IDE и редактора сильно отличаются.
                      Хорошо, для примера, у vim есть контекстный автокомплит показывающий классы/методы/функции не только языка, но и всех подключаемых файлов в проекте?
                        0
                        вот таких например в vim нет и не будет
                          0
                          конечно есть
                            0
                            вы забыли гиперссылку на хотя бы что-нибудь, иллюстрирующее ваш тезис
                            беглый гуглинг нашёл, хм, решение для CoffeeScript (стереть первую строку в блоке и по два пробела в начале каждой оставшейся). как нащот реализации для C/C++/JS/Ruby/Java/etc
                              0
                              вы про это?
                              vim.wikia.com/wiki/Folding
                                0
                                я про сделать из
                                function yarr(){
                                  if (foo('(0)')) { 
                                    bar(); 
                                    baz('}\''); // }_-_{
                                  }
                                }
                                
                                вот это
                                function yarr(){
                                  bar(); 
                                  baz('}\''); // }_-_{
                                }
                                

                                решение должно учитывать все нюансы синтаксиса JS
                        0
                        Vim снилось многое, что не снилось вам.
                          –1
                          Например, что там есть такого действительно полезного, чего нет у других? Я к примеру обычно имею дело с большими SQL-файлами, поэтому у меня тест редактора (не IDE) весьма простой, открываю файлик гигов на 6-8. Vim на нем загнулся. долго тупил, пока не вылетел. Тот же файл EmEditor (который я использую как быстрый всеядный редактор) открывает не поперхнувшись за секунды, с подсветкой, и не пытаясь его весь в память загрузить.
                            +3
                            Я даже выйду из режима read-only, только лишь чтобы спросить: помилуйте, зачем вам открывать в редакторе SQL-файл на 8 гигов?! Это штатный режим работы?
                              0
                              Нет, но это показатель того, насколько хорошо устроен редактор. У Vim отличный UI и множество дополнений, из‐за чего (особенно первого) я его и использую, но VimL и архитектура очень далеки от идеальных. Про VimL вы можете почитать мою статью, а архитектура — это общее впечатление от того, что вы
                              • не видите C API, для улучшения интерфейсов с другими языками зачастую приходится экспортировать существующую static функцию или выделять существующий код в отдельную функцию. Единственная документация — комментарии и их далеко не всегда достаточно;
                              • видите отсутствие нормального поддержки клавиатурных сочетаний. Обсуждениям на эту тему уже невесть сколько лет, но у Брама нет времени, а у остальных, видимо, пороха на такую задачу;
                              • видите множество запросов вида «а как сделать подсветку строки там где нет символов/подсветить N’ю колонку» Второе уже решено, но если бы вместо :syn было внятное C API, используемое первой, и соответствующие функции на Python/…, то вопрос бы не требовал создания целой новой настройки;
                              • видите до сих пор не исправленные неровности в скрытии символов вроде некрасивой табуляции, невозможности получить видимую позицию курсора, необходимости нажимать l/h столько раз, сколько символов сокрыто, …;
                              • видите вопросы «а почему я не могу сделать nnoremap d smth, не получая задержку при вводе d»
                              , то у вас остаётся впечатление, что с архитектурой что‐то не то.

                              Собственно, VimL, система подсветки и система ввода — то, что нуждается в улучшениях, причём второе можно сделать без нарушения обратной совместимости, третье тоже (хотя если вы попросите меня это сделать или дождётесь пока сам созрею, то часть обратной совместимости будет намеренно нарушена, могу объяснить какая и почему). Вместо первого лучше иметь C API с доступом ко всем возможностям редактора и соответствующие интерфейсы: для того, чтобы всё использование VimL сводилось к чему‐то вроде
                              nnoremap some-key :<C-u>python module.method()<CR>
                              

                              . Впрочем это не отменит того, что я считаю необходимым сделать VM для VimL, но это имеет мало смысла без потери малой части обратной совместимости: скажите, как Vim может воспринять вторую строку в следующем коде:
                              execute variable
                              nnoremap a b
                              

                              ? Я знаю как минимум три варианта. Если запретить незавершённые блоки :if/:for/:try/:while/:function и принудительно завершать :append/:insert по окончании :execute то всё сведётся к двум вариантам (никак и как создание привязки) и при том возможно будет построить синтаксическое дерево.
                                0
                                Бывают косяки в подобных файлах, которые вполне обнаруживаются при беглом просмотре (нужно потыкать в несколько мест этого самого файла). Но для этого редактор должен нормально скроллить файл, а не тупить по 10 минут при открытии, а потом вываливаться, или на каждую попытку прокрутить хоть чуть файл подвисать на пару минут.
                                В общем с EmEditor'ом я уже много раз удостоверился, что он откроет абсолютно любой файл, причем очень быстро, потому он у меня уже много лет вместо выпиленного блокнота.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое