All streams
Search
Write a publication
Pull to refresh
41
0
Павлов Николай Александрович @ZyXI

Инженер

Send message
«Отдалённый» всё же обычно употребляется к обозримым объектам. Здесь объект не обозримый для человека, особенно без переключения контекста. Да и это уже давно устоявшийся термин, причём намного более употребительный (по отношению к своим синонимам), чем он же, но в значении «стёртый». Но вот если бы вместо «удалить удалённый репозиторий» было написано «стереть удалённый репозиторий» понять смысл было бы намного легче, уж к глаголу‐то в этом значении понятных и часто употребляемых синонимов более чем достаточно.
Возможности программы, согласованность интерфейса и разделение ответственности между частями программы — это три разные вещи. Никто здесь не просит убрать функционал git, здесь просят изменить интерфейс. Народ из MS, к слову, не побоялся это сделать.

Конечно, внезапный переход на новую систему — не самая хорошая идея для git. Но взять и допилить тот же libgit2 (или написать что‐то своё, но обязательно с API — его отсутствие — это один из недостатков git), сделать на его основе новый CLI с учётом всех выявленных недостатков и объявить старый вариант deprecated (с поддержкой в течение нескольких лет) они вполне могут. Альтернативу — имея чёткий план по шагам ломать старый — тоже (правда, по‐моему, первый вариант легче пережить).

Если этого не сделать то легко повторить судьбу perl — желаемых изменений накопилось на целый новый язык, но популярность старого perl продолжает падать, а новый всё ещё не готов.
<C-t> в разных раскладках — это собственная возможность X’ов (при условии, что X’ам сообщили о нескольких раскладках; с некоторыми переключалками может не работать).
С такой может быть и так (хотя эту ошибку я видел в списке рассылки, но что на что меняли реально не помню. Точно меняли не латиницу на латиницу). Вторая и третья проблемы от того никуда не делись.
Там наверху у меня ссылка на учебник. Основная страница: learnvimscriptthehardway.stevelosh.com/. Ещё можно посмотреть на мою статью с описанием некоторых особенностей vimL. Правда по последней давно (со дня написания, но тогда, разумеется, мне казалось иначе) плачет refactoring.
3. Определите привязку, к примеру nnoremap Y :echom "I am HERE"<CR>. И попробуйте её использовать с вашим кодом.
4. Попробуйте ввести с вашим кодом составные команды (вроде gg) или операторы (вроде yy). Поместить все символы после <CR> с или без <silent> является куда как лучшей идеей, чем использовать :normal в функции: эффект от :normal на этих командах слабо отличается от того, из‐за чего вы использовали исключительный случай для :. Разве что убирать <silent> не обязательно. Замечу что исключительный случай для : в функции не выполняет ровным счётом никакой полезной работы.
+ несистемное переключение раскладки и необходимость помнить в каком окне какая раскладка (даже хуже: в каком Vim’е какого эмулятора терминала, у меня обычно первых больше чем последних, но и последних тоже много). Так что расслабьтесь, langmap — это просто ещё одна возможность, которая есть, но которой нет.
Langmap == проблемы с привязками с левой частью вида <Plug>ISurround:
:inoremap <Plug>Isurround <Nop>
:imap <C-g>S <Plug>Isurround
:set langmap=YI,IY
:execute "normal i\<C-g>S"
:1print
<Plug>ISurround
Идея интересная, но
  1. Тем, что если nmap'ить все символы, то при попытке сделать Жцй(:wq) вы получите кукиш.
    решается таким же набором привязок для командного режима, это не является принципиально неустранимой проблемой старого способа;
  2. nmap в вашем случае не надо использовать (Learn vimscript the hard way, глава 5: Strict mapping). Для такой задачи вообще‐то nore обычно вреден, но в вашем коде без nore хуже.
  3. чтобы сохранить поведение нельзя использовать normal! (с восклицательным знаком).
  4. чтобы сохранить поведение многосимвольных команд нельзя использовать normal вообще, хоть с, хоть без восклицательного знака;
  5. чтобы не менять символы в двух удалённых друг от друга местах при копировании проще сделать функцию‐помощник и менять их в одном месте.


В вашем коде нужно либо заменить nmap на nnoremap и execute("normal…") на call feedkeys(a:key, "t"), либо использовать <expr>:
function s:ChangeLayout(key)
    call system('osascript -e "tell application \"System Events\" to key code 49 using command down"')
    return a:key
