«Отдалённый» всё же обычно употребляется к обозримым объектам. Здесь объект не обозримый для человека, особенно без переключения контекста. Да и это уже давно устоявшийся термин, причём намного более употребительный (по отношению к своим синонимам), чем он же, но в значении «стёртый». Но вот если бы вместо «удалить удалённый репозиторий» было написано «стереть удалённый репозиторий» понять смысл было бы намного легче, уж к глаголу‐то в этом значении понятных и часто употребляемых синонимов более чем достаточно.
Возможности программы, согласованность интерфейса и разделение ответственности между частями программы — это три разные вещи. Никто здесь не просит убрать функционал git, здесь просят изменить интерфейс. Народ из MS, к слову, не побоялся это сделать.
Конечно, внезапный переход на новую систему — не самая хорошая идея для git. Но взять и допилить тот же libgit2 (или написать что‐то своё, но обязательно с API — его отсутствие — это один из недостатков git), сделать на его основе новый CLI с учётом всех выявленных недостатков и объявить старый вариант deprecated (с поддержкой в течение нескольких лет) они вполне могут. Альтернативу — имея чёткий план по шагам ломать старый — тоже (правда, по‐моему, первый вариант легче пережить).
Если этого не сделать то легко повторить судьбу perl — желаемых изменений накопилось на целый новый язык, но популярность старого perl продолжает падать, а новый всё ещё не готов.
<C-t> в разных раскладках — это собственная возможность X’ов (при условии, что X’ам сообщили о нескольких раскладках; с некоторыми переключалками может не работать).
С такой может быть и так (хотя эту ошибку я видел в списке рассылки, но что на что меняли реально не помню. Точно меняли не латиницу на латиницу). Вторая и третья проблемы от того никуда не делись.
3. Определите привязку, к примеру nnoremap Y :echom "I am HERE"<CR>. И попробуйте её использовать с вашим кодом.
4. Попробуйте ввести с вашим кодом составные команды (вроде gg) или операторы (вроде yy). Поместить все символы после <CR> с или без <silent> является куда как лучшей идеей, чем использовать :normal в функции: эффект от :normal на этих командах слабо отличается от того, из‐за чего вы использовали исключительный случай для :. Разве что убирать <silent> не обязательно. Замечу что исключительный случай для :в функции не выполняет ровным счётом никакой полезной работы.
+ несистемное переключение раскладки и необходимость помнить в каком окне какая раскладка (даже хуже: в каком Vim’е какого эмулятора терминала, у меня обычно первых больше чем последних, но и последних тоже много). Так что расслабьтесь, langmap — это просто ещё одна возможность, которая есть, но которой нет.
<Esc>, кстати, — ещё одна суперфича. Я как‐то недавно ковырял Firefox и удивился, в каком количестве мест Esc не работает:
Он не выведет из поля адреса. Может отменить то, что вы там ввели, вернув изначальный адрес, но не уберёт фокус
Он не выведет из полей ввода типа textarea
Он не отменит поиск по <C-f> или даже / (они вообще отменяются только мышкой, второй ещё по timeout’у).
Он не остановит загрузку страницы.
. И это только то, чем я чаще всего пользуюсь. Причём первыми двумя пунктами страдает ещё и chromium. Возможно, конечно, что всё можно как‐то настроить.
Здесь главный вопрос не скорость. Автосоздание переменных в таком виде зачастую весьма удобно: если проигнорировать импорт, то это одна короткая и понятная строчка (определение tags не считается, так как должно присутствовать в обоих случаях) против либо длинной, либо и вовсе четырёх. Читаемость везде нормальная, но если конструкций с except KeyError: много, то, если скорость позволяет, уж лучше использовать ваш вариант.
Кстати, вспомнил про аналогичный benchmark из этой темы. Если воспользоваться кодом оттуда (но файлом увеличенным в десять раз простым «умножением»), то распределение по скорости выглядит следующим образом (от самого быстрого: 3,3, 3,4, 3,7, 4,1):
d = defaultdict(int)
…
d[x] += 1
try:
d[x] += 1
except KeyError:
d[x] = 1
if x in d:
d[x] += 1
else:
d[x] = 1
d[x] = d[x] + 1 if x in d else 1
Собственно весь код:
import re
n = 5
with open("./pg2600.txt", "r") as f:
s = f.read()
d={}
for x in re.findall(r'\w+',s):
<tested code here>
print repr([k for k,v in d.items() if v == n])
Мой вариант стабильно быстрее except KeyError: (разница мала или очень мала, но он всегда быстрее), последние два могут показывать близкую производительность (но ваш всегда медленнее).
Замечу, что здесь используется int, а не lambda: 0. Разница в скорости, впрочем, не обнаружена.
Но отмечать изменения в произвольно порядке таки можно. Толку — чуть, из‐за остальных проблем я никогда не поверю, что crecord не собирается мне что‐то испортить (слишком много ошибок в UI, чтобы я считал, что авторы могут написать остальные внутренности без ошибок).
Это было очень давно, а я не помню, в чём были проблемы (старое ощущение — «ужас, ужас, ужас» и всё). Сейчас опять запустил, вижу проблему с границами выделений (на русском тексте) и замечательный текст «изменено поло�~A: 5, �~A�~B�~@ок: 165». Если что, это не часть изменений. Также вижу отсутствие возможности изменять текст внутри линии. Вижу замечательное поведение PageUp/PageDown (внутри длинного hunk прокручивает на одну строку). Вижу , двойное нажатие на который не ведёт к возвращению отметки к неотмеченным изменениям добавленного файла, а нажатие на единственный внутренний hunk (но не линию) убирает отметку со всех линий и самого hunk’а, но не с имени файла. При «review and edit» (единственный способ всё‐таки изменить текст внутри линии), а также при обычном commit не виден diff (мне он нужен, чтобы всё‐таки составить сообщение), и нельзя вернуться назад, если при просмотре diff’а обнаружилось что‐то не то. Подозреваю, что посмотреть diff можно, настроив mercurial засовывать его в комментарий (вроде где‐то пробегало что‐то такое, работающее для и «hg commit», и для всего остального).
Я имею ввиду, можно ли сначала посмотреть (и отметить) изменения в одном файле из конца списка, потом в другом из начала, потом отметить полностью какие‐то файлы в середине, затем вернуться к первому, и, возможно, переотметить.
Последний (и единственный) раз, когда я его смотрел, у него были проблемы с русским языком в файлах. Русский у меня сейчас только на моих старых проектах, но и на новых часто встречаются юникодные символы (в основном апострофы, кавычки (а не ASCII‐убожество), маркеры для складок (использую «▶,▲» вместо «{{{,}}}»)). И ещё мне чего‐то не понравилось в интерфейсе (не помню, что именно). Напомните, в Crecord можно работать с изменениями в произвольном порядке?
Первое прекрасно служит в качестве второго. Замечу, что нужная мне часть почти не менялась с mercurial-1.3. Предположительно и с mercurial-1.2, но в Vim нет sys.stdout.closed, поэтому я всегда получаю AttributeError, когда пытаюсь использовать последний.
Никто не занимается сломом API «из любви к исскусству», поэтому просто не лезьте в дебри, следите за изменениями и получите нормальную поддержку всех версий, в том числе тех, когда Command Server не существовал. С бонусом в виде отсутствия затрат на IPC или даже жутких затрат на fork/exec.
На самом деле, расширения ломаются даже чаще — им нужны бо́льшие дебри.
Конечно, внезапный переход на новую систему — не самая хорошая идея для git. Но взять и допилить тот же libgit2 (или написать что‐то своё, но обязательно с API — его отсутствие — это один из недостатков git), сделать на его основе новый CLI с учётом всех выявленных недостатков и объявить старый вариант deprecated (с поддержкой в течение нескольких лет) они вполне могут. Альтернативу — имея чёткий план по шагам ломать старый — тоже (правда, по‐моему, первый вариант легче пережить).
Если этого не сделать то легко повторить судьбу perl — желаемых изменений накопилось на целый новый язык, но популярность старого perl продолжает падать, а новый всё ещё не готов.
nnoremap Y :echom "I am HERE"<CR>
. И попробуйте её использовать с вашим кодом.4. Попробуйте ввести с вашим кодом составные команды (вроде
gg
) или операторы (вродеyy
). Поместить все символы после<CR>
с или без<silent>
является куда как лучшей идеей, чем использовать:normal
в функции: эффект от:normal
на этих командах слабо отличается от того, из‐за чего вы использовали исключительный случай для:
. Разве что убирать<silent>
не обязательно. Замечу что исключительный случай для:
в функции не выполняет ровным счётом никакой полезной работы.<Plug>ISurround
:nmap
в вашем случае не надо использовать (Learn vimscript the hard way, глава 5: Strict mapping). Для такой задачи вообще‐тоnore
обычно вреден, но в вашем коде безnore
хуже.normal!
(с восклицательным знаком).normal
вообще, хоть с, хоть без восклицательного знака;В вашем коде нужно либо заменить
nmap
наnnoremap
иexecute("normal…")
наcall feedkeys(a:key, "t")
, либо использовать<expr>
:tags
не считается, так как должно присутствовать в обоих случаях) против либо длинной, либо и вовсе четырёх. Читаемость везде нормальная, но если конструкций сexcept KeyError:
много, то, если скорость позволяет, уж лучше использовать ваш вариант.Кстати, вспомнил про аналогичный benchmark из этой темы. Если воспользоваться кодом оттуда (но файлом увеличенным в десять раз простым «умножением»), то распределение по скорости выглядит следующим образом (от самого быстрого: 3,3, 3,4, 3,7, 4,1):
Собственно весь код:
Мой вариант стабильно быстрее
except KeyError:
(разница мала или очень мала, но он всегда быстрее), последние два могут показывать близкую производительность (но ваш всегда медленнее).Замечу, что здесь используется
int
, а неlambda: 0
. Разница в скорости, впрочем, не обнаружена.Всё это не идёт ни в какое сравнение с AuRecord.
Никто не занимается сломом API «из любви к исскусству», поэтому просто не лезьте в дебри, следите за изменениями и получите нормальную поддержку всех версий, в том числе тех, когда Command Server не существовал. С бонусом в виде отсутствия затрат на IPC или даже жутких затрат на fork/exec.
На самом деле, расширения ломаются даже чаще — им нужны бо́льшие дебри.