LuaFAR — библиотека для создания плагинов на языке Lua

[John Doe]

Библиотека LuaFAR делает возможным написание плагинов на языке Lua, предоставляя им адаптированную версию FAR API.

Входит в состав FAR manager (начиная с 3.0 build 2851), и доступна для использования в макросах.

Справка по функциям библиотеки — luafar_manual.chm (в дистрибутиве, папка Encyclopedia).
Мануал весьма лаконичен, предполагает что вы ориентируетесь в FAR Plugins API (FarEncyclopedia.ru.chm, в дистрибутиве)

Дополнения к мануалу:

• far.Menu: в описании приведена ссылка на статью Энциклопедии Виртуальные коды клавиш. Однако не все перечисленные там клавиши на самом деле обрабатываются фаром. В частности, в качестве BreakKey не могут выступать кнопки мыши.
• editor.GetString: о скорости режимов 0/1/2/3 viewtopic.php?p=110435#p110435

Полезное по теме:

• Темы, связанные с far.Timer
• О возвращаемом значении export.ProcessDialogEvent
• Преимущества скрипта, оформленного как LuaFAR плагин, перед макросом
• Наглядный пример для написания простого плагина на LuaFAR: клон Fix Incorrect Names, FarEventsView, KeepEditboxFocus, другие примеры.
• DLL для LUA плагина
• Юникод в LuaFAR
• "юникодный Lua-интерпретатор" lflua.exelfjit.exe, который динамически слинкован не только с lua51.dll, но и с luafar3.dll
• lua51x.exe Lua.exe с встроенными дополнительными библиотеками. [27.06.2013]

См. также:

• LuaFAR for Editor: организатор скриптов и пакетов скриптов пользователя
  LuaFAR: ломка API

[Shmuel]

Latest post of the previous page:

Спасибо за репорт, исправлено.
P.S. вместо function(...) far.Show(...) end можно просто far.Show

[John Doe]

Что собой представляет дескриптор диалога? Почему даже для одного того же открытого диалога дескрипторы всё время получаются разные?
Пример:

Code: [Select all] [Expand/Collapse]

1. local dlgs = {}
2.  
3. Macro{area="Dialog Menu"; key="F1"; action=function()
4.  
5.   local hDlg = far.AdvControl(F.ACTL_GETWINDOWINFO).Id
6.  
7.   dlgs[hDlg] = 1
8.  
9.  
10.  
11.   local t,i = {},1
12.  
13.   for k,v in pairs(dlgs) do t[i],i = k,i+1 end
14.  
15.   far.Show(unpack(t))
16.  
17. end
18.  
19. }

GeSHi © Codebox Plus Extension

.
При вызове из диалога макроса на F1 в таблицу добавляются новые и новые значения (хотя и с совпадающими строковыми представлениями

Code: Select all

╔════════════════════════════╗
║  1│ FarDialog (0x0024e0dc) ║
║  2│ FarDialog (0x0024e0dc) ║
║  3│ FarDialog (0x0024e0dc) ║
╚═══════ 3 arguments ════════╝

).

Получается невозможно использовать дескриптор диалога в качестве ключа таблицы.
Возможно ли как-то обойти эту проблему (tostring ведь не вариант)?
Update:
0002612: LuaFAR: метод для получения "сырого" значения хэндла диалога

[Shmuel]

Что собой представляет дескриптор диалога? Почему даже для одного того же открытого диалога дескрипторы всё время получаются разные?

Представляет собой отдельный тип userdata, со своими методами. Идея в том, что этот тип проверяется при вызовах, предотвращая возможные ошибки.

Разные получаются из-за особенностей реализации. Однако проверка == покажет, что они не разные.

Возможно ли как-то обойти эту проблему (tostring ведь не вариант)?

Если так необходимо использовать их как ключи, могу добавить метод, например "rawhandle", возвращающий одно и то же для хэндлов одного диалога.

[John Doe]

Я рассчитывал что хэндлы разных экземпляров одного диалога будут отличаться, однако поэкспериментировав с равенством убедился что это не так.
Т.е. один и тот же диалог всегда будет иметь один и тот же хэндл.
Теоретически возможна ситуация когда одновременно существуют несколько экземпляров одного и того же диалога/меню.
Не очень это правильно...
Но как я понимаю не от LuaFAR зависит.
Вместо метода "rawhandle" похоже можно использовать функцию tostring.

[DrKnS]

Но как я понимаю не от LuaFAR зависит.

А от кого ещё?
Внутри Far и в plugin api хендл диалога - это просто адрес его экземпляра в памяти.
Разные экземпляры - разные адреса.