endfunction
nmap <expr> <unique> й <SID>ChangeLayout('q')
<Esc>, кстати, — ещё одна суперфича. Я как‐то недавно ковырял Firefox и удивился, в каком количестве мест Esc не работает:
  • Он не выведет из поля адреса. Может отменить то, что вы там ввели, вернув изначальный адрес, но не уберёт фокус
  • Он не выведет из полей ввода типа textarea
  • Он не отменит поиск по <C-f> или даже / (они вообще отменяются только мышкой, второй ещё по timeout’у).
  • Он не остановит загрузку страницы.
. И это только то, чем я чаще всего пользуюсь. Причём первыми двумя пунктами страдает ещё и chromium. Возможно, конечно, что всё можно как‐то настроить.
Другой способ — использовать neocomplcache. Кроме установки плагина, нужно задать omnifunc для питоновских файлов:
Зачем? Эта настройка задаётся в python-mode-klen. В вашем варианте вы используете поставляующуюся с Vim.
Здесь главный вопрос не скорость. Автосоздание переменных в таком виде зачастую весьма удобно: если проигнорировать импорт, то это одна короткая и понятная строчка (определение 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. Разница в скорости, впрочем, не обнаружена.
Не проверял на скорость, но я в таких случаях использую defaultdict:

from collections import defaultdict
…
tags = defaultdict(lambda: 0)
…
def start_element(name, attrs):
    tags[name] += 1

Но отмечать изменения в произвольно порядке таки можно. Толку — чуть, из‐за остальных проблем я никогда не поверю, что crecord не собирается мне что‐то испортить (слишком много ошибок в UI, чтобы я считал, что авторы могут написать остальные внутренности без ошибок).
Это было очень давно, а я не помню, в чём были проблемы (старое ощущение — «ужас, ужас, ужас» и всё). Сейчас опять запустил, вижу проблему с границами выделений (на русском тексте) и замечательный текст «изменено поло�~A: 5, �~A�~B�~@ок: 165». Если что, это не часть изменений. Также вижу отсутствие возможности изменять текст внутри линии. Вижу замечательное поведение PageUp/PageDown (внутри длинного hunk прокручивает на одну строку). Вижу , двойное нажатие на который не ведёт к возвращению отметки к неотмеченным изменениям добавленного файла, а нажатие на единственный внутренний hunk (но не линию) убирает отметку со всех линий и самого hunk’а, но не с имени файла. При «review and edit» (единственный способ всё‐таки изменить текст внутри линии), а также при обычном commit не виден diff (мне он нужен, чтобы всё‐таки составить сообщение), и нельзя вернуться назад, если при просмотре diff’а обнаружилось что‐то не то. Подозреваю, что посмотреть diff можно, настроив mercurial засовывать его в комментарий (вроде где‐то пробегало что‐то такое, работающее для и «hg commit», и для всего остального).

Всё это не идёт ни в какое сравнение с AuRecord.
Я имею ввиду, можно ли сначала посмотреть (и отметить) изменения в одном файле из конца списка, потом в другом из начала, потом отметить полностью какие‐то файлы в середине, затем вернуться к первому, и, возможно, переотметить.
Последний (и единственный) раз, когда я его смотрел, у него были проблемы с русским языком в файлах. Русский у меня сейчас только на моих старых проектах, но и на новых часто встречаются юникодные символы (в основном апострофы, кавычки (а не ASCII‐убожество), маркеры для складок (использую «▶,▲» вместо «{{{,}}}»)). И ещё мне чего‐то не понравилось в интерфейсе (не помню, что именно). Напомните, в Crecord можно работать с изменениями в произвольном порядке?
Ответ непонятен. У git не должен быть --source, потому что есть --onto?
Первое прекрасно служит в качестве второго. Замечу, что нужная мне часть почти не менялась с mercurial-1.3. Предположительно и с mercurial-1.2, но в Vim нет sys.stdout.closed, поэтому я всегда получаю AttributeError, когда пытаюсь использовать последний.

Никто не занимается сломом API «из любви к исскусству», поэтому просто не лезьте в дебри, следите за изменениями и получите нормальную поддержку всех версий, в том числе тех, когда Command Server не существовал. С бонусом в виде отсутствия затрат на IPC или даже жутких затрат на fork/exec.

На самом деле, расширения ломаются даже чаще — им нужны бо́льшие дебри.
Для того, чтобы оно работало, нужно только обновиться.
Сервер обновлять не обязательно, подробнее в «hg help phases».

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity