curl -D/dev/stdout -L --insecure вполне заменяет браузер, всё равно там plaintext:
HTTP/1.1 200 OK
Date: Sun, 29 Oct 2017 10:56:38 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, must-revalidate
Content-Type: text/plain; charset=UTF-8
Server: ClientMapServer
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alt-Svc: quic=":443"; ma=2592000; v="41,39,38,37,35"
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked
77.37.230.77 => rostelecom-bka3 (77.37.128.0/17)
Debug Info:
o-AAAuOQuco4GD4LDIN5IyPVuYRKGalWlWOBkkkR8_UfOhJj81eTi0Ji4QtHWJZ1romLjxg4Nvm49NGB
IKufnfqu7Cl1fFKtAKHIn5U-RdRFQUwn7Mn7Te3Wo5KIDYx983C5j4K4KKQi4Lu21IKndP7qYNoG8PnP
(и ещё практически три тысячи таких же непонятных строк, которые не base64,
потому что имеют в своём составе подчёркивания и дефисоминусы и не ascii85,
потому что есть только буквы, цифры, подчёркивания и дефисоминусы)
Где я или кто‐то ещё говорил про «одну точку входа»? Она там не одна, режим там один на много разных вещей. С необходимостью или наличием модальности я не спорил, я спорил только с определением количества режимов.
(А spotlite-like окошки — это хорошо, но это не вопрос «CLI vs GUI», на ncurses для своей программы при желании можно и такое написать, просто пока никто одновременно хочет и способен это сделать, да и приложений, где такое было бы оправданно, для терминала не слишком много. Да и не то что ncurses, специально для Vim можно подпилить какое‐нибудь дополнение вроде ctrlp.)
Режим ввода команд начинается в том числе с /, но вопрос не в этом: в sublime есть именно режим поиска, который не основной, и который сделан с одной узкой целью со своим узкоспециализированным элементом интерфейса. Сохранение тоже позволяет только сохранять, и тоже имеет отдельный интерфейс. В Vim есть режим для ввода команд редактору, но он не настолько узко специализирован и интерфейс для ввода поисковой строки практически не отличается от интерфейса для ввода команды сохранения. Кроме того, командный режим официально признаётся режимом, и при том одним из основных.
И ещё, нет такой вещи, как «поле ввода имени файла», оно часть команды. Внимание смещается просто в командную строку.
У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд. С сохранением то же самое. «Тем более» в начале я сказал, потому что именно у поиска есть несколько отличий, в т.ч. несколько дополнительных клавиатурных сочетаний, тогда как сохранение делается только командой без каких‐либо особенностей. И «команда» здесь в смысле «выражение на языке программирования, выполняемое ради побочных эффектов (т.е. без возвращаемого значения)», какое выражение прекрасно сочетается с другими командами, если нужно, а не что‐то, позволяющее только написать имя файла и больше ничего.
PS: «плагинчики для гиков» почему‐то есть в стандартной поставке: то же https://github.com/JetBrains/ideavim откуда‐то имеет бейджик «JB official» (хотя и требует отдельной установки) и упомянуто в официальной документации, а не в редакторах, но интерактивных оболочках вроде bash, zsh и fish (последнее ещё и называет себя «friendly interactive shell») аналог есть без установки каких‐либо дополнений. Зачем JetBrains внезапно официально поддерживает «плагинчик для гиков», вам не кажется это странным?
GPL позволяет скрывать весь свой код — пока вы не начали распространять программу, скрывайте сколько хотите. Можете сделать свой закрытый форк чего угодно с лицензией GPL, главное — не предоставляйте его клиентам, они могут потребовать от вас код, а вы не можете в ответ потребовать NDA: https://gcc.gnu.org/ml/gcc/2001-07/msg01342.html.
Если шифровать построчно, то вам понадобится сравнительно сложный скрипт построчного (де)шифрование и понимание криптографии на достаточно высоком уровне, чтобы скрипт не сделал шифрование хуже, чем бесполезным: напоминаю, что если шифровать именно код, то там будет очень много весьма предсказуемых строк вроде «пустая строка», «строка с пробелами и закрывающей фигурной скобкой» и какие‐нибудь #!/usr/bin/env bash. Одна ошибка в скрипте и эти строки выдают злоумышленнику пароль, всего лишь за возможное уменьшение размера репозитория.
А вы не политиком? Я вот не вижу, чтобы автор писал про публичный репозиторий, не покажете? Может ещё скажете, что там же упомянутый GoogleDrive стал внезапно публиковать файлы по‐умолчанию? А в начале комментария про пароли я вообще написал «Автор почему‐то привёл в пример именно шифрование кодовой базы» а не «Автор на самом деле имел ввиду шифрование паролей».
Кроме того, где ваши предложения про «другие места»? Почему вам не нравится шифрование приватных репозиториев? В отличие от вас, я написал, какая может быть мотивация за этим действием.
В общем ваш комментарий практически не содержит смысла, но зато содержит пачку ораторских приёмов. Политику бы определённо подошёл.
Ага, гибкий. Но даже аналога фаз из mercurial почему‐то нет, не говоря уже о чём‐то более фундаментальном вроде changeset evolution. Для чего‐то простого можно обвешаться атрибутами и хуками, и это гораздо проще, чем написать дополнение для mercurial или даже делать шифрование на «фильтрах» (аналогично атрибутам, вот только настройких не хранятся в репозитории), но если вам, к примеру, захочется иметь возможность объявлять «этот коммит опубликован, его нельзя менять (в т.ч. удаляя из ветки)» и «этот коммит не опубликован, его можно менять», то вам понадобятся, во‐первых, хуки, во‐вторых, отдельный сервер синхронизации фаз: средств добавления метаданных в коммиты нет вообще, тем более средств добавления метаданных, которые не учавствуют в расчёте хэша и могут быть изменены позднее.
Конкретно с фазами проблема частично решается запретом force-push в «публикующих» репозиториях, но это, во‐первых, менее удобно для пользователя, а, во‐вторых, поднятие проблемы, решаемой фазами, не является целью комментария вообще. Приведя данный пример, длительное время существовавший в виде дополнения я просто показываю, что дополнения в mercurial обеспечивают намного бо́льшую гибкость, чем позволяет архитектура git.
По моему мнению создание репозитория на github и хранение на нём шифрованных данных вполне логично:
Автор почему‐то привёл в пример именно шифрование кодовой базы. Но вы можете, к примеру, сделать на этой основе свой парольный менеджер и хранить так пароли, при этом храня и историю их изменения, не опасаясь что‐то случайно удалить.
Ещё так можно публично хранить все.файлы скопом — в том числе .ssh — в зависимости от того, к чему именно вы имеете доступ такое может быть вполне приемлемо.
В моём первом предложении не случайно отсутствует слова «публичный» и «открытый». Шифрование репозитория просто значит «я не доверяю github, но не готов поддерживать свой сервер». Ничто не мешает взять и также зашифровать приватный репозиторий.
Заметьте, автор написал «воспользоваться публичным ресурсом». А не «публичным репозиторием».
Я часто опечатываюсь с десятипальцевым методом, и часто знаю, что я опечатался и чуть реже, как именно я опечатался, даже не смотря на результат. Правда т.к. я на него обычно всё‐таки смотрю, то такая способность относится в первую очередь к паролям.
Такая «кнопка» даже в Vim может быть: к примеру, дополнение pymode предоставляет интерфейс к rope, каковая является библиотекой для рефакторинга Python проектов (правда, в документации я увидел только переименование модуля). Но Python — это язык с динамической типизацией, много вы тут в автоматическом режиме не нарефакторите. Java и C++ — другое дело, тут рефакторинг автоматизировать гораздо легче (если не злоупотреблять макросами в C++).
Правда, во что я не поверю, так это в то, что IDE способны ещё и комментарии отрефакторить. Особенно если это не комментарии‐документация (где могут и часто должны возникать явные и типизированные ссылки на конкретные сущности вроде классов и методов), а просто комментарии к коду.
И ещё я не поверю в то, что есть вменяемый автоматизированный рефакторинг динамически типизированных языков, в т.ч. проектов, где часть кода на C++, а часть на каком‐нибудь luajit с его ffi.
В общем, старый добрый grep (точнее, его альтернативы) мне кажется хоть и менее удобным, но одновременно более надёжным и более универсальным.
Vim-7.0 появился в 2004 (точнее, тогда появился первый commit в mercurial репозитории, а он содержит исходные коды начиная с 7.0, но не более ранние). Первый commit, позволяющий запуск powerline (которому нужен +python) — 7.0.112 — октябрь 2006.
А у Neovim есть API на основе msgpack для взаимодействия с внешними процессами, что позволяет писать на любом языке.
Кстати, самое интересное: в Vim есть подсветка intel hex файлов. А в Atmel и CCS studio (последнее что‐то на основе какой‐то другой IDE, кажется, eclipse) и вроде каких‐то ещё IDE для микроконтроллеров нет.
И :terminal, и асинхронность Брам уже переписал, не очень совместимым образом. IPC API на msgpack или эквивалента как у Neovim нет, и :terminal более нов и менее стабилен, но, тем не менее, асинхронные задачи, таймеры и терминал в Vim сейчас есть.
Neovim пилят не столько из‐за legacy, сколько из‐за Брама и модели разработки вообще: хотя Neovim и нарушает обратную совместимость в некоторых местах, многие его преимущества такого нарушения в принципе не требуют, но через Брама никогда бы не прошли. Теперь ситуация несколько изменилась: Neovim наступает на пятки, поэтому Брам посылает лесом свой же :h design-not, испытывает прилив энтузиазма и создаёт несовместимые альтернативы. Но модель разработки так и не поменял, поэтому всегда можно обнаружить в master сначала изменение «добавлено X» потом «после добавления X нифига не компилируется» (хотя обычно всё же «не компилируется с определённым набором возможностей»), но нельзя обнаружить метку «это стабильный релиз». И никто не делает review (не публично, во всяком случае), не ждёт результата CI перед тем как засунуть что‐то в master и не всегда понятно, что нужно сделать, чтобы ваш вклад оказался в master (и, кстати, автором всех изменений в основном репозитории с т.з. git[hub] всегда выступает Брам, оригинальный автор указывается в комментарии).
Возможность сделать что‐то асинхронно — это пример возможности, изначально появившейся в Neovim, а потом переписанной Брамом для Vim, с несовместимым API, конечно.
Впрочем, это не значит, что legacy код у нас не исправляется. К слову, я один из основных авторов Neovim, хотя и не первый по числу кода. И я как раз сейчас очень медленно переписываю большой кусок legacy под названием «VimL»: в идеале в итоге должны быть полностью изменён «парсер/исполнитель» на реальный парсер и виртуальную машину: сейчас код выполняется по мере разбора, таких вещей как «синтаксическое дерево» и «байт‐код» нет.
Второй пункт означает, что остальные редакторы, что вы нашли, ещё хуже Vim: вообще‐то Vim сразу грузит весь файл в память, даже не используя mmap(). Другое дело, что он на C и там простейшие C’шные строки, собранные в структуры; overhead по памяти есть, но не очень большой и тем менее заметен, чем длиннее строка. «Большие датасеты» такой вариант проглатывает, только если есть достаточно памяти, но если память есть, то скорость работы самого Vim не упадёт (другое дело дополнения, особенно если им зачем‐то нужно проходиться по всему буферу, иногда синтаксические файлы требую странного вроде syn sync fromstart).
А смысл такого опроса и вообще о чём он? Вот я пользуюсь Vim, печатая вслепую, но vimtutor не прошёл, и даже печатать вслепую учился без курсов вроде «соло на клавиатуре» (кстати, как раз пробовал, но не прошёл): просто перешёл на другую раскладку (программистский Дворак), подвесил оную под монитором и начал так печатать (заодно узнал, что в linux’овой консоли (той, что по <C-A-Fn>) оказывается есть таймаут на набор пароля). Но при этом «что такое vimtutor» я примерно знаю. Мне что отвечать?
В Vim этой ереси по‐умолчанию, к счастью, нет. Я люблю вставку открывающей+закрывающей сразу, но у меня это на отдельных сочетаниях клавиш. Плюс дополнение surround.vim, позволяет легко запихивать различные конструкции в скобки/кавычки/… или удалять сразу два парных символа.
Для такого иногда можно посоветовать всё же дополнение: с таким простым автозакрытием скобок возникают проблемы с undo (вставка скобок создаёт новый узел в дереве undo) и точкой. Лично мне первое не мешает, но вот второе сильно раздражает, хотя дополнение я так и не поставил: они имеют свойство ломаться с обновлениями Vim и не уверен, что сейчас вообще есть с работающей точкой (т.к. следил за vim-dev и иногда ловил сообщения «этот трюк сломался», но соответствующие ветки потом не особо читал).
PS: Не нужно говорить про «любое сочетание клавиш» и «в любом режиме»: я знаю очень много контрпримеров, вот два самых простых: на первое достаточно просто <C-S-x>, на второе: вы знаете, что у YouCompleteMe есть «принципиально нерешаемая» проблема с неработающим <C-u>?
curl -D/dev/stdout -L --insecureвполне заменяет браузер, всё равно там plaintext:(Оператор: onlime.)
Где я или кто‐то ещё говорил про «одну точку входа»? Она там не одна, режим там один на много разных вещей. С необходимостью или наличием модальности я не спорил, я спорил только с определением количества режимов.
(А spotlite-like окошки — это хорошо, но это не вопрос «CLI vs GUI», на ncurses для своей программы при желании можно и такое написать, просто пока никто одновременно хочет и способен это сделать, да и приложений, где такое было бы оправданно, для терминала не слишком много. Да и не то что ncurses, специально для Vim можно подпилить какое‐нибудь дополнение вроде ctrlp.)
Режим ввода команд начинается в том числе с
/, но вопрос не в этом: в sublime есть именно режим поиска, который не основной, и который сделан с одной узкой целью со своим узкоспециализированным элементом интерфейса. Сохранение тоже позволяет только сохранять, и тоже имеет отдельный интерфейс. В Vim есть режим для ввода команд редактору, но он не настолько узко специализирован и интерфейс для ввода поисковой строки практически не отличается от интерфейса для ввода команды сохранения. Кроме того, командный режим официально признаётся режимом, и при том одним из основных.И ещё, нет такой вещи, как «поле ввода имени файла», оно часть команды. Внимание смещается просто в командную строку.
У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд. С сохранением то же самое. «Тем более» в начале я сказал, потому что именно у поиска есть несколько отличий, в т.ч. несколько дополнительных клавиатурных сочетаний, тогда как сохранение делается только командой без каких‐либо особенностей. И «команда» здесь в смысле «выражение на языке программирования, выполняемое ради побочных эффектов (т.е. без возвращаемого значения)», какое выражение прекрасно сочетается с другими командами, если нужно, а не что‐то, позволяющее только написать имя файла и больше ничего.
PS: «плагинчики для гиков» почему‐то есть в стандартной поставке: то же https://github.com/JetBrains/ideavim откуда‐то имеет бейджик «JB official» (хотя и требует отдельной установки) и упомянуто в официальной документации, а не в редакторах, но интерактивных оболочках вроде bash, zsh и fish (последнее ещё и называет себя «friendly interactive shell») аналог есть без установки каких‐либо дополнений. Зачем JetBrains внезапно официально поддерживает «плагинчик для гиков», вам не кажется это странным?
GPL позволяет скрывать весь свой код — пока вы не начали распространять программу, скрывайте сколько хотите. Можете сделать свой закрытый форк чего угодно с лицензией GPL, главное — не предоставляйте его клиентам, они могут потребовать от вас код, а вы не можете в ответ потребовать NDA: https://gcc.gnu.org/ml/gcc/2001-07/msg01342.html.
Если шифровать построчно, то вам понадобится сравнительно сложный скрипт построчного (де)шифрование и понимание криптографии на достаточно высоком уровне, чтобы скрипт не сделал шифрование хуже, чем бесполезным: напоминаю, что если шифровать именно код, то там будет очень много весьма предсказуемых строк вроде «пустая строка», «строка с пробелами и закрывающей фигурной скобкой» и какие‐нибудь
#!/usr/bin/env bash. Одна ошибка в скрипте и эти строки выдают злоумышленнику пароль, всего лишь за возможное уменьшение размера репозитория.А вы не политиком? Я вот не вижу, чтобы автор писал про публичный репозиторий, не покажете? Может ещё скажете, что там же упомянутый GoogleDrive стал внезапно публиковать файлы по‐умолчанию? А в начале комментария про пароли я вообще написал «Автор почему‐то привёл в пример именно шифрование кодовой базы» а не «Автор на самом деле имел ввиду шифрование паролей».
Кроме того, где ваши предложения про «другие места»? Почему вам не нравится шифрование приватных репозиториев? В отличие от вас, я написал, какая может быть мотивация за этим действием.
В общем ваш комментарий практически не содержит смысла, но зато содержит пачку ораторских приёмов. Политику бы определённо подошёл.
Ага, гибкий. Но даже аналога фаз из mercurial почему‐то нет, не говоря уже о чём‐то более фундаментальном вроде changeset evolution. Для чего‐то простого можно обвешаться атрибутами и хуками, и это гораздо проще, чем написать дополнение для mercurial или даже делать шифрование на «фильтрах» (аналогично атрибутам, вот только настройких не хранятся в репозитории), но если вам, к примеру, захочется иметь возможность объявлять «этот коммит опубликован, его нельзя менять (в т.ч. удаляя из ветки)» и «этот коммит не опубликован, его можно менять», то вам понадобятся, во‐первых, хуки, во‐вторых, отдельный сервер синхронизации фаз: средств добавления метаданных в коммиты нет вообще, тем более средств добавления метаданных, которые не учавствуют в расчёте хэша и могут быть изменены позднее.
Конкретно с фазами проблема частично решается запретом force-push в «публикующих» репозиториях, но это, во‐первых, менее удобно для пользователя, а, во‐вторых, поднятие проблемы, решаемой фазами, не является целью комментария вообще. Приведя данный пример, длительное время существовавший в виде дополнения я просто показываю, что дополнения в mercurial обеспечивают намного бо́льшую гибкость, чем позволяет архитектура git.
По моему мнению создание репозитория на github и хранение на нём шифрованных данных вполне логично:
Автор почему‐то привёл в пример именно шифрование кодовой базы. Но вы можете, к примеру, сделать на этой основе свой парольный менеджер и хранить так пароли, при этом храня и историю их изменения, не опасаясь что‐то случайно удалить.
Ещё так можно публично хранить все.файлы скопом — в том числе .ssh — в зависимости от того, к чему именно вы имеете доступ такое может быть вполне приемлемо.
В моём первом предложении не случайно отсутствует слова «публичный» и «открытый». Шифрование репозитория просто значит «я не доверяю github, но не готов поддерживать свой сервер». Ничто не мешает взять и также зашифровать приватный репозиторий.
Заметьте, автор написал «воспользоваться публичным ресурсом». А не «публичным репозиторием».
Я часто опечатываюсь с десятипальцевым методом, и часто знаю, что я опечатался и чуть реже, как именно я опечатался, даже не смотря на результат. Правда т.к. я на него обычно всё‐таки смотрю, то такая способность относится в первую очередь к паролям.
Такая «кнопка» даже в Vim может быть: к примеру, дополнение pymode предоставляет интерфейс к rope, каковая является библиотекой для рефакторинга Python проектов (правда, в документации я увидел только переименование модуля). Но Python — это язык с динамической типизацией, много вы тут в автоматическом режиме не нарефакторите. Java и C++ — другое дело, тут рефакторинг автоматизировать гораздо легче (если не злоупотреблять макросами в C++).
Правда, во что я не поверю, так это в то, что IDE способны ещё и комментарии отрефакторить. Особенно если это не комментарии‐документация (где могут и часто должны возникать явные и типизированные ссылки на конкретные сущности вроде классов и методов), а просто комментарии к коду.
И ещё я не поверю в то, что есть вменяемый автоматизированный рефакторинг динамически типизированных языков, в т.ч. проектов, где часть кода на C++, а часть на каком‐нибудь luajit с его ffi.
В общем, старый добрый grep (точнее, его альтернативы) мне кажется хоть и менее удобным, но одновременно более надёжным и более универсальным.
Vim-7.0 появился в 2004 (точнее, тогда появился первый commit в mercurial репозитории, а он содержит исходные коды начиная с 7.0, но не более ранние). Первый commit, позволяющий запуск powerline (которому нужен +python) — 7.0.112 — октябрь 2006.
А у Neovim есть API на основе msgpack для взаимодействия с внешними процессами, что позволяет писать на любом языке.
Кстати, самое интересное: в Vim есть подсветка intel hex файлов. А в Atmel и CCS studio (последнее что‐то на основе какой‐то другой IDE, кажется, eclipse) и вроде каких‐то ещё IDE для микроконтроллеров нет.
И :terminal, и асинхронность Брам уже переписал, не очень совместимым образом. IPC API на msgpack или эквивалента как у Neovim нет, и
:terminalболее нов и менее стабилен, но, тем не менее, асинхронные задачи, таймеры и терминал в Vim сейчас есть.Neovim пилят не столько из‐за legacy, сколько из‐за Брама и модели разработки вообще: хотя Neovim и нарушает обратную совместимость в некоторых местах, многие его преимущества такого нарушения в принципе не требуют, но через Брама никогда бы не прошли. Теперь ситуация несколько изменилась: Neovim наступает на пятки, поэтому Брам посылает лесом свой же
:h design-not, испытывает прилив энтузиазма и создаёт несовместимые альтернативы. Но модель разработки так и не поменял, поэтому всегда можно обнаружить в master сначала изменение «добавлено X» потом «после добавления X нифига не компилируется» (хотя обычно всё же «не компилируется с определённым набором возможностей»), но нельзя обнаружить метку «это стабильный релиз». И никто не делает review (не публично, во всяком случае), не ждёт результата CI перед тем как засунуть что‐то в master и не всегда понятно, что нужно сделать, чтобы ваш вклад оказался в master (и, кстати, автором всех изменений в основном репозитории с т.з. git[hub] всегда выступает Брам, оригинальный автор указывается в комментарии).Возможность сделать что‐то асинхронно — это пример возможности, изначально появившейся в Neovim, а потом переписанной Брамом для Vim, с несовместимым API, конечно.
Впрочем, это не значит, что legacy код у нас не исправляется. К слову, я один из основных авторов Neovim, хотя и не первый по числу кода. И я как раз сейчас очень медленно переписываю большой кусок legacy под названием «VimL»: в идеале в итоге должны быть полностью изменён «парсер/исполнитель» на реальный парсер и виртуальную машину: сейчас код выполняется по мере разбора, таких вещей как «синтаксическое дерево» и «байт‐код» нет.
Второй пункт означает, что остальные редакторы, что вы нашли, ещё хуже Vim: вообще‐то Vim сразу грузит весь файл в память, даже не используя mmap(). Другое дело, что он на C и там простейшие C’шные строки, собранные в структуры; overhead по памяти есть, но не очень большой и тем менее заметен, чем длиннее строка. «Большие датасеты» такой вариант проглатывает, только если есть достаточно памяти, но если память есть, то скорость работы самого Vim не упадёт (другое дело дополнения, особенно если им зачем‐то нужно проходиться по всему буферу, иногда синтаксические файлы требую странного вроде
syn sync fromstart).А смысл такого опроса и вообще о чём он? Вот я пользуюсь Vim, печатая вслепую, но vimtutor не прошёл, и даже печатать вслепую учился без курсов вроде «соло на клавиатуре» (кстати, как раз пробовал, но не прошёл): просто перешёл на другую раскладку (программистский Дворак), подвесил оную под монитором и начал так печатать (заодно узнал, что в linux’овой консоли (той, что по
<C-A-Fn>) оказывается есть таймаут на набор пароля). Но при этом «что такое vimtutor» я примерно знаю. Мне что отвечать?Большие по объёму кода дополнения часто пишут на Python, lua и ruby; в основном первое.
В Vim этой ереси по‐умолчанию, к счастью, нет. Я люблю вставку открывающей+закрывающей сразу, но у меня это на отдельных сочетаниях клавиш. Плюс дополнение surround.vim, позволяет легко запихивать различные конструкции в скобки/кавычки/… или удалять сразу два парных символа.
Для такого иногда можно посоветовать всё же дополнение: с таким простым автозакрытием скобок возникают проблемы с undo (вставка скобок создаёт новый узел в дереве undo) и точкой. Лично мне первое не мешает, но вот второе сильно раздражает, хотя дополнение я так и не поставил: они имеют свойство ломаться с обновлениями Vim и не уверен, что сейчас вообще есть с работающей точкой (т.к. следил за vim-dev и иногда ловил сообщения «этот трюк сломался», но соответствующие ветки потом не особо читал).
Сам использую
,s(круглые скобки) /,h([]) /,f({}) /,u(<>).PS: Не нужно говорить про «любое сочетание клавиш» и «в любом режиме»: я знаю очень много контрпримеров, вот два самых простых: на первое достаточно просто
<C-S-x>, на второе: вы знаете, что у YouCompleteMe есть «принципиально нерешаемая» проблема с неработающим<C-u>?