Page 2 of 3

Идея: скрипты в метасимволах

Posted: Fri 02 Nov, 2018 08:25
by John Doe

Latest post of the previous page:

IgorZ wrote: Fri 02 Nov, 2018 06:04 Предлагаю в список возвращаемых значений добавить true - команду не выполнять, пометку снять: функция уже сама всё сделала.
Подскажите в каком сценарии это может быть полезно.
IgorZ wrote: Fri 02 Nov, 2018 06:04 Может, вместо ... лучше таблицу?
... соответствует тому, как аргументы представлены при использовании метасимвола.
Это кстати тоже вполне вопрос для обсуждения, ведь можно и !lua!func {arg1=val1,arg2=val2} (имхо избыточно, но решать всё равно не мне).
IgorZ wrote: Fri 02 Nov, 2018 06:04 В ряде случаев это удобнее.
arg = {...}.
IgorZ wrote: Fri 02 Nov, 2018 06:04 Все флаги в параметрах, наверное, логично убрать в State.
Поясните.
IgorZ wrote: Fri 02 Nov, 2018 06:04 Для Item, вероятно, наиболее логично использовать tPluginPanelItem.
Да, но см. fnparce.cpp: я вовсе не уверен что эта информация там доступна.
Также вспомните, что на плагиновых панелях Применить Команду вообще не реализовано, а при использовании ассоциаций элемент распаковывается во временную папку, и это уже совсем не tPluginPanelItem. Edit
При использовании ассоциаций из командной строки аналогично, элемент не принадлежит панели.

Идея: скрипты в метасимволах

