Библиотека LuaFAR делает возможным написание плагинов на языке Lua, предоставляя им адаптированную версию FAR API.
Входит в состав FAR manager (начиная с 3.0 build 2851), и доступна для использования в макросах.
Справка по функциям библиотеки — luafar_manual.chm (в дистрибутиве, папка Encyclopedia).
Мануал весьма лаконичен, предполагает что вы ориентируетесь в FAR Plugins API (FarEncyclopedia.ru.chm, в дистрибутиве)
Дополнения к мануалу:
far.Menu: в описании приведена ссылка на статью Энциклопедии Виртуальные коды клавиш. Однако не все перечисленные там клавиши на самом деле обрабатываются фаром. В частности, в качестве BreakKey не могут выступать кнопки мыши.
Несколько методов объекта Settings Control принимают параметр Root, тип которого в мануале указан как integer.
Однако если передать nil, то это не приведёт к ошибке.
Не правильнее в этом случае вызывать runtime error, как это происходит если например передать в параметре Root строку, или логическое значение?
John Doe, да, несоответствие документации и реализации.
В реализации тип этого параметра не "integer", а "flag", а для "флагов" значение nil всегда является допустимым и трансформируется в 0.
Может просто документацию поправить?
Shmuel wrote: ↑Mon 29 Oct, 2018 10:11
Может просто документацию поправить?
Я рассуждаю так: nil в данном контексте смысла заведомо не имеет, и если он всё же передаётся, то может означать лишь то, что в коде ошибка (неинициализированная переменная).
Если передавать nil как 0 то ошибку можно замаскировать, что не очень хорошо.
Этот параметр - флаг. Для флагов nil -> 0. 0 == FSSF_ROOT.
В LuaFAR API есть много функций с опциональными параметрами и не обязательно последними в списке параметров. Во всех этих случаях передача неинициализированной переменной может быть отловлена только ран-тайм тестированием. Данный случай подпадает под эту категорию (после правки документации). Если вы убеждены, что это не тот случай, откройте тикет на Мантисе.
John Doe wrote: ↑Tue 30 Oct, 2018 11:16
far.FreeSettings
Желательно в мануале добавить примечание, поясняющее особенности функции, с перекрёстной ссылкой на метод схожего назначения.
Мантис.
DrKnS wrote: ↑Tue 30 Oct, 2018 12:06
а какова вообще область применения этой функции?
Область применения - освободить все открытые хэндлы скопом, без необходимости отслеживать каждый из них (иногда можно забыть).
В период до LuaMacro, эта функция вообще вызывалась луафар'ом автоматически при возвращении управления от плагина Фару, впоследствии я автоматическое освобождение убрал.
Last edited by Shmuel on Tue 30 Oct, 2018 12:28, edited 1 time in total.
Shmuel wrote: ↑Tue 30 Oct, 2018 12:24без необходимости отслеживать каждый из них
Ну это как бы не память, которую можно доверить garbage collector'у и оставить на потом. При освобождении этих хендлов происходят сайд-эффекты, так что их откладывание, накапливание и закрытие в неизвестном порядке, наверное, может иметь неожиданные последствия.
Поэтому автоматическое освобождение и было убрано. У программиста - полный контроль и, если хочет вызвать far.FreeSettings(), значит знает, что делает. Никто не заставляет пользоваться этой функцией.
Last edited by Shmuel on Tue 30 Oct, 2018 12:41, edited 1 time in total.
IgorZ wrote: ↑Fri 02 Nov, 2018 05:34
(во всяком случае, если не станет известно, что использование far.FreeSettings() приводит к серьёзной ошибке).
Возможно я плохо объяснил.
Другой скрипт (не ваш) создал настройки, которыми намерен пользоваться некоторое время.
В это время ваш скрипт берёт и закрывает настройки ВСЕХ скриптов.
Неаккуратненько.
John Doe wrote: ↑Fri 02 Nov, 2018 08:02
Другой скрипт (не ваш) создал настройки, которыми намерен пользоваться некоторое время.
Совет пользовать метод Free() вместо ф-ции FreeSettings() конечно проавильный, но этот "другой скрипт" по идее не должен так делать. По-видимому, этот другой скрипт сохраняет свои настройки по событию ExitFar, но ведь оно может и не произойти (в случае крэша Фар).
Правильная тактика: тебя вызвали - сохрани настройки перед возвращением управления (если их изменял).