Пользовался такими лифтами в БЦ Kutuzoff Tower (Москва, станция метро Кунцевская). Непривычно, но ничего ужасного. Из неприятного только дребезг кнопок в пультах, из‐за которого система несколько раз получила неверную информацию о том, что я отправляюсь на 11‐й, а не первый или десятый этаж (соответственно, с пультов на десятом и первом этаже). Только я про такие лифты к тому времени уже успел прочитать на хабре.
А ваш отчим в каком здании работает? И вы этим лифтом пользовались в том же здании? Просто я видел их только в Kutuzoff Tower и мне интересно, где ещё такие можно встретить в Москве.
Я не использовал бо́льшую часть старой настраивамости. Но вкладки у меня должны быть справа. Остальных (кто хочет снизу, сверху и слева) тоже обижать не стоит.
Я использую текущий буфер — просто очищаю его и заполняю заново. Возможно это не самый лучший путь, скорее это — первое, что пришло в голову и было реализовано.
Использование текущего буфера — это то, что вы должны делать с BufReadCmd. При использовании команды надо его всё же создавать, иначе область применения команды ограничиться либо командой‐обвязкой, которая его‐таки создаст (и добавит ненужный уровень вложенности), либо запуском через vim +Reddit. То есть можно просто взять вашу функцию и мой код с BufReadCmd и оставить так.
Кстати: у BufReadCmd есть ещё преимущества: можно взять и написать tabedit reddit:// и не париться созданием кучи команд на все случаи: когда пользователь захочет видеть посты из reddit в новой вкладке, новом окне сверху/слева/справа/снизу, в текущем окне и т.д.
Кстати, если я не ошибаюсь, у вас каждый раз при вызове :Reddit в sys.path добавляется путь. Зачем?
И ещё: я не вижу, где вы создаёте новый буфер.
Вообще, если требуется показать какие‐либо данные я всегда использую не команду, а событие BufReadCmd и псевдо‐протокол (к примеру,
augroup Reddit
autocmd! BufReadCmd reddit:// :call Reddit()
augroup END
) + ещё, возможно, FileReadCmd: на случай, если хочется использовать :read reddit://. Теоретически это даст возможность восстановления таких буферов при загрузке сессий. Правда, я не использую последние.
А всю подсветку правильно было бы убрать в syntax/reddit.vim и использовать set ft=reddit. Не надо писать велосипеды для обработки выключенного синтаксиса. И не надо бояться множества мелких файлов.
Не раньше, чем кто‐то научит его работать с несколькими нитями и получит нормальное API для различных вещей. Что будет очень и очень нескоро.
Сейчас его при некоторой удаче можно уронить стандартной функциональностью: изменением размера окна (gvim, не vim) и клиент‐серверным взаимодействием. Как это нормально исправить непонятно: слишком много глобальных переменных.
Мне лично никогда не нужно было ничего сверх протаскивания буфера обмена через ssh. Пока я перейду к другому компьютеру я уже совершенно забуду, что именно находится в буфере обмена.
И, кстати, какой(ие) буфер(а) предполагается синхронизировать и с чем? В X11 их три, используются два («мышиный» или primary, «буфер обмена» или clipboard; есть ещё secondary, доступный через xclip, но как без xclip (или C‐шных библиотек) поместить в него или достать из него что‐либо, я не знаю). В windows буфер обмена один. В android используется только один (весьма вероятно, что второго также нет: в конце‐концов, здесь графика не на X11).
В опроснике есть варианты «история будет сохраняться на своём сервере» и «история будет шифроваться своим ключом». (Перевод заведомо неточный. Спрашивалось, насколько взолнованы вы будете безопасностью сервиса, ответы по форме (но не по сути) к вопросу не подходят, а я их ещё переформулировал в обещания.)
По опыту сидения в issue tracker’е powerline, который может быть установлен (и зачастую устанавливается) в два места: в систему с помощью pip и в .vim/bundle, могу сказать, что замалчивание такой ошибки (которое здесь (в powerline) происходит), приводит к появлению кучи народа именно с проблемой обновлённого только в одном месте powerline. Если вы ожидаете, что ваше дополнение будет положено в два места, ни в коем случае не используйте такой простой guard, по крайней мере, в одиночку. Ни s:, ни g:. У меня вылезают ошибки, но за счёт frawor — то есть guard уже не используется в одиночку.
С g:, если вы заботитесь о такой ситуации, надо сохранять expand('<sfile>') в переменную и проверять соответствие при запуске (то есть, сначала if exists(), внутри if expand('sfile') isnot# g:… с сообщением об ошибке).
Впрочем, я не видел реальных пользователей с такой проблемой.
У меня при этом будет куча ошибок и кому‐то придётся удалить скрипт из одного места: framework предполагает регистрацию всех внешних интерфейсов, а также принципиальное неиспользование function! и command! (именно с восклицательными знаками, а не неиспользование вообще). Такое поведение гораздо лучше, чем притворяться, что ошибок нет, а потом узнавать, что дополнение было обновлено в одном месте, а загружается из другого.
При использовании только событий кучи ошибок может и не быть, но необходимо будет хотя бы одно предупреждение о том, что файл с таким именем уже загружен. (Под именем следует полагать часть полного пути файла без runtimepath и .vim и с компонентами пути, разделёнными /, независимо от используемой ОС. Например, plugin/aurum.)
Ошибки не было — нечего исправлять, см. коммент ниже. Я, кстати, использую для страховки локальные для скрипта переменные (s:): если кому‐то надо отключить конкретное дополнение, то для этого есть менеджеры путей (pathogen) или дополнений (VAM, Vundle, …), а засорять глобальную область видимости тем, что не является абсолютно необходимым я не люблю. Тем более, что отключение загрузки можно легко добавить в мой framework в виде одной глобальной переменной на все дополнения со списком отключённых, а не пачки по одной переменной на дополнение, если кому‐то потребуется.
Кстати, в vim-7.4a можно не трогать sys.path. Только модуль надо класть не в plugin/, а в python2/, python3/ или pythonx/ (для второй, третьей и обеих версий Python соответственно).
Она и так глобальная. Локальные для файла переменные начинаются с s:. И страхуют от загрузки файла, поскольку эта область видимости не очищается. Без префикса переменные локальны только внутри функции, а finish внутри функции не работает.
There are several name spaces for variables. Which one is to be used is
specified by what is prepended:
(nothing) In a function: local to a function; otherwise: global
Единственное, что меня бесит на SO — это то, что различные ошибки на стороне их сервера перенаправляют меня на страницу с другим адресом и после исправления ошибки надо нажимать не F5, а назад.
Ещё при увеличении в Opera (≤12) едет вёрстка. Впрочем, она при увеличении много где едет.
Короче, мелкие ошибки программистов и верстальщиков. Сообщество и система (само)регулирования у них весьма неплохи, на эту часть я никогда не жаловался.
В вашем случае нужно было делать цитату, если по ссылке есть ответ на вопрос, и комментарий со ссылкой, если ответа на вопрос нет. Пересказ нужен, только если цитата в первом случае будет слишком большой. Если у проблемы по ссылке уже появился конкретный статус НЕИСПРАВИМ, как вы предполагаете будет, то это тоже может быть ответом¹, но пересказ причин данного статуса ИМХО вполне уместен.
¹ Во всяком случае, никто не удаляет ответы, вся суть которых сводится к «в Vim такое сделать нельзя» (иногда даже с указанием причин), даже если они не содержат предложений, как можно добиться чего‐то подобного, или если рядом есть ответ, показывающий, как это сделать можно. Иногда, впрочем, удаляют сами авторы (чтобы не отхватить минусов).
Я не имею ввиду что правила stackoverflow не правильные, нужно их конечно соблюдать, просто имхо некоторые из них направлены на не-увод пользователей с сайта. Так же немного бесит когда модераторы меняют сообщения и немного искажают смысл, например «easy deploy, deploy instructions for CentOS» заменяют на «with easy deploy instructions for CentOS.»
Это делают почти всегда не модераторы. Любой пользователь может взять и изменить вам ответ, а я (и ещё двое с достаточной репутацией) проголосовать за принятие изменения. Я могу изменить чужой ответ без голосования вообще: с достаточно большой репутацией и такие действия доступны.
Для этого у них есть FAQ по ссылке «help» в заголовке. Вот здесь есть информация о том, какие ответы удаляются.
Ответ на вопрос «кто удалил» должен быть виден (насколько я помню, ваши собственные ответы вам должны быть видны всегда):
. Но у меня достаточно большая репутация, чтобы видеть чужие удалённые ответы. Возможно, «deleted by …» новичкам не показывается. Замечу, что ссылка «edit» ещё доступна и по ней всё ещё можно осуществлять изменение ответа. Полагаю,
«undelete», которая отправит запрос модераторам, тоже должна быть вам доступна.
Для прояснения того, что видят модераторы (и могут ли они вообще выставить причину), лучше отправиться на meta. Не являясь модератором, я могу лишь привлекать их внимание, используя «flag» или голосовать за закрытие вопроса (но не его удаление и не удаление ответа). В последнем случае причина всегда выставляется, но она обычно весьма общая. Кто голосовал за закрытие тоже видно. Как разрешается ситуация, когда кто‐то голосовал за закрытие по одной причине, а кто‐то — по другой, я не видел.
Это неудобно без различных дополнений. Нужно как минимум два: одно для навигации по проекту в виде чего‐то вроде Command-T и ещё одного, который будет переключать каталоги, если вы откроете другой проект в той же сессии (у меня это самописный велосипед, но я вроде встречал аналоги на vim.org).
Когда Command-T у меня не было, а я не имел привычки открывать все файлы проекта сразу, часто ловил себя на попытках открыть файл из того же каталога, в котором находится тот файл, что я сейчас просматриваю. И это при том, что я никогда не использовал autochdir и открывал Vim из корня проектов.
Указанный скрипт имеет смысл, если вам не хочется писать то же поведение на VimL или любом из других поддерживаемых скриптовых языков.
Во втором случае обычно дают цитаты из материалов по ссылке либо же пишут такой ответ в комментариях, а не в виде ответа. Я, кстати, о таком правиле не помню¹, но всегда делал именно так, потому что так делают остальные.
¹ Мне проще соблюдать два вместе с некоторыми общими для всех правилами этикета: «делай как они» и «учись на ошибках». Первое соблюдать легко, если вы читаете намного чаще, чем пишете, а обычно это именно так. Насчёт второго: нарушенное правило легче запоминается, когда с ним связано эмоциональное воспоминание о наказании. Правила я при этом всё же читаю, но они очень быстро забываются. Перечитывать, разумеется, лениво.
Я себе сделал зеркало: SSD+HDD. Конечно, в таком варианте скорость записи будет ограничиваться HDD, но она мне и не нужна. Скорость чтения же соответствует сумме скоростей всех участников.
Впрочем, никакой RAID не отменяет необходимость резервных копий.
А ваш отчим в каком здании работает? И вы этим лифтом пользовались в том же здании? Просто я видел их только в Kutuzoff Tower и мне интересно, где ещё такие можно встретить в Москве.
vim +Reddit. То есть можно просто взять вашу функцию и мой код с BufReadCmd и оставить так.Кстати: у BufReadCmd есть ещё преимущества: можно взять и написать
tabedit reddit://и не париться созданием кучи команд на все случаи: когда пользователь захочет видеть посты из reddit в новой вкладке, новом окне сверху/слева/справа/снизу, в текущем окне и т.д.:Redditвsys.pathдобавляется путь. Зачем?И ещё: я не вижу, где вы создаёте новый буфер.
Вообще, если требуется показать какие‐либо данные я всегда использую не команду, а событие
BufReadCmdи псевдо‐протокол (к примеру, ) + ещё, возможно, FileReadCmd: на случай, если хочется использовать:read reddit://. Теоретически это даст возможность восстановления таких буферов при загрузке сессий. Правда, я не использую последние.А всю подсветку правильно было бы убрать в syntax/reddit.vim и использовать
set ft=reddit. Не надо писать велосипеды для обработки выключенного синтаксиса. И не надо бояться множества мелких файлов.Сейчас его при некоторой удаче можно уронить стандартной функциональностью: изменением размера окна (gvim, не vim) и клиент‐серверным взаимодействием. Как это нормально исправить непонятно: слишком много глобальных переменных.
И, кстати, какой(ие) буфер(а) предполагается синхронизировать и с чем? В X11 их три, используются два («мышиный» или primary, «буфер обмена» или clipboard; есть ещё secondary, доступный через xclip, но как без xclip (или C‐шных библиотек) поместить в него или достать из него что‐либо, я не знаю). В windows буфер обмена один. В android используется только один (весьма вероятно, что второго также нет: в конце‐концов, здесь графика не на X11).
s:, ниg:. У меня вылезают ошибки, но за счёт frawor — то есть guard уже не используется в одиночку.С
g:, если вы заботитесь о такой ситуации, надо сохранятьexpand('<sfile>')в переменную и проверять соответствие при запуске (то есть, сначалаif exists(), внутриif expand('sfile') isnot# g:…с сообщением об ошибке).Впрочем, я не видел реальных пользователей с такой проблемой.
function!иcommand!(именно с восклицательными знаками, а не неиспользование вообще). Такое поведение гораздо лучше, чем притворяться, что ошибок нет, а потом узнавать, что дополнение было обновлено в одном месте, а загружается из другого.При использовании только событий кучи ошибок может и не быть, но необходимо будет хотя бы одно предупреждение о том, что файл с таким именем уже загружен. (Под именем следует полагать часть полного пути файла без runtimepath и .vim и с компонентами пути, разделёнными
/, независимо от используемой ОС. Например,plugin/aurum.)И вы забыли «50 — возможность оставлять комментарии где угодно».
stackoverflow.com/help/whats-reputation
s:): если кому‐то надо отключить конкретное дополнение, то для этого есть менеджеры путей (pathogen) или дополнений (VAM, Vundle, …), а засорять глобальную область видимости тем, что не является абсолютно необходимым я не люблю. Тем более, что отключение загрузки можно легко добавить в мой framework в виде одной глобальной переменной на все дополнения со списком отключённых, а не пачки по одной переменной на дополнение, если кому‐то потребуется.Кстати, в vim-7.4a можно не трогать sys.path. Только модуль надо класть не в plugin/, а в python2/, python3/ или pythonx/ (для второй, третьей и обеих версий Python соответственно).
s:. И страхуют от загрузки файла, поскольку эта область видимости не очищается. Без префикса переменные локальны только внутри функции, аfinishвнутри функции не работает.vimhelp.appspot.com/eval.txt.html#internal-variables
Ещё при увеличении в Opera (≤12) едет вёрстка. Впрочем, она при увеличении много где едет.
Короче, мелкие ошибки программистов и верстальщиков. Сообщество и система (само)регулирования у них весьма неплохи, на эту часть я никогда не жаловался.
¹ Во всяком случае, никто не удаляет ответы, вся суть которых сводится к «в Vim такое сделать нельзя» (иногда даже с указанием причин), даже если они не содержат предложений, как можно добиться чего‐то подобного, или если рядом есть ответ, показывающий, как это сделать можно. Иногда, впрочем, удаляют сами авторы (чтобы не отхватить минусов).
Это делают почти всегда не модераторы. Любой пользователь может взять и изменить вам ответ, а я (и ещё двое с достаточной репутацией) проголосовать за принятие изменения. Я могу изменить чужой ответ без голосования вообще: с достаточно большой репутацией и такие действия доступны.
Ответ на вопрос «кто удалил» должен быть виден (насколько я помню, ваши собственные ответы вам должны быть видны всегда):
. Но у меня достаточно большая репутация, чтобы видеть чужие удалённые ответы. Возможно, «deleted by …» новичкам не показывается. Замечу, что ссылка «edit» ещё доступна и по ней всё ещё можно осуществлять изменение ответа. Полагаю,
«undelete», которая отправит запрос модераторам, тоже должна быть вам доступна.
Для прояснения того, что видят модераторы (и могут ли они вообще выставить причину), лучше отправиться на meta. Не являясь модератором, я могу лишь привлекать их внимание, используя «flag» или голосовать за закрытие вопроса (но не его удаление и не удаление ответа). В последнем случае причина всегда выставляется, но она обычно весьма общая. Кто голосовал за закрытие тоже видно. Как разрешается ситуация, когда кто‐то голосовал за закрытие по одной причине, а кто‐то — по другой, я не видел.
Когда Command-T у меня не было, а я не имел привычки открывать все файлы проекта сразу, часто ловил себя на попытках открыть файл из того же каталога, в котором находится тот файл, что я сейчас просматриваю. И это при том, что я никогда не использовал autochdir и открывал Vim из корня проектов.
Указанный скрипт имеет смысл, если вам не хочется писать то же поведение на VimL или любом из других поддерживаемых скриптовых языков.
¹ Мне проще соблюдать два вместе с некоторыми общими для всех правилами этикета: «делай как они» и «учись на ошибках». Первое соблюдать легко, если вы читаете намного чаще, чем пишете, а обычно это именно так. Насчёт второго: нарушенное правило легче запоминается, когда с ним связано эмоциональное воспоминание о наказании. Правила я при этом всё же читаю, но они очень быстро забываются. Перечитывать, разумеется, лениво.
Впрочем, никакой RAID не отменяет необходимость резервных копий.