@erthalion21 июл 2013 в 05:32

Пока Vim пишет код за Вас…

3 мин

29K

Python * VIM *

+16

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

@alhimik45 21 июл 2013 в 05:53

Да уж… Vim был бы отличной операционной системой, если бы в нем был текстовый редактор

@torkve 21 июл 2013 в 07:18

Путаете с емаксом.

@alhimik45 21 июл 2013 в 13:35

Ну, судя по таким постам, Вим скоро его догонит.

@ZyXI 21 июл 2013 в 18:44

Не раньше, чем кто‐то научит его работать с несколькими нитями и получит нормальное API для различных вещей. Что будет очень и очень нескоро.

Сейчас его при некоторой удаче можно уронить стандартной функциональностью: изменением размера окна (gvim, не vim) и клиент‐серверным взаимодействием. Как это нормально исправить непонятно: слишком много глобальных переменных.

@Griffer 21 июл 2013 в 22:06

Нити? Последний раз я видел эту терминологию в известном трактате Терренса Чана, где он еще сокеты гнёздами называл. Я не имею желания придраться, просто хочется узнать, почему именно нити, а не потоки?

@klirichek 22 июл 2013 в 02:52

Думаю, Терренс Чан всё же называл сокеты sockets, а потоки — threads. А дальше уже на вкус переводчика.
Можно потоки и фибры, а можно — нити и волокна. И в последнем варианте сразу ясно, что из чего состоит.

@Griffer 22 июл 2013 в 09:21

Прошу прощения. Конечно я имел в виду перевод. И все же, на мой взгляд, потоки и волокна звучат традиционнее нитей и фибр. Но это моё мнение, никому не навязываю.

@Paul 23 июл 2013 в 22:17

Термин «нити» обычно используют люди, которым приходится работать одновременно и с нитями и с потоками: потоки это streams, например fstream, stringstream и т.д., а нити это threads.

@torkve 21 июл 2013 в 07:19

if exists('vim_reddit_module')
finish
endif

Переменная должна быть глобальной — g:vim_reddit_module
Иначе это не страхует от повторной загрузки плагина.

@erthalion 21 июл 2013 в 07:23

да, опечатка — благодарю за находку)

@ZyXI 21 июл 2013 в 09:09

Ошибки не было — нечего исправлять, см. коммент ниже. Я, кстати, использую для страховки локальные для скрипта переменные (s:): если кому‐то надо отключить конкретное дополнение, то для этого есть менеджеры путей (pathogen) или дополнений (VAM, Vundle, …), а засорять глобальную область видимости тем, что не является абсолютно необходимым я не люблю. Тем более, что отключение загрузки можно легко добавить в мой framework в виде одной глобальной переменной на все дополнения со списком отключённых, а не пачки по одной переменной на дополнение, если кому‐то потребуется.

Кстати, в vim-7.4a можно не трогать sys.path. Только модуль надо класть не в plugin/, а в python2/, python3/ или pythonx/ (для второй, третьей и обеих версий Python соответственно).

@torkve 21 июл 2013 в 09:51

s: использовать точно плохо, т.к. кто-то может по ошибке положить скрипт в два места (в plugins/ и bundle/.../ например)

@ZyXI 21 июл 2013 в 10:35

У меня при этом будет куча ошибок и кому‐то придётся удалить скрипт из одного места: framework предполагает регистрацию всех внешних интерфейсов, а также принципиальное неиспользование function! и command! (именно с восклицательными знаками, а не неиспользование вообще). Такое поведение гораздо лучше, чем притворяться, что ошибок нет, а потом узнавать, что дополнение было обновлено в одном месте, а загружается из другого.

При использовании только событий кучи ошибок может и не быть, но необходимо будет хотя бы одно предупреждение о том, что файл с таким именем уже загружен. (Под именем следует полагать часть полного пути файла без runtimepath и .vim и с компонентами пути, разделёнными /, независимо от используемой ОС. Например, plugin/aurum.)

@ZyXI 21 июл 2013 в 10:53

По опыту сидения в issue tracker’е powerline, который может быть установлен (и зачастую устанавливается) в два места: в систему с помощью pip и в .vim/bundle, могу сказать, что замалчивание такой ошибки (которое здесь (в powerline) происходит), приводит к появлению кучи народа именно с проблемой обновлённого только в одном месте powerline. Если вы ожидаете, что ваше дополнение будет положено в два места, ни в коем случае не используйте такой простой guard, по крайней мере, в одиночку. Ни s:, ни g:. У меня вылезают ошибки, но за счёт frawor — то есть guard уже не используется в одиночку.

С g:, если вы заботитесь о такой ситуации, надо сохранять expand('<sfile>') в переменную и проверять соответствие при запуске (то есть, сначала if exists(), внутри if expand('sfile') isnot# g:… с сообщением об ошибке).

Впрочем, я не видел реальных пользователей с такой проблемой.

@ZyXI 21 июл 2013 в 08:59

Она и так глобальная. Локальные для файла переменные начинаются с 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

vimhelp.appspot.com/eval.txt.html#internal-variables

@torkve 21 июл 2013 в 09:50

Ок, согласен.

@Michael134096 21 июл 2013 в 07:25

«Vim пишет код за Вас…» — это действительно так? как с ним работать?
в остальном статья осталась непонятной. что же делает ваш плагин? зачем он нужен?

@erthalion 21 июл 2013 в 08:40

Возможно, статья получилась немного сумубрной, но в ней описано все, что я хотел сказать. Плагин в данном случае не есть самоцель — через него я просто демонстрирую (и разбираюсь сам), как реализовать в vim нужную фичу на python.
Если же вам непонятно в буквальном смысле, что делает этот плагин — он отображает посты из reddit на странице редактора. Это маленькая приятность, которую я давно хотел для себя сделать. Собственно, поэтому он и нужен — в первую очередь, мне)

@Michael134096 21 июл 2013 в 12:14

Спасибо, что вы выкладываете в свободный доступ все, что вам удалось реализовать и рассказываете об этом сообществу.
Сочтите дальнейшее как конструктивную критику и желание получить качественно поданный материал.

1.Вместо кричащих заголовков «Vim пишет код за Вас…» читателю/пользователю было бы интереснее узнать, что же реально делает ваш плагин.
2.Вместо картинки из мультфильма стоило бы скриншотами показать, как было и как стало. Или, что лучше, сделать видео на ютьюбе.
3.Установка и мелочи — под кат. (Не всем же это надо, и не все будут это устанавливать. Пожалейте чужое время)
4.Поменьше метафор и аллегорий. Приятнее читать, когда все просто и ясно. Мы же не художественную литературу читаем.

Спасибо.

@Michael134096 21 июл 2013 в 12:19

5.Если это нужно только и в первую очередь вам, то может не стоит лишний раз хвастаться и выкладывать «очередной суперполезный плагин» на хабр? или, что лучше, сделать «сей скромный трактат» читаемым и полезным?

Спасибо.

НЛО прилетело и опубликовало эту надпись здесь

@tangro 21 июл 2013 в 10:34

>"(подобрать соответсвующее сравнение)"

Штопор?

@SVolkov 21 июл 2013 в 15:52

А я наивный… думал что тут реально что-то крутое будет, что перевернет мое представление о текстовом редакторе и покажет как он за меня пишет нужный мне код. Эх

@ZyXI 21 июл 2013 в 18:34

Я думал о каком‐то очередном конкуренте snipmate/XPtemplate/… Тысячи их, но остальные далеко не так известны.

@ZyXI 21 июл 2013 в 19:00

Кстати, если я не ошибаюсь, у вас каждый раз при вызове :Reddit в sys.path добавляется путь. Зачем?

И ещё: я не вижу, где вы создаёте новый буфер.

Вообще, если требуется показать какие‐либо данные я всегда использую не команду, а событие BufReadCmd и псевдо‐протокол (к примеру,

augroup Reddit
    autocmd! BufReadCmd reddit:// :call Reddit()
augroup END

) + ещё, возможно, FileReadCmd: на случай, если хочется использовать :read reddit://. Теоретически это даст возможность восстановления таких буферов при загрузке сессий. Правда, я не использую последние.

А всю подсветку правильно было бы убрать в syntax/reddit.vim и использовать set ft=reddit. Не надо писать велосипеды для обработки выключенного синтаксиса. И не надо бояться множества мелких файлов.

@erthalion 22 июл 2013 в 03:00

Кстати, если я не ошибаюсь, у вас каждый раз при вызове :Reddit в sys.path добавляется путь. Зачем?

Это недосмотр — конечно, надо добавлять только при запуске плагина.

И ещё: я не вижу, где вы создаёте новый буфер.

Я использую текущий буфер — просто очищаю его и заполняю заново. Возможно это не самый лучший путь, скорее это — первое, что пришло в голову и было реализовано.

А всю подсветку правильно было бы убрать в syntax/reddit.vim и использовать set ft=reddit. Не надо писать велосипеды для обработки выключенного синтаксиса. И не надо бояться множества мелких файлов.

Согласен. Судя по всему, мне придется внести еще кучу мелких и не очень исправлений, т.к. в создании плагинов к Vim я очевидный новичок. Благодарю за замечания — они чрезвычайно полезны для меня)

@ZyXI 22 июл 2013 в 14:37

Я использую текущий буфер — просто очищаю его и заполняю заново. Возможно это не самый лучший путь, скорее это — первое, что пришло в голову и было реализовано.

Использование текущего буфера — это то, что вы должны делать с BufReadCmd. При использовании команды надо его всё же создавать, иначе область применения команды ограничиться либо командой‐обвязкой, которая его‐таки создаст (и добавит ненужный уровень вложенности), либо запуском через vim +Reddit. То есть можно просто взять вашу функцию и мой код с BufReadCmd и оставить так.

Кстати: у BufReadCmd есть ещё преимущества: можно взять и написать tabedit reddit:// и не париться созданием кучи команд на все случаи: когда пользователь захочет видеть посты из reddit в новой вкладке, новом окне сверху/слева/справа/снизу, в текущем окне и т.д.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий