Page 3 of 8

Редактор БД плагинов

Posted: Thu 03 Mar, 2016 10:28
by IgorZ
(бывший "Экспорт / импорт данных LuaMacro")
Описание:
Данный скрипт позволяет просматривать данные плагинов, хранящиеся в локальном и глобальном профилях Far-а, редактировать их, экспортировать в файл, а также импортировать из ранее экспортированного файла. По умолчанию предлагаются данные LuaMacro. После выбора другого плагина умолчание меняется до перезагрузки макросов. Формат файла импорта/экспорта текстовый, довольно простой - фактически, .ini-формат с некоторыми дополнительным ограничениями, так что, в принципе, легко редактируемый при надобности. Можно последовательно сохранить несколько разрозненных кусков данных в один файл путём дописывания в конец. Полученный файл можно импортировать в Far.



В стандартной поставке идёт файл, добавляющий следующие возможности:
  • Пункт в меню плагинов.
Требуемая версия Far 3.0.4324+.


Редактор БД плагинов

Posted: Thu 19 May, 2016 12:06
by IgorZ

Latest post of the previous page:

Поскольку замечаний больше не поступает, то...
Версия 2.0.3 - Расширенное меню выбора плагина.

Редактор БД плагинов

Posted: Thu 09 Jun, 2016 18:02
by cyberspace
Детский вопрос: а как его установить-то?
Распаковал, скопировал в /addons/macros, перезапустил far.
Видимо этого недостаточно, т.к. на хоткей a-s-f2 / a-s-f3 реакции нет.

Редактор БД плагинов

Posted: Thu 09 Jun, 2016 18:13
by 2useven10
cyberspace wrote: скопировал в /addons/macros, перезапустил far.
как все макросы (скрипты) - %FARPROFILE%\Macros\scripts\ ?

Редактор БД плагинов

Posted: Thu 09 Jun, 2016 18:55
by cyberspace
2useven10
Спасибо.
Не покажете ли пальцем в документацию, где всё вот это написано?
В каталоге /documentation мануала большого нет, только faq. А встроенная справка удобна только для контекста.

Редактор БД плагинов

Posted: Thu 09 Jun, 2016 19:02
by Shmuel
Encyclopedia\macroapi_manual.ru.chm.

Редактор БД плагинов

Posted: Wed 12 Oct, 2016 10:33
by IgorZ
Версия 2.1.0 - Скрипт можно использовать как модуль. Исправлена область действия в MenuItem. Разделение префиксов. Переделана справка. Добавлено nfo. Мелкие правки.Расширенное меню выбора плагина.

Редактор БД плагинов

Posted: Wed 12 Oct, 2016 21:51
by John Doe
IgorZ wrote: Скрипт можно использовать как модуль.
А для чего такое хитрое коварство: заглушка для модуля?

Раз в дистрибутиве две папки, то наверняка 99% пользователей будут честно копировать обе.
Не сделать ли теперь настоящий модуль?

Редактор БД плагинов

Posted: Fri 14 Oct, 2016 08:03
by IgorZ
John Doe wrote:
IgorZ wrote: Скрипт можно использовать как модуль.
А для чего такое хитрое коварство: заглушка для модуля?
Если, к примеру, в _macroinit.lua вызывается (условно) regscript, а он, в свою очередь, вызывает DBEdit, то без заглушки возникнет ситуация, когда DBEdit не найден - скрипт ещё не успел зарегистрировать себя как модуль. А с заглушкой всё просто - подхватится она, а затем скрипт при загрузке запишет себя, а её уберёт, и при следующем вызове запустится вместо заглушки. Эта ситуация, кстати, впервые всплыла с LuaManager, и, если память не изменяет, с Вашей подачи.
John Doe wrote:Раз в дистрибутиве две папки, то наверняка 99% пользователей будут честно копировать обе.
Не сделать ли теперь настоящий модуль?
Не раз рассматривал такой вариант. Большая проблема в том, что языковые и справочные файлы будут нужны и модулю, и скрипту-затычке, вызывающему модуль. Возникает проблема с их местоположением и именованием (некоторые пользователи переименовывают файлы и раскладывают их в определённые файлы в соответствии со своими соображениями). Вариант с заглушкой наименее затратен для меня и прозрачен для пользователя.

Редактор БД плагинов

Posted: Fri 14 Oct, 2016 08:44
by John Doe
IgorZ wrote: Большая проблема в том, что языковые и справочные файлы будут нужны и модулю, и скрипту-затычке, вызывающему модуль.
С чего это?
Достаточно только модулю.
IgorZ wrote: Возникает проблема с их местоположением и именованием
Есть дистрибутив, и никто ничего не будет внутри его переименовывать и перемещать.
IgorZ wrote: некоторые пользователи переименовывают файлы
Если скрипт "отдельнолежащий" то да.
А в вашем случае будут переименовывать и перемещать саму папку.

Редактор БД плагинов

Posted: Mon 17 Oct, 2016 12:29
by IgorZ
John Doe wrote:
IgorZ wrote: Большая проблема в том, что языковые и справочные файлы будут нужны и модулю, и скрипту-затычке, вызывающему модуль.
С чего это?
Достаточно только модулю.
Предварительную обработку тех же префиксов надо производить, а значит, сообщения об ошибках (сейчас отсутствующие, но потенциально возникающие) возможны; в макросах и menuitem-е тоже присутствует локализованный текст.
John Doe wrote:
IgorZ wrote: Возникает проблема с их местоположением и именованием
Есть дистрибутив, и никто ничего не будет внутри его переименовывать и перемещать.
Внутри нет, а вот весь дистрибутив (5 файлов на данный момент, если не считать заглушку) в случае модуля намертво привязан к папке modules, а в нынешней ситуации вполне переносим в любую удобную папку.
Да, кстати. Если положить DBEdit*.* в modules, то должен работать, как обычный модуль. Во всяком случае, LuaManager, устроенный по той же схеме, работал.
John Doe wrote:
IgorZ wrote: некоторые пользователи переименовывают файлы
Если скрипт "отдельнолежащий" то да.
А в вашем случае будут переименовывать и перемещать саму папку.
1. Только в нынешнем исполнении. Модуль из папки modules перемещать нельзя.
2. Есть опыт, когда пользователь переименовывал скрипты в соответствии со своими привычками (Bookmark*.* в Shell_Bookmark*.* и т. д.).

Редактор БД плагинов

Posted: Tue 25 Oct, 2016 10:49
by John Doe
IgorZ wrote: в макросах и menuitem-е тоже присутствует локализованный текст.
Функция локализации может предоставляться модулем.
IgorZ wrote: а вот весь дистрибутив [...] в нынешней ситуации вполне переносим в любую удобную папку.
IgorZ wrote: 1. Только в нынешнем исполнении. Модуль из папки modules перемещать нельзя.
2. Есть опыт, когда пользователь переименовывал скрипты в соответствии со своими привычками (Bookmark*.* в Shell_Bookmark*.* и т. д.).
Дистрибутив состоит из двух частей: содержимое scripts можно переименовывать/переносить, а содержимое modules нет.
И как ни крути — этого не изменить, независимо от того, будет ли "заглушка", или честный модуль.

Редактор БД плагинов

Posted: Tue 25 Oct, 2016 11:24
by John Doe
Мелкие пожелания по скрипту:
  1. В меню плагинов пункт отображается так: "Plugins DB editor (LuaMacro)"
    Имхо содержимое скобок тут лишнее, ведь при вызове открывается выбор плагина.
  2. Выбор плагина отовсюду вызывается по CtrlS, но ещё интуитивнее если нажатие CtrlPgUp выполняло бы ту же функцию (из меню выбора локального/глобального профиля).
  3. Хотелось бы иметь возможность для просмотра таблиц использовать альтернативные средства.
    (Встроенная функция кажется мне не очень наглядной)
  4. По справке: есть конечно ShiftF1, но я бы добавил в каждый раздел гиперссылку на содержание.
    В штатных плагинах так.
  5. В модуле не нашёл возможности вызывать выбор плагина.
    В справке не описано, но если указать неправильное имя, то выбор выводится, однако при нажатии Esc происходит не то, что ожидается

Редактор БД плагинов

Posted: Tue 25 Oct, 2016 11:59
by IgorZ
John Doe wrote:Мелкие пожелания по скрипту:
  1. В меню плагинов пункт отображается так: "Plugins DB editor (LuaMacro)"
    Имхо содержимое скобок тут лишнее, ведь при вызове открывается выбор плагина.
  2. Выбор плагина отовсюду вызывается по CtrlS, но ещё интуитивнее если нажатие CtrlPgUp выполняло бы ту же функцию (из меню выбора локального/глобального профиля).
  3. Хотелось бы иметь возможность для просмотра таблиц использовать альтернативные средства.
    (Встроенная функция кажется мне не очень наглядной)
  4. По справке: есть конечно ShiftF1, но я бы добавил в каждый раздел гиперссылку на содержание.
    В штатных плагинах так.
  5. В модуле не нашёл возможности вызывать выбор плагина.
    В справке не описано, но если указать неправильное имя, то выбор выводится, однако при нажатии Esc происходит не то, что ожидается
  1. Осталось от старого варианта, когда открывалась БД плагина по умолчанию. Стоит поправить, действительно.
  2. Посмотрю. Сделаю, если ничему не помешает.
  3. Гляну. Может, сделаю.
  4. Спасибо, идея архиправильная.
  5. Погляжу. По задумке, всё должно работать, как и при обычном запуске. Исправлю, если не так.

Редактор БД плагинов

Posted: Tue 25 Oct, 2016 12:03
by IgorZ
Потерялось почему-то. Попробую снова запостить.
John Doe wrote:
IgorZ wrote: в макросах и menuitem-е тоже присутствует локализованный текст.
Функция локализации может предоставляться модулем.
В принципе, можно и так, но для этого надо всё переделывать. А для этого нужны объективные основания, перевешивающие аргументы за сохранение текущего состояния. На данный момент в качестве такого основания мне в голову приходит только "Шеф, всё пропало! Эта схема больше не работает/форматирует жёсткий диск при запуске/и т. п.". В конце концов, я больше не использую хаки вроде самостоятельного добавления своего модуля непосредственно в _G.package.loaded, всё делается по правилам.
John Doe wrote:
IgorZ wrote: а вот весь дистрибутив [...] в нынешней ситуации вполне переносим в любую удобную папку.
IgorZ wrote: 1. Только в нынешнем исполнении. Модуль из папки modules перемещать нельзя.
2. Есть опыт, когда пользователь переименовывал скрипты в соответствии со своими привычками (Bookmark*.* в Shell_Bookmark*.* и т. д.).
Дистрибутив состоит из двух частей: содержимое scripts можно переименовывать/переносить, а содержимое modules нет.
И как ни крути — этого не изменить, независимо от того, будет ли "заглушка", или честный модуль.
Есть разница: несколько (пять, в данном случае) фиксированных файлов в modules, или одна заглушка, большинству (по моим прикидкам) пользователей вообще совершенно не нужная и, соответственно, безболезненно ими при желании удаляемая. Я бы вообще не стал её вводить, если бы придумал конвенциональный способ обходиться без неё (или без редактирования _macroinit.lua в качестве альтернативы).

P. S. Есть, на мой взгляд, фундаментальный принцип: если пакет создан, чтобы предоставлять универсальный программный интерфейс любым программам, его надо делать модулем (библиотекой, в более общем смысле). semver - типичный тому пример. Если он предоставляет интерфейс пользователю - это скрипт/программа. С этой точки зрения и LuaManager, и DBEdit - скрипты с минимальным элементом модульности. Ведь, скажем, Word или Excel, хоть и имеют программный интерфейс, не являются библиотеками.

Редактор БД плагинов

Posted: Tue 25 Oct, 2016 12:48
by John Doe
IgorZ wrote: Гляну. Может, сделаю.
dump из moonscript доступен из коробки, хотя бы его для начала, может остальное и не понадобится.
IgorZ wrote: В принципе, можно и так, но для этого надо всё переделывать. А для этого нужны объективные основания
Я рассматриваю данное обсуждение как теоретическое, и не призываю всё переделывать.
IgorZ wrote: В конце концов, я больше не использую хаки вроде самостоятельного добавления своего модуля непосредственно в _G.package.loaded, всё делается по правилам.
Но вы всё же модифицируете package.loaded, да и заглушка сама по себе хак.
IgorZ wrote: С этой точки зрения и LuaManager, и DBEdit - скрипты с минимальным элементом модульности.
Но элемент есть, и вопрос в том, как его правильнее реализовать. А точнее: надо ли что-то выдумывать своё, или достаточно использовать стандартный механизм lua.
Вариантов ведь много, например ваш модуль-заглушка может выглядеть так:

Code: Select all

local function dummy()
  far.Message("dbedit not loaded yet")
end

local m = {dbedit=dummy}

local mt = {}
function mt:__call(...)
  return self.dbedit(...)
end

return setmetatable(m,mt)
А в скрипте соответственно:

Code: Select all

local m = require "dbedit"
m.dbedit = ModProc        
По крайней мере это позволит обойтись без хаков.

Редактор БД плагинов

Posted: Tue 25 Oct, 2016 13:01
by John Doe
P.S.
Отдельно хочу обратить внимание, что сейчас при попытке "раннего" вызова (например require"dbedit"() в _macroinit.lua) пользователь получит серию непонятных сообщений об ошибках.

В моём варианте (из поста выше) сообщение будет вразумительным.

Ну а полноценный модуль позволил бы вызывать утилиту сколь угодно "рано" без ограничений.