MacroLib — Far Macro Library

[Acerbic]

Latest post of the previous page:

Есть виш/предложение: распознавать левые модификаторы для клавиш срабатывания макросов - LCtrl, LAlt - в дополнение к правым, как в LuaMacro.

В текущей реализации, насколько я понял, ситуация двузначная:
1) если в биндинге нет специфично правых модификаторов (например "CtrlAltP"), то подразумеваются оба, у макрос вызывается по всем 4м вариантам нажатия - RCtrlRAltP, RCtrlLAltP, LCtrlRAltP, LCtrlLAltP.

2) если в биндинге есть хоть один правый модификатор, то модификаторы по умолчанию становятся левыми. Т.е. CtrlRAlt начинает расцениваться как LCtrlRAlt, а RCtrlAlt - как RCtrlLAlt.

В результате можно задать макро на исключительно правую комбинацию (например RAltX, но не LAltX), но нельзя задать на исключительно левую (LAltX, но не RAltX).

Приходится изворачиваться и задавать желаемы макрос на неспецифичную комбинацию - AltX, а на правое сочетание ставить затычку.

[Max Rusov]

Есть виш/предложение: распознавать левые модификаторы для клавиш срабатывания макросов - LCtrl, LAlt - в дополнение к правым, как в LuaMacro

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

[John Doe]

Если MacroLib ещё не совсем заброшен, то может стоит сделать ещё один шаг в сторону Lua?
Т.е. уменьшить отличия между fmlua и обычными макро-файлами.
Например в fml с давних пор есть макроподстановки, и когда-то это было шагом вперёд, но сейчас уже архаично.
Ведь в Lua достаточно просто иметь общую функцию.

Другой пример: для сохранения состояний в fmlua нет другого способа кроме как использование глобальных таблиц.
Постоянное употребление _G неудобно, некрасиво (да и не правильно)

А ведь вполне реально совместить все нативные свойства Lua с уникальными возможностями MacroLib.

[Max Rusov]

Возможно, я не настолько силен в LUA, но мне не приходит в голову как это сделать.
Если популярно объясните - я подумаю.

[John Doe]

Всё проще, чем вы можете себе представить: достаточно хранить макросы не как строки, а как функции.
Так они и получат общий контекст.

1. Загрузчик fml-макросов может представлять собой lua-скрипт (довольно простой, тут кое-что уже разжевано)
2. В результате работы этого скрипта все fml-макросы в виде функций сохраняются (например, для простоты), в глобальную таблицу _G.FML
3. MacroLibrary как я понимаю использует для запуска макросов MCTL_SENDSTRING, тут ничего менять не надо, только Param2 будет содержать не текст макроса, а ссылку на загруженную функцию.

Вот и вся магия.

[Max Rusov]

Всё проще, чем вы можете себе представить: достаточно хранить макросы не как строки, а как функции.

Не уверен, что все так просто. По крайней мере я пока не понял. Даже просто синтаксически непонятно как это оформить в синтаксисе FML.

Code: Select all

macro Descr="Test1"
{{
  local function LocalFunc()
  end

  LocalFunc()
  CommonFunc()
}}

macro Descr="Test2"
{{
  CommonFunc()
}}

Где и как описать CommonFunc ?

[John Doe]

CommonFunc надо описать в том же файле, вне всех Macro {{ ... }}.
В любом месте, лишь бы выше определения использующего эту функцию макроса.

А сами определения надо трансформировать в формат macro {field1=aaa, field2=bbb, ...}
В файле синтаксис менять не обязательно, можно трансформировать на лету.
(можно по случаю и поменять, но это уже другой вопрос)

[Max Rusov]

CommonFunc надо описать в том же файле, вне всех Macro {{ ... }}.
В любом месте, лишь бы выше определения использующего эту функцию макроса.

Так не получится, если только не делать полный Lua-парсер, чего я, конечно, делать не буду.
Можно сделать типа псевдо-макроса common {{ }} или даже просто {{ }}

Насчет регистрации я еще не понял, но если даже предположить, что это как-то возможно, вопрос - когда это делать?

Сразу все FML при запуске - не хочется, может быть долго.

Все из одного FML при вызове любого макроса из него? Приемлемо, но тогда нельзя будет делать библиотеки, либо придется придумывать какие-нибудь imports.

И еще непонятно, что делать с обновлением? Есть способ удалить старые функции и добавить новые?

[John Doe]

