Журнал Витуса

Когда-то давно я тестировал почтовый клиент iris для vim. Оно меня тогда совершенно не впечатлило. Впрочем, прошло два с половиной года. Если столько времени назад чего-то в мире opensource не было, стоит поискать еще раз.

Поискал и нашел himalaya-vim. Это как-то имеет по-моему более вменяемый дизайн - базируется на командно-строчном почтовом клиенте, который запускает в фоне. Это по-моему гораздо логичнее, чем писать всю обработку протоколов и форматов на встроенном скриптовом языке, даже если у него в стандартной библиотеке есть соответствующие модули (а это уже требует недефолтного языка. iris был на питоне).

Сам по себе почтовый клиент, на который это опирается himalaya, тоже штука довольно интересная. Написан на Rust, поддержиивает спеециальный микроязычок разметки для описания мультипарт-MIME сообщений. Но как-то он мне не глянулся.

Я подумал, а может поискать командно-строчный почтовый клиент поприличние и самому вокруг него вимовский плагин накрутить?

Правда, от современной почты требуется как минимум поддердка smtp и imap, а также аттачментов (у himalaya все это есть).

Первый попавшийся в дистрибутиве клиент оказался s-nail. Вроде он все что надо умеет. И даже такая замечательная фишка как поддержка .netrc там есть, чтобы пароли не хранить по куче конфигурационных файлов. Единственное что мне в нем не понравилось, так это то, что он не умеет сообщать о приходе новой почты, ежели запущен и ждет команды от пользователя. Традиционный mailx, который без аттачментов сетевых протоколов и юникода, по-моему это умел. Но тут вообще у автора отношение к imap какое-то странное. Он, судя по документации даже выпилить его хотел, но пользователи очень попросили так не делать.

Зато автор в курсе что такое line-buffered stdio. И это оченьу упростит управление его программой из другой программы. например vim. В общем, возможно, правильный подход - написатьт плагин вокрут s-nail, потом для этого плагина написать свой mailx, с поддержкой IDLE и прочих imap-вкусностей (например на базе c-client от alpine).

Кстати, на сайте у автора есть еще его собственные реализации грейлистинга и dkim для postfix. Посмотреть на них что ли. Все равно собирался dkim у себя поднимать.

Решил тут поискать по интернету плагины для vim для управления задачами. Нашел целую кучу

• gtd.vim
• vim-quicktask
• vim-tasks
• vim-orgmode (дрожите, емаксеры!)
• vim-tada

Вот теперь думаю что бы из них попробовать.

Попробовал iris - почтновый клиент встроенный в vim. Как то он меня не впечатлил. Странная схема работы с паролями, неудобный интерфейс навигации по папкам. Почему-то не включились биндинги для навигации по сообщениям, и соответствнено попробовать как там работает цитирование не получилось.

Нет, fugitive это счастье с большой буквы Щ. Как я раньше без него жил... Когда у тебя в jira задачи в статус Waiting For Merge в экран не влазят, фугитивовские :Git merge и :Git diff неоценимы.

Теперь еще научитсья тесты не в отдельных окнах screen, а в term-буферах vim запускать..

А то в screen я что-то не вижу как можно изнутри screen (в смысле из скрипта, запущенного в нём) сделать две вещи

1. Поменять название текущего окна, которое показыватся в статуслайне
2. Запустить скрипт в новом окне текущего screen.

Обнаружил сущестование в vim таких полезных событий для автокоманд как BufReadCmd и BufWriteCmd.

В результате теперь у меня получилось сделать плагин (который лежит в ~/.vim/plugin/fossilwiki.vim)

и умеет открывать и сохранять странички по именам вида wiki://Название.

При этом, если страничка была открыта через этот плагин, на ,l назначается команда превращения текущего слова/выделенного текста в маркдауновскую ссылку, а если нет, то нет.

Осталось повесить на <Enter> переход по такой ссылке (уже имеющейся в тексте) и, пожалуй уже можно будет хвастаться в фоссиловской рассылке. Здесь я как-то пока не соображу, как определить текующую позицию курсора, и как от неё искать границы ссылки.

Текст плагина пока такой:

