Page 48 of 53

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

Posted: Wed 29 Jul, 2009 21:41
by John Doe
Библиотека LuaFAR делает возможным написание плагинов на языке Lua, предоставляя им адаптированную версию FAR API.

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

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

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

Полезное по теме: См. также:

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

Posted: Thu 15 Nov, 2018 13:14
by John Doe

Latest post of the previous page:

Shmuel wrote: Thu 15 Nov, 2018 09:33 Если считаете нужным изменить эту ситуацию - на Мантис.
Я не вижу общей картины, поэтому затрудняюсь определить необходимость.
Кажется что в большинстве подобных случаев нумерация в LuaFAR изменена.
Но поскольку здесь база отсчёта документирована в описании функции, то проблемы никакой нет.

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

Posted: Thu 15 Nov, 2018 13:18
by Shmuel
Проблемы нет, но и противопоказаний к изменению как бы не видно (кроме обратной совместимости).

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

Posted: Sat 17 Nov, 2018 07:33
by SUSim
а по мне 0 это как бы базовый цвет, а потом уже раскраска начинается плагинами/макросами, вроде логично.

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

Posted: Sat 17 Nov, 2018 09:23
by John Doe
Нет никакого базового цвета, вся раскраска только плагинами, и 0 - это первая раскраска.

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

Posted: Sun 18 Nov, 2018 08:36
by SUSim
Ну как хотите, если менять, то щас (чем раньше тем лучше) пока макросов определяющих цвет мало!

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

Posted: Mon 14 Jan, 2019 07:27
by IgorZ
Столкнулся с непонятным поведением обработчика событий просмотрщика Far.
  1. Event{
  2.  
  3.   group="ViewerEvent";
  4.  
  5.   condition=function(_,Event) return Event==F.VE_READ or Event==F.VE_CLOSE end;
  6.  
  7.   action=function(Id) far.Show(viewer.GetFileName(Id)) end;
  8.  
  9. }
Данный обработчик событий показывает имя файла при открытии и закрытии. Если открыть файл в просмотрщике, имя файла возвращается правильно и при открытии, и при закрытии. Если же открыть файл в быстром просмотре, при открытии имя файла возвращается правильно, а при закрытии возвращается nil. Такое различие - нормально или ошибка?
Far 3.0.5351 x86, Windows XP SP3.

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

Posted: Mon 14 Jan, 2019 08:13
by John Doe

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

Posted: Mon 14 Jan, 2019 08:17
by 2useven10
IgorZ wrote: Mon 14 Jan, 2019 07:27 Такое различие - нормально или ошибка?
Не знаю правильно это или нет.
Если переключиться на окно просмотра (Tab) скорее всего имя файла будет правильным.
Похоже Viewer.FileName непустое только если текущая область просмотрщик.
В нормальном просмотре, если окно нективно (F12 ...) - Viewer.FileName тоже пустое.

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

Posted: Mon 14 Jan, 2019 08:43
by John Doe
> Viewer.FileName

Поведение ожидаемое, но выше речь не о нём, а о плагиновом апи.

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

Posted: Mon 14 Jan, 2019 09:28
by 2useven10
John Doe wrote: Mon 14 Jan, 2019 08:43 Поведение ожидаемое, но выше речь не о нём, а о плагиновом апи.
Да. Просто похоже способ получения имени один и тот же.

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

Posted: Mon 14 Jan, 2019 09:43
by IgorZ
2useven10 wrote: Mon 14 Jan, 2019 08:17 Если переключиться на окно просмотра (Tab) скорее всего имя файла будет правильным.
Нет, пустое, я проверил сразу. При чтении, кстати, хоть окно и неактивное, имя файла показывается корректно.

P. S. Проверил viewer.GetInfo. Картина идентичная, так что ситуация шире, на самом деле.

P. P. S. Дописал насчёт viewer.GetInfoVCTL_GETINFO на мантиссе.

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

Posted: Thu 17 Oct, 2019 01:04
by zg
из DN_KILLFOCUS можно вернуть индекс элемента, которому надо передать фокус. в текущей версии оно 0-based.

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

Posted: Thu 17 Oct, 2019 06:47
by Shmuel
zg wrote: Thu 17 Oct, 2019 01:04 из DN_KILLFOCUS можно вернуть индекс элемента, которому надо передать фокус. в текущей версии оно 0-based.
Вроде поправил.

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

Posted: Wed 06 Nov, 2019 07:22
by IgorZ
Всем добрый день. У меня закончилась страда, появилось свободное время, и я начал разбираться с хвостами. Изучая проблему с match, проявившуюся в LuaManager после замены библиотеки string, обнаружил две, как мне кажется, ошибки.

Первая касается встроенной match:

Code: Select all

local txt = ("A\n"):rep(300)
local pati,patr = ".-\n",".*?\n"
local n = 199
far.Show(n,"regex",regex.match(txt,patr:rep(n)))
far.Show(n,"internal",txt:match(pati:rep(n)))
n = 200
far.Show(n,"regex",regex.match(txt,patr:rep(n)))
far.Show(n,"internal",txt:match(pati:rep(n)))
Как видно из примера, совершенно корректный синтаксически паттерн работает, повторённый 199 и менее раз, но вызывает ошибку pattern too complex, повторённый 200 и более раз.

Вторая ошибка относится к regex.match:

Code: Select all

local txt = ("A\n"):rep(300)
local pat1,pat2 = ".*\n",".*?\n"
far.Show("regex",pat1,regex.match(txt,pat1:rep(10)))
far.Show("regex",pat2,regex.match(txt,pat2:rep(10)))
far.Show("internal",pat1,txt:match(pat1:rep(10)))
Как видно из примера, жадный паттерн захватывает тот же фрагмент, что и нежадный. При этом встроенный match отрабатывает жадный паттерн корректно.

P. S. Вероятно, не ошибка, но хотелось бы уточнить у Shmuel: changelog LuaMacro до билда 698 включительно идёт по-русски, а начиная с билда 699 - по-английски. Это так и задумано?

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

Posted: Wed 06 Nov, 2019 08:32
by Shmuel
IgorZ wrote: Wed 06 Nov, 2019 07:22 Как видно из примера, совершенно корректный синтаксически паттерн работает, повторённый 199 и менее раз, но вызывает ошибку pattern too complex, повторённый 200 и более раз.
Это же поведение у стандартного string.match. Ограничение вводится, чтобы предотвратить экспоненциальный рост времени исполнения с увеличением n.
IgorZ wrote: Wed 06 Nov, 2019 07:22 Вторая ошибка относится к regex.match:
И это тоже не ошибка. Для того, чтоб regex.match с паттерном "." находил "\n", ему нужно указать флаг "s" (см. документацию).
IgorZ wrote: Wed 06 Nov, 2019 07:22 changelog LuaMacro до билда 698 включительно идёт по-русски, а начиная с билда 699 - по-английски. Это так и задумано?
Да. По здравому размышлению пришёл к выводу, что так будет правильнее. Английский знают во всём мире, а русский, к сожалению, нет.

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

Posted: Fri 08 Nov, 2019 06:12
by IgorZ
Shmuel wrote: Wed 06 Nov, 2019 08:32
IgorZ wrote: Wed 06 Nov, 2019 07:22 Как видно из примера, совершенно корректный синтаксически паттерн работает, повторённый 199 и менее раз, но вызывает ошибку pattern too complex, повторённый 200 и более раз.
Это же поведение у стандартного string.match. Ограничение вводится, чтобы предотвратить экспоненциальный рост времени исполнения с увеличением n.
Не баг, а фича? А она описана где-то? А то я, вроде бы, не видел в докуметации на Lua упоминания такого ограничения.
Shmuel wrote: Wed 06 Nov, 2019 08:32
IgorZ wrote: Wed 06 Nov, 2019 07:22 Вторая ошибка относится к regex.match:
И это тоже не ошибка. Для того, чтоб regex.match с паттерном "." находил "\n", ему нужно указать флаг "s" (см. документацию).
Про "s" я знаю... А, понял, в чём нюанс, действительно, мой косяк.
Shmuel wrote: Wed 06 Nov, 2019 08:32
IgorZ wrote: Wed 06 Nov, 2019 07:22 changelog LuaMacro до билда 698 включительно идёт по-русски, а начиная с билда 699 - по-английски. Это так и задумано?
Да. По здравому размышлению пришёл к выводу, что так будет правильнее. Английский знают во всём мире, а русский, к сожалению, нет.
Oll korrekt. :)