Решил тут поискать по интернету плагины для 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 и спросил про то как открыть файл соседний с открытым. Я не знал. Мне никогда до сих пор не было надо. Пришлось немного почитать хелп. Но в виме есть всё.