LINUX.ORG.RU

Реализована одна из самых востребованных фич в VIM: совместная работа над документом. Collaborative Editing for Vim

 , ,


1

2

Наиболее востребованным фичреквестом (№4 в текущем списке) является:

№   points       voters     feature
4   176  (-14)   66  -7     add collaborative editing: changes made to a buffer show up in another Vim in a second 
а именно: возможность совместной работы над документом.

Fred K. Schott рад представить вашему вниманию: CoVim - Collaborative Editing for Vim

Основные возможности текущей ревизии:

  • Легкая настройка и использование
  • Идеально подходит для парного программирования
  • Отображение участников совместного редактирования разными курсорами
  • Работа с вашей текущей конфигурацией (.vimrc)

Подробнее в блогозаписи Фрэда.

Демонстрация, исходный код и информация об установке на сайте проекта.

Быстрая установка единственной зависимости и плагина через патоген Тима Попа:

pip install twisted && git clone git://github.com/FredKSchott/CoVim.git ~/.vim/bundle/CoVim

★★☆

Проверено: Shaman007 ()

Ответ на: комментарий от ZyX

В lua с созданием абстракций на C так плохо?

наоборот, хорошо. Хочешь, пиши слой абстракции, не хочешь - не пиши, а просто сделай тонкий интерфейс к сишным функциям.

Нормальная абстракция над всем этим многого стоит.

Это на первый взгляд. В реальности же обычно абстракция только добавляет глюков и сковывает функционал. Если интерфейс хороший, то его нужно реализовать прямо в сишном интерфейсе.

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

наоборот, хорошо. Хочешь, пиши слой абстракции, не хочешь - не пиши, а просто сделай тонкий интерфейс к сишным функциям.

Так тонкий интерфейс можно на чём угодно из остальных языков написать. Только нафиг он никому не нужен.

Это на первый взгляд. В реальности же обычно абстракция только добавляет глюков и сковывает функционал. Если интерфейс хороший, то его нужно реализовать прямо в сишном интерфейсе.

В C коде зачастую ничего подходящего нет. Так что воплощение идей из RFC добавит также и функций в нижележащий код (чаще всего — путём выделения кода из имеющихся функций). Уже имеющийся интерфейс не так уж и толст, большая часть кода в if_py_both.h — всеми любимая обработка ошибок и конвертация в/из объектов Python. Хотя, конечно, когда мне потребовалась функция «get_options_value_strict» (единственная функция, способная при получении значения отличить настройку, локальную для окна и для буфера) — она была написана. Впрочем, эта функция и ещё две (для нахождения индекса окна и вкладки) — всё, что я помню из добавленных мною функций не в if_py*, использующихся только в Python интерфейсе.

И вообще, разговор беспредметен. Напишите своё RFC для lua и сравним, «тонкость» — понятие относительное. «Не так уж и толст» — для меня это «не содержит сложной логики» и «вызывает не слишком много функций из основного кода» (обычно одну или 0 (нужен только доступ к полям структур)).

ZyX ()
Ответ на: комментарий от ZyX

Так тонкий интерфейс можно на чём угодно из остальных языков написать.

большая часть кода в if_py_both.h — всеми любимая обработка ошибок и конвертация в/из объектов Python.

взаимоисключающие параграфы.

«Не так уж и толст» — для меня это «не содержит сложной логики» и «вызывает не слишком много функций из основного кода» (обычно одну или 0 (нужен только доступ к полям структур)).

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

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

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

взаимоисключающие параграфы.

Я же сказал, что «тонкость» — понятие относительное. Перечисленные вещи мною не считаются увеличивающими «толщину».

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

Замечательно. А что с выделением памяти (важнее, освобождением), передачей возвращаемых значений через указатели в аргументах функции, преобразованием исключений VimL в их аналоги на lua (если таковые имеются)? Я не хочу видеть этот ужас в высокоуровневом языке.

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

Не так. Использование вашего варианта либо накладывает вето на изменение интерфейса в C после его публикации, либо ведёт к созданию функций‐обёрток и использованию только их из lua.

Второе ничем не отличается от варианта с Python (кроме меньшего преобразований числа преобразований типов, если всё можно написать в соответствии с вашими словами). Чисто на первое никто не пойдёт — добавление новых возможностей или исправление ошибок часто сопровождается изменением прототипа функции, что автоматически приведёт ко второму варианту.

Здесь у lua нет ровным счётом никаких преимуществ. Из‐за обратной совместимости биндинг не будет обновляться, какой бы удобной процедура обновления не была.

А вот с Python другое дело: я могу в любой момент добавить аргументов в функцию из биндинга, не нарушая обратной совместимости: если сделаю соответствующие значения по‐умолчанию для новых аргументов. В C никаких значений по‐умолчанию же нет, значит их, вероятно, не будет и в биндинге, созданном таким способом. Кивать на функции с переменным числом аргуметов не надо: во‐первых, их может не быть (Vim поддерживает компиляторы, не предоставляющие данной возможности), во‐вторых, с ними неудобно работать.

ZyX ()

Когда релизуют самую востребованную фичу?

chromium ()
Ответ на: комментарий от fero

А я-то думал, что хоткеи в не английских раскладках починили

keymap & langmap в помощь

jellyfish ()
Ответ на: комментарий от jellyfish

Знаю я про эти костыли. Только внутренняя раскладка нормально работает, но я не хочу переключаться в Vim как-то иначе

fero ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.