В чем причина скобок в именах карт <Plug>?

Многие плагины делают свой открытый интерфейс сопоставления доступным через карты <Plug>. Затем пользователи могут использовать эти карты в качестве крючков для своих собственных сопоставлений, например. :nmap <Leader>fu <Plug>fooPluginUnlinkRootDir.

Недавно я столкнулся с некоторыми плагинами, которые помещают их имена карт в скобки, например.

<Plug>(textobj-indent-a) в плагине textobj-indent,
<Plug>(LineJugglerBlankUp) в плагине LineJuggler.

Этот синтаксис не документируется нигде в файлах справки, и ни один из связанных с ним файлов времени исполнения Vim не использует его. Тем не менее, эти плагины прекрасно справляются со своей задачей.

Какова мотивация скобок? Есть ли преимущества в их использовании? Следует ли поощрять авторов плагинов следовать этой практике (как наилучшей практике)?

Ответ 1

Спасибо ZyX; ваш ответ уже охватывает основные принципы, поэтому позвольте мне добавить, почему я принял нотацию <Plug>(PluginNameAndMore). (Я думаю, что я видел это первым в плагинах Kana Natsuno.)

Две причины:

При переносе сопоставления с другими материалами проще визуально анализировать отдельные целевые объекты сопоставления, например здесь:

imap <C-x><C-c> <Plug>(CompleteStart)<Plug>(CamelCaseComplete)<SID>(CamelCaseCompleteModifyUndo)<Plug>(CamelCasePostComplete)<Plug>(CompleteoptLongestSelect)
При определении нескольких сопоставлений для плагина необходимо быть осторожным, чтобы LHS одного из них не содержался в другом сопоставлении. В противном случае произойдет задержка при срабатывании сопоставления, так как Vim должен ждать дополнительных нажатий клавиш до того, как может быть разрешена неоднозначность. Закрывающая скобка предотвращает любую такую двусмысленность.

BAD                 GOOD
<Plug>MyFunc        <Plug>MyFuncNext, <Plug>(MyFunc)
<Plug>MyFuncReverse <Plug>MyFuncPrev, <Plug>(MyFuncReverse)

Ответ 2

Оба параметра {lhs} и {rhs} в команде сопоставления представляют собой последовательности байтов, которые могут содержать произвольные данные (за исключением NUL-байта), если у него есть натуральное число байтов (для {rhs} с нулевым числом байтов также разрешено). С этой точки зрения практика (…) не имеет преимуществ перед другим.

В частности, для (textobj-…) существует одно незначительное преимущество: вы можете выбрать целую часть {lhs} без <Plug> с движением a) и иметь более читаемые штрихи между словами. Я понятия не имею, почему бы это сделать, так как весь {lhs} можно выбрать с помощью aW (с частью <Plug>).

Я не вижу причин для версии LineJuggler.

Вам лучше спросить авторов об этом. @IngoKarkat здесь, в stackoverflow и, вероятно, скоро прочитает вопрос. Я не знаю, как связаться с Kana Natsuno.