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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

keymap & langmap в помощь

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