[Shmuel]

Внутри Far и в plugin api хендл диалога - это просто адрес его экземпляра в памяти.
Разные экземпляры - разные адреса.

Запускаю 2 Фара, в каждом нажимаю F7 и в диалоге макросом вызываю AdvControl(ACTL_GETWINDOWINFO). Вижу одинаковые Id.

[DrKnS]

Запускаю 2 Фара ... Вижу одинаковые Id.

Ну у нас тут как бы не DOS, адрес уникален в пределах процесса.

[Shmuel]

Ну у нас тут как бы не DOS, адрес уникален в пределах процесса.

При повторных вызовах диалога по F7 (в одном процессе) и получении его хэндла ни разу не удалось увидеть разные значения хэндла.

[zg]

При повторных вызовах диалога по F7 (в одном процессе) и получении его хэндла ни разу не удалось увидеть разные значения хэндла.

в одном фаре сразу f7, в другом f5 esc f7. но я лично не очень понимаю, о чём речь вообще? ну совпадают в тепличных условиях адреса у объекта, но в общем случае совпадений не будет.
в одном экземпляре f7 и там же f9 f m. адреса разные.
update: ну и третий вариант адреса — f7 в дереве. четвёртый — f9 f m в дереве.
и диалог создания папки — он не единственный. есть например диалог выбора цвета.

[Shmuel]

Ну вот мне, например, непонятно, почему при нажатии F5, F6, F7, F8, F10 хэндлы всё время одинаковы (для каждой клавиши - свой, естественно). Думал, может кто объяснит.

Между экспериментами запускал поиск в панелях, который находил и выводил тысячи файлов на врем. панель, думал это на что-то повлияет - ан нет.

[DrKnS]

Как правило, диалоги внутри фара - стековые объекты. Т. е. это не просто какой-то левый адрес в куче, а смещение от начала стека.
Поэтому в зависимости от того, каким способом диалог вызвали и сколько стека при этом заняли, адрес может или совпасть или не совпасть.
Если вы собираетесь на это завязываться - не рекомендую, это полнейшее UB.

[Shmuel]

Если вы собираетесь на это завязываться - не рекомендую, это полнейшее UB.

Завязываться и в мыслях не было (поскольку потребности никакой нет).
Что такое UB не знаю, сорри.

Да, то, что диалоги создаются на стеке, объясняет это явление - спасибо.

[HaRT]

полнейшее UB.

Что такое UB не знаю, сорри.

Подозреваю, что Undefined behavior (в стандартах на Си/Си++ его упоминание регулярно встречается).

[John Doe]

Пожелание по документации:
luafar_manual.chm ::/71.html
Сообщения перечислены не в алфавитном порядке, это затрудняет их поиск.
В частности DM_LIST* разбросаны по списку.

P.S.

Code: Select all

DM_LISTGETITEM:
    Param2:  integer (ItemIndex)
    Result:  table, or nil

В качестве ItemIndex можно указывать 0, что будет означать выбранный пункт меню.
Не нашёл об этом упоминания ни в мануале ни в Энциклопедии.

[Shmuel]

Пожелание по документации:
luafar_manual.chm ::/71.html
Сообщения перечислены не в алфавитном порядке, это затрудняет их поиск.
В частности DM_LIST* разбросаны по списку.

Там многие сообщения сгруппированы, что делает полное упорядочение невозможным.
DM_LIST* в основном упорядочены, возможно что-то куда-то перенести, но не думаю, что это сделает погоду.
По хорошему вся эта статья должна быть переработана, либо нужно сделать по статье на каждый тип сообщения.

И вообще данному мануалу закладка "Index" не помешала бы.

Code: Select all

DM_LISTGETITEM:
    Param2:  integer (ItemIndex)
    Result:  table, or nil

В качестве ItemIndex можно указывать 0, что будет означать выбранный пункт меню.
Не нашёл об этом упоминания ни в мануале ни в Энциклопедии.

Этот 0 в скрипте передаётся Фару как -1. Видимо забыли в доках описать.

[John Doe]

Там многие сообщения сгруппированы, что делает полное упорядочение невозможным.

Строгий алфавитный порядок и не нужен.
Я понимаю что *SET* удобно видеть рядом с *GET*
К сожалению такая группировка тоже не везде (DM_GETEDITPOSITION/DM_SETEDITPOSITION)

DM_LIST* в основном упорядочены, возможно что-то куда-то перенести, но не думаю, что это сделает погоду.

Имхо независимо от того по какому принципу группировать - все DM_LIST* удобно видеть непрерывным списком (сейчас это не так).