Posted: Sun 04 Nov, 2018 19:56
by Smitis
Имхо, в идеале было лучше что-то типа ![=[выражение lua]=], тогда не нужно будет описывать никаких отдельных Symbol. Вместо [=[ в случае необходимости использовать [==[ [===[ и т.д.

Идея: скрипты в метасимволах

Posted: Mon 05 Nov, 2018 12:19
by John Doe
Smitis wrote: Sun 04 Nov, 2018 19:56 тогда не нужно будет описывать никаких отдельных Symbol.
Разве вы только что не описали отдельный символ, своего рода?
(Имхо, не очень. Громоздко.)

Идея: скрипты в метасимволах

Posted: Mon 05 Nov, 2018 13:09
by Smitis
John Doe
А писать отдельные конструкции это не громоздко? И вообще, зачем плодить лишние сущности?
Разве вы только что не описали отдельный символ, своего рода?
Так можно сказать о любом метасимволе. Я не настаиваю именно на конструкции именно [=[ ]=], но что-то типа такого упростит синтаксический разбор строки.

Идея: скрипты в метасимволах

Posted: Mon 05 Nov, 2018 13:17
by John Doe
Smitis wrote: Mon 05 Nov, 2018 13:09 А писать отдельные конструкции это не громоздко? И вообще, зачем плодить лишние сущности?
Вы имеете ввиду, что не нужно никак специально определять подстановочные функции (то что расписано тут: viewtopic.php?p=151184#p151184).

Не могу с этим согласиться (учитывая все описанные в том посте ньюансы).

P.S.
Я не возражаю, что может быть удобно указывать выражение прямо в метасимволе. Используя предложенный мной подход это ведь тоже возможно.

Идея: скрипты в метасимволах

Posted: Mon 05 Nov, 2018 13:51
by Smitis
John Doe wrote: Mon 05 Nov, 2018 13:17 Вы имеете ввиду, что не нужно никак специально определять подстановочные функции
Да. В моём варианте в качестве подстановочных функций можно использовать ОБЫЧНЫЕ функции lua как частный случай. Параметры передавать как ... ![==[func(...)]==]

Идея: скрипты в метасимволах

Posted: Mon 05 Nov, 2018 14:25
by John Doe
John Doe wrote: Mon 05 Nov, 2018 13:17 Используя предложенный мной подход это ведь тоже возможно.
Предположим, у нас уже определена функция eval (а это можно хоть из коробки), тогда в моём варианте всё можно сделать похожим образом:

Code: Select all

!*eval[[func(...)]]
Smitis wrote: Mon 05 Nov, 2018 13:09 но что-то типа такого упростит синтаксический разбор строки.
Об разборе действительно стоит подумать.

Идея: скрипты в метасимволах

Posted: Mon 05 Nov, 2018 16:09
by Smitis
John Doe wrote: Mon 05 Nov, 2018 14:25 Предположим, у нас уже определена функция eval (а это можно хоть из коробки), тогда в моём варианте всё можно сделать похожим образом
Вот! Всё тоже самое, только Вы предлагаете для этого некие специальные программные конструкции, а я предлагаю обойтись штатными средствами.

Идея: скрипты в метасимволах

Posted: Mon 05 Nov, 2018 16:21
by Smitis
John Doe wrote: Thu 01 Nov, 2018 11:46 Осталась неопределённость с параметрами action
А зачем вообще параметры? Если нужен список выделенных файлов, текущий файл и пр. то их можно получить через api.
John Doe wrote: Wed 31 Oct, 2018 13:59 Кроме того, если идея получит развитие, то возможны дополнения, например дополнительный запуск функции после обработки нескольких выделенных файлов.
Опять таки, в моём случае, вызвали функцию, функция обработала выделенные файлы, если нет выделенного - текущий файл, потом сняла выделение, потом ещё что-то выполнила, потом вернула значение, которое подставилось на место метасимвола.

Идея: скрипты в метасимволах

Posted: Tue 06 Nov, 2018 06:59
by IgorZ
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 Предлагаю в список возвращаемых значений добавить true - команду не выполнять, пометку снять: функция уже сама всё сделала.
Подскажите в каком сценарии это может быть полезно.
Предлагалось, исходя из общих соображений: это единственный возможный результат, не отражённый в списке вариантов. Но пример придумать нетрудно.
Например, когда для части выделенных файлов требуется выполнить два действия (одно по команде, другое в функции), а для остальных - только одно. Скажем, мы выделили кучу текстовых файлов, из них надо выбрать данные, а часть из файлов ещё и заархивировать.
Или ещё проще: мы выделили кучу текстовых файлов, часть из них надо заархивировать, часть не трогать. Что, не тронутые так и должны оставаться выделенными?
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 Может, вместо ... лучше таблицу?
... соответствует тому, как аргументы представлены при использовании метасимвола.
Это кстати тоже вполне вопрос для обсуждения, ведь можно и !lua!func {arg1=val1,arg2=val2} (имхо избыточно, но решать всё равно не мне).
Так ведь всё, здесь написанное, по определению - вопрос для обсуждения.
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 В ряде случаев это удобнее.
arg = {...}.
Ну, в принципе, можно и так. Хотя я исхожу из того, что таблица гораздо практичнее в большинстве случаев.
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 Все флаги в параметрах, наверное, логично убрать в State.
Поясните.
Это тоже состояние.
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 Для Item, вероятно, наиболее логично использовать tPluginPanelItem.
Да, но см. fnparce.cpp: я вовсе не уверен что эта информация там доступна.
Также вспомните, что на плагиновых панелях Применить Команду вообще не реализовано, а при использовании ассоциаций элемент распаковывается во временную папку, и это уже совсем не tPluginPanelItem.
При использовании ассоциаций из командной строки аналогично, элемент не принадлежит панели.
Ну, с наполнением полей таблицы надо думать, а саму структуру удобно взять готовую, по мере необходимости добив дополнительными полями (исходный путь, к примеру).

Идея: скрипты в метасимволах

Posted: Tue 06 Nov, 2018 09:44
by John Doe
Smitis wrote: Mon 05 Nov, 2018 16:09 Вот! Всё тоже самое, только Вы предлагаете для этого некие специальные программные конструкции, а я предлагаю обойтись штатными средствами.
Именно так, я считаю, что подстановочные функции достаточно специфичны.
Сомневаюсь, что конструировать функцию прямо в метасимволе будет распространённой практикой.
Чаще удобнее иметь предварительно заданные функции, и даже если задавать их штатным образом, то удобнее (на практике) держать их вместе, в отдельной таблице, типа _G.symbol.
В итоге, использование отдельного загрузчика видится мне предпочтительным, поскольку предоставляет дополнительные удобства по администрированию метасимволов (наряду и с другими загружаемыми сущностями: макросами, событиями, и др.)
И второй момент: гибкость, потенциальная и реальная (например предлагаемый флаг OnceForSelected).
Smitis wrote: Mon 05 Nov, 2018 16:21 А зачем вообще параметры? Если нужен список выделенных файлов, текущий файл и пр. то их можно получить через api.
Например, чтобы передать источник вызова, и др. свойства (см. мою спецификацию).
Выделенный файл мы конечно через апи получим, но что если это вызов по ассоциации из архива? Как нам получить имя распакованного файла во временной папке?
Альтернативой параметрам может быть переменная из окружения функции (об этом тоже сказано в спецификации).

Идея: скрипты в метасимволах

Posted: Tue 06 Nov, 2018 10:01
by John Doe
IgorZ wrote: Tue 06 Nov, 2018 06:59 Предлагалось, исходя из общих соображений: это единственный возможный результат, не отражённый в списке вариантов.
Тоже думал об этом, но сознательно отказался, поскольку на практике вариант получается лишний.
IgorZ wrote: Tue 06 Nov, 2018 06:59 Например, когда для части выделенных файлов требуется выполнить два действия (одно по команде, другое в функции), а для остальных - только одно. Скажем, мы выделили кучу текстовых файлов, из них надо выбрать данные, а часть из файлов ещё и заархивировать.
Или ещё проще: мы выделили кучу текстовых файлов, часть из них надо заархивировать, часть не трогать. Что, не тронутые так и должны оставаться выделенными?
Этот случай предусмотрен в спецификации, флаг SelectedAtOnce.
IgorZ wrote: Tue 06 Nov, 2018 06:59 Это тоже состояние.
Спецификация конечно же предварительная, и я специально не делал попыку что-либо из параметров объединять/группировать в Params.
Но да, это может быть что угодно, например и позиционные аргументы action(Params,State,Item,...), где флаги объединены в Params.

А вот конкретно в State я пожалуй не хотел бы их добавлять, потому что по замыслу этим состоянием должна управлять сама функция, и будет удобнее не иметь там ничего лишнего, например во избежание конфликтов.
Возможно, лучше назвать аргумент иначе.

Идея: скрипты в метасимволах

Posted: Tue 06 Nov, 2018 11:37
by IgorZ
John Doe wrote: Tue 06 Nov, 2018 10:01
IgorZ wrote: Tue 06 Nov, 2018 06:59 Предлагалось, исходя из общих соображений: это единственный возможный результат, не отражённый в списке вариантов.
Тоже думал об этом, но сознательно отказался, поскольку на практике вариант получается лишний.
Не лишний, см. ниже.
John Doe wrote: Tue 06 Nov, 2018 10:01
IgorZ wrote: Tue 06 Nov, 2018 06:59 Например, когда для части выделенных файлов требуется выполнить два действия (одно по команде, другое в функции), а для остальных - только одно. Скажем, мы выделили кучу текстовых файлов, из них надо выбрать данные, а часть из файлов ещё и заархивировать.
Или ещё проще: мы выделили кучу текстовых файлов, часть из них надо заархивировать, часть не трогать. Что, не тронутые так и должны оставаться выделенными?
Этот случай предусмотрен в спецификации, флаг SelectedAtOnce.
Как я понимаю, SelectedAtOnce означает "обработать все скопом". А файлы, в данном случае, необходимо упаковать каждый в свой архив, то есть, выполнять команду для каждого отдельно.
Кстати, приводя пример, упустил ещё одну деталь. Более приближённый к практике вариант: "Эта карточка закрыта, вес подсчитать, её упаковать и в архив; эта карточка ещё открыта, вес подсчитать, снять пометку; а вот в этой, похоже, ошибка, ничего не делать, пометку не снимать".
John Doe wrote: Tue 06 Nov, 2018 10:01
IgorZ wrote: Tue 06 Nov, 2018 06:59 Это тоже состояние.
Спецификация конечно же предварительная, и я специально не делал попыку что-либо из параметров объединять/группировать в Params.
Но да, это может быть что угодно, например и позиционные аргументы action(Params,State,Item,...), где флаги объединены в Params.
А вот конкретно в State я пожалуй не хотел бы их добавлять, потому что по замыслу этим состоянием должна управлять сама функция, и будет удобнее не иметь там ничего лишнего, например во избежание конфликтов.
Возможно, лучше назвать аргумент иначе.
Состоянием управляет сама функция. Но начальное-то состояние мы всё равно задаём. Просто часть состояния изменяется в процессе, а часть нет. Что же до конфликтов, так на то и придумано понятие "зарезервированные имена".

Идея: скрипты в метасимволах

Posted: Tue 06 Nov, 2018 12:14
by John Doe
IgorZ wrote: Tue 06 Nov, 2018 11:37Кстати, приводя пример, упустил ещё одну деталь. Более приближённый к практике вариант: "Эта карточка закрыта, вес подсчитать, её упаковать и в архив; эта карточка ещё открыта, вес подсчитать, снять пометку; а вот в этой, похоже, ошибка, ничего не делать, пометку не снимать".
Если принять такую задачу, то действительно может понадобиться отдельный сигнал.
Принципиальных возражений не имею, но будучи сторонником минимализма, предпочёл бы обойтись: (далее имхо, можно не отвечать)
IgorZ wrote: Tue 06 Nov, 2018 11:37Состоянием управляет сама функция. Но начальное-то состояние мы всё равно задаём. Просто часть состояния изменяется в процессе, а часть нет. Что же до конфликтов, так на то и придумано понятие "зарезервированные имена".
Я согласен, что можно объединить в одной таблице всё что угодно: и флаги, и "состояние", которым управляет функция, и не возражаю, если автор так и решит сделать.

Но всё равно хочу подчеркнуть: State в спецификации подразумевает независимый аргумент, который даже не обязан быть таблицей.
Его можно передавать как отдельной позицией, так и в таблице, в числе прочих (например Param.State).
Но я против того, чтобы объявлять состоянием всю таблицу Param, потому что получившийся микс не видится мне красивым решением (зачем эта возня с зарезервированными именами, если её можно избежать).

Идея: скрипты в метасимволах

Posted: Tue 06 Nov, 2018 12:44
by IgorZ
John Doe wrote: Tue 06 Nov, 2018 12:14 Принципиальных возражений не имею, но будучи сторонником минимализма, предпочёл бы обойтись.
Ну, тут вопрос, где проходит разумная граница между минимализмом и выбрасыванием заведомо нужного функционала, который всё равно, по моему мнению, придётся добавлять, если новый механизм окажется востребованным. Я считаю, что данный вариант возвращаемого результата всё равно окажется нужным, так что проще сразу его добавить, чем потом допиливать с риском что-то поломать (не у себя, так у какого-нибудь пользователя).
John Doe wrote: Tue 06 Nov, 2018 12:14
IgorZ wrote: Tue 06 Nov, 2018 11:37Состоянием управляет сама функция. Но начальное-то состояние мы всё равно задаём. Просто часть состояния изменяется в процессе, а часть нет. Что же до конфликтов, так на то и придумано понятие "зарезервированные имена".
Я согласен, что можно объединить в одной таблице всё что угодно: и флаги, и "состояние", которым управляет функция, и не возражаю, если автор так и решит сделать.

Но всё равно хочу подчеркнуть: State в спецификации подразумевает независимый аргумент, который даже не обязан быть таблицей.
Его можно передавать как отдельной позицией, так и в таблице, в числе прочих (например Param.State).
Но я против того, чтобы объявлять состоянием всю таблицу Param, потому что получившийся микс не видится мне красивым решением (зачем эта возня с зарезервированными именами, если её можно избежать).
Подумав, решил считать это непринципиальным вопросом. Возврат true - существенный момент, передача аргументов в виде таблицы - не столь существенный, но удобный для обработки пользователем. Остальное обсуждавшееся вполне допустимо и так, и этак.

Идея: скрипты в метасимволах

Posted: Tue 06 Nov, 2018 12:59
by John Doe
IgorZ wrote: Tue 06 Nov, 2018 12:44 Ну, тут вопрос, где проходит разумная граница между минимализмом и выбрасыванием заведомо нужного функционала, который всё равно, по моему мнению, придётся добавлять, если новый механизм окажется востребованным.
О разумноё границе.
Предлагаемая спецификация на самом деле далека от минимализма, и в частности многого требует от фара (что может оказаться не так просто).
В то же время, даже без половины удобств, обсуждаемая функциональность всё ещё весьма полезна.

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