Можно сделать типа псевдо-макроса common {{ }} или даже просто {{ }}

Конечно можно.
А ещё проще - рассмотреть вариант записи определений макросов в духе LuaMacro.

Насчет регистрации я еще не понял, но если даже предположить, что это как-то возможно, вопрос - когда это делать?

Сразу все FML при запуске - не хочется, может быть долго.

Нативные макросы ведь быстро грузятся, с чего бы вашим дольше?

Все из одного FML при вызове любого макроса из него? Приемлемо, но тогда нельзя будет делать библиотеки, либо придется придумывать какие-нибудь imports.

Для библиотек в Lua есть стандартное средство - модули. Какие преимущества у FML-библиотек?
Где вообще посмотреть такую библиотеку и пример её использования?

И еще непонятно, что делать с обновлением? Есть способ удалить старые функции и добавить новые?

Новые - добавляются в таблицу. Старые - удаляются. В чём загвоздка?

[Max Rusov]

А ещё проще - рассмотреть вариант записи определений макросов в духе LuaMacro.

Ну, это вообще бессмысленно. Если FML придется переписывать - то проще сразу в LUA. MacroLib имеет несколько преимуществ по модификаторам клавиш, но почти все можно так или иначе перенести на native. Или добавить эти фичи в Far. Так что я не намерен менять формат уж точно.

Нативные макросы ведь быстро грузятся, с чего бы вашим дольше?.

Native макросы являются обычными LUA файлами. Для них не делали свой парсер, как я понимаю - они просто парсятся библиотеками LUA. В случае FML все будет значительно сложнее: MacroLib парсит FML файлы и конвертирует их в LUA формат, а затем как-то скрамливает Far'у - через API или вообще через LUA скрипт... Шагов больше, наверняка будет дольше.

Для библиотек в Lua есть стандартное средство - модули. Какие преимущества у FML-библиотек?

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

[John Doe]

Если FML придется переписывать [...]

Под "FML" вы тут имеете в виду плагин или совокупность готовых макрофайлов?

MacroLib имеет несколько преимуществ по модификаторам клавиш

Собственно да, и если добавить их в фар, то FML и не понадобится.

В случае FML все будет значительно сложнее [...] Шагов больше, наверняка будет дольше.

Я лично уверен что это не проблема. Но к чему гадать, всё и так будет видно.

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

Понятно. Обсуждалось в теме "зачем require". В данном случае это не принципиально, всё как и в нативных макросах, т.е:
- библиотеку можно поместить в глобальную таблицу (желательно в персональный namespace).
- чтобы код библиотеки выполнился до его использования тоже ничего нового придумывать нет нужды (например есть автостартующие макросы)

[sToLp]

MacroLib имеет несколько преимуществ по модификаторам клавиш

Собственно да, и если добавить их в фар, то FML и не понадобится.

Полагаю, что это вовсе не обязательно.

К примеру, я постоянно использую замечательно комфортный макрос "Закладки в панелях". И если, дай Бог, в Луа появятся возможности для создания подобного, то, всё же, не стану тратить время на конвертацию его из fmlua- в lua-формат, а буду продолжать использовать его из под MacroLib`а. Как и множество других макролибовских макросов тоже.

По-моему FML только тогда может стать вовсе не нужным, когда Lua заметно обгонит его, станет значительно лучше, а не почти таким же.

Да и чем в перспективе может быть в принципе плоха ситуация наличия альтернативы?

[John Doe]

sToLp
Вроде MacroLib у вас тоже никто не отбирает.
Обратите внимание, что он давно не развивается, и на то есть причины.

P.S.
Тот макрос скорее всего и сейчас можно переписать для чистого LuaMacro, хотя и придётся использовать "кривые" способы для детекции нажиманий/отпусканий .

[Max Rusov]

Вообще говоря, единственное, чего мне самому не хватает в MacroLib - это произвольный condition. Сейчас его уже, вроде, можно сделать, нужно только синтаксис придумать. Предложения?

[John Doe]

Если даже не трогая формат сделать то, что я выше предлагаю, то condition можно будет задавать как в Luamacro — функцией (анонимной, или по общему идентификатору).
В простых случаях можно ограничиться и строкой, в кавычках или в блоке [[...]]

condition должен идти последним в определении макроса. Завершение condition можно считать начало тела макроса, т.е. {{

[Max Rusov]

Я пока склоняюсь к тому, что как то давно предлагал:
http://forum.farmanager.com/viewtopic.p ... 227#p74227