augroup fossilwiki
au! * wiki://*
au BufReadCmd wiki://* let s:page=shellescape("< amatch>:t")
\ |exe "r !fossil wiki export ".s:page
\ . "\|\| fossil wiki create ".s:page." /dev/null"
\ | :%s/^M$//e
\ | set filetype=markdown |doau BufReadPost
au BufReadPost wiki://* :map < buffer> ,l lbcw[< Esc>pa](wiki?name=< Esc>pa)< Esc>
au BufReadPost wiki://* :vmap < buffer> ,l da[< Esc>pa](wiki?name=< Esc>
\:let @@=substitute(@@,' ','+','g')< CR>pa)< Esc>
au BufWriteCmd wiki://* exe "w !fossil wiki commit "
\.  shellescape("< amatch>:t") . " -M text/x-markdown"
\| set nomodified
augroup end

(бэкслеш с начале строки это признак продолжения команды с предыдущей строки. Чтобы не было слишком длинных строк.)

И еще тут есть один грязный хак, который унаследован от шелловского скрипта, использовавшегося раньше - если страница не существует, она создается (пустая) в момент чтения. Возможно, правильнее было бы заводить buffer-local переменную, которая бы содержала слово create если страницы не существует, и слово commit, если существует. Но это я еще не разобрался с неймспейсами в vim.

P.S. А чтобы дримвидсовский конвертер маркдауна не принимал вимовские токены в угловых скобках за незакрытые html-тэги, пришлось везде после < пробелов навставлять, так как почему-то &lt; он понимает в обычном тексте, но не в преформаттед блоке. А на тэги ругается и в нём тоже.

Вчера в ходе обсуждения VOom задумался о том, почему у меня в своё время не пошёл vcscommand.

Казалось бы, работа с версиями является необходимым следствием работы с текстом и в значительной степени её включает. Тем более что если ты пользуешься разными привычками, а я пользуюсь git для работы с чужими проектами (включая рабочие) и fossil для собственых. Впрочем собственные в git тоже есть).

Почему-то даже в тех случаях, когда мне надо отрезолвить 250 однотипных конфликтов, не пропустив среди них 5 конфликтов другого типа, которые надо резолвить по-другому, я не пользуюсь каким-то стандартным инструментом, а пишу на ходу пару макросов, который мне проще воспроизвести из головы, чем вспоминать, на какие клавиши я их повесил в прошлый раз.

Форк vcscommand с поддержкой fossil я в своё время находил, так что запихнуть в единый интерфейс работу с git и fossil он позволяет.

Возможно, дело в том, что для меня работа с VCS это в первую очередь работа не с текстом, а с проектом. Запустить тесты и по их результатам решить, коммитить этот снапшот или нет.

Возможно, в том, что разные VCS предполагают настолько разный workflow, что загонять их в общую систему команд неудобно. Впрочем есть git, который внутри себя настолько разнообразный что поддерживает много разных workflow в рамках отдельно взятой vcs.

Ну и уже упоминавшийся эффект того, что команды собственно VCS все равно помнить надо (так как именно в их терминах описывается логика работы этой VCS и ее отличия от других). А раз так слой команд редактора, которые являются оберткой над ними, является лишней сущностью, которую оказалось лень запоминать.

Вообще интересно что с 2013 года (когда я пытался этот плагин освоить) развитие vcscommand.vim практически не идет. А что git, что fossil - активно развиваются. Так что, возможно, это не только у меня не сложилось работать с vcs из vim, а не наоборот.

X-Post to LJ

Сегодня я узнал, что в vim-е есть понятие filename-modifiers.

То есть в частности, если вам нужно открыть файл лежащий в той же директории, что и текущий (и эта директория ни разу не cwd), то :e %:h/filename сработает.

Еще может оказаться полезным действие :cd %:h (или даже cd %:p:h). Хоть на кнопку его вешай. Но я хронически не в состоянии запомнить самостоятельно созданных макросов и алиасов.

Соответственно, полезной идиомой может оказаться :w %:t - это если вы сказали vim /some/unwritable/path, а cwd writable.

Еще интересный модификатор :S.


А все потому, что пришел shaplov и спросил про то как открыть файл соседний с открытым. Я не знал. Мне никогда до сих пор не было надо. Пришлось немного почитать хелп. Но в виме есть всё.