На форуме выкладываются множество макросов. Некоторые идут целыми пакетами.
Очевидно что не все макросы могут быть нужны пользователю, а значит они напрасно занимают клавиши.
Или макросы хочется использовать с другими сочетаниями, а не с теми, которые определил автор.
Можно конечно просто отредактировать макросы, но при каждом обновлении процедуру придётся повторить.
Ниже предлагается простое централизованное решение, позволяющее отключить любой сторонний макрос, или переопределить его клавиатурную комбинацию.
Прототип обсуждался ранее, а теперь всё это можно делать интерактивно, с помощью одного из двух альтернативных макро браузеров:
Del — запретить/разрешить макрос. Запрещённый макрос отображается серым.
ShiftF4 — (пере)назначить сочетание клавиш.
В диалоге можно указать несколько клавиш или регэксп. Пустая строка отменяет переназначение.
После этого все макросы перезагружаются, чтобы изменения вступили в силу.
Переназначенные макросы индицируются звёздочкой перед клавишей.
к перечисленным выше комбинациям клавиш также расширяется дополнительное меню фильтров Misc,
добавляются такие пункты:
rebinded — макросы с переназначенными клавишами
disabled — запрещённые макросы
(db) — макросы, настройки которых прочитаны из базы
(file) — макросы, настройки которых прочитаны из файла bindings
rebindable — макросы, которые возможно переназначить
no id — макросы без идентификатора
Все настройки (состояние запрета и переназначенные клавиши) сохраняются в базе, и загружаются при запуске фара.
Также поддерживается альтернативный способ хранения настроек, в файле %FARPROFILE%\Macros\scripts\bindings.
В MacroBrowser alt для этого служит комбинация CtrlShiftF4, открывающая редактор, и вставляющая шаблон для настройки текущего макроса.
Для макросов, переназначенных таким образом, клавиши Del и ShiftF4 действуют иначе: открывают файл настроек в нужном месте.
Формат файла настроек не описываю, т.к. всё должно быть понятно при вставке шаблона по CtrlShiftF4.
Пример получившегося файла:
Всё что требуется для работы перечисленных функций — это подключить в _macroinit.lua модуль rebind: require"rebind".
На практике полезно дополнительно настроить модуль:
local rebind = require"rebind"
if type(rebind)=="table" then
rebind.Setup {auto_uids=true,no_warnings=true} -- опционально: разрешаем автоназначение идентификаторов, без вывода ошибок
rebind.LoadBindings() -- опционально: загружаем настройки из файла "bindings"
end
Об идентификаторах макросов:
В идеале в определение каждого макроса следует добавить поле id с уникальным идентификатором.
Или разрешить автоматическую их генерацию (auto_uids=true) на основе имени файла и описания макроса.
При загрузке макросов возможна ситуация, когда id получается неуникальным.
В этом случае тут же будет предложено его исправить.
Можно отключить предупреждения (no_warnings=true), проблем не будет, но некоторые макросы невозможно будет переназначить.
Требования: Far 3.0 build >4743 (luamacro build 580)
John Doe wrote:Собственно, будущая версия rebind уже хранит свои данные иначе, и в общем-то нет препятствий использовать поле с любым именем.
Поэтому просьба всех заинтересованных высказаться, стоит ли uid переименовывать в guid
На мой взгляд, в целях совместимости лучше оставить старое название. Или, как минимум, предусмотреть возможность принимать и uid, и guid. Но оставить, как есть, проще и надёжнее. Разве что кто-то сумеет аргументированно доказать, что сохранение существующего названия вызывает объективные проблемы.
Заодно напомню про пожелание использования uid/guid и для Event. Надеюсь, это будет в новой версии?
Кстати, идея на рассмотрение: можно вообще варьировать имя в зависимости от типа скрипта: uid(Macro, уже есть)/euid(Event, надеюсь, будет)/guid(MenuItem, есть изначально)/puid(CommandLine, если будет реализовано - впрочем, необязательно и даже, возможно, вредно, там сам префикс должен быть уникален).
IgorZ wrote: предусмотреть возможность принимать и uid, и guid.
..как промежуточный этап в процессе (потенциального) перехода.
Если по сути, то имя "uid" точнее соответствует особенностям текущей реализации.
Сейчас это произвольный "уникальный идентификатор", абсолютно любой, может быть в формате гуида, а может быть просто любой строкой, единственное требование к которой — уникальность.
Сделано это в основном для автогенерации условно-постоянных идентификаторов, позволяющих начать пользоваться всей функциональностью rebind сразу.
В противном случае требовалась бы ручная правка всех пользовательских макросов. Вроде бы однократная операция, но надо ведь учитывать что часть макросов не совсем принадлежат пользователю, т.к. скачаны с форума, где их поддержкой занимаются авторы, не заботящиеся о функционировании какого-то там rebind, а значит с каждой новой версией пришлось бы проставлять гуиды заново, что (помимо очевидных неудобств) нарушило бы неизменность идентификаторов.
Однако это всё пользователю малоинтересно, а лишние сущности только запутывают дело, поэтому мне понятна позиция Smitis.
IgorZ wrote: варьировать имя в зависимости от типа скрипта:
Это был бы ад)
IgorZ wrote: Разве что кто-то сумеет аргументированно доказать, что сохранение существующего названия вызывает объективные проблемы.
Объективных проблем нет, но субъективные тоже не стоит игнорировать.
Может быть выскажется ещё кто-нибудь из заинтересованных.
John Doe wrote:Если по сути, то имя "uid" точнее соответствует особенностям текущей реализации.
Сейчас это произвольный "уникальный идентификатор", абсолютно любой, может быть в формате гуида, а может быть просто любой строкой, единственное требование к которой — уникальность.
Сделано это в основном для автогенерации условно-постоянных идентификаторов, позволяющих начать пользоваться всей функциональностью rebind сразу.
В противном случае требовалась бы ручная правка всех пользовательских макросов. Вроде бы однократная операция, но надо ведь учитывать что часть макросов не совсем принадлежат пользователю, т.к. скачаны с форума, где их поддержкой занимаются авторы, не заботящиеся о функционировании какого-то там rebind, а значит с каждой новой версией пришлось бы проставлять гуиды заново, что (помимо очевидных неудобств) нарушило бы неизменность идентификаторов.
Однако это всё пользователю малоинтересно, а лишние сущности только запутывают дело, поэтому мне понятна позиция Smitis.
Мой личный опыт утверждает, что если сущности разные, то имена у них тоже лучше делать разными. Так что, на мой взгляд, под спойлером находятся аж два достаточных обоснования оставления имени "uid". Причём, первое отпадёт только если Shmuel сделает поле "guid" обязательным для макросов.
John Doe wrote:
IgorZ wrote: варьировать имя в зависимости от типа скрипта:
Это был бы ад)
Возможно. Не все спонтанные идеи оказываются гениальны. (здесь не помешал бы смайлик с Наполеоном)
John Doe wrote:
IgorZ wrote: Разве что кто-то сумеет аргументированно доказать, что сохранение существующего названия вызывает объективные проблемы.
Объективных проблем нет, но субъективные тоже не стоит игнорировать.
Субъективные по самому определению сугубо индивидуальны. Поэтому их стоит принимать в расчёт только если подавляющее большинство высказывается одинаково. Здесь, к сожалению, пока маловато людей поделились своим взглядом на вопрос.
John Doe wrote:Кроме того обдумываю не будет ли полезно разрешить переназначать не только клавиши, но и приоритеты, описания [, ...?]
Не будет ли это фактически параллельной базой макросов? Возможно, в качестве компромисса имеет смысл подумать о переназначении только тех полей, которые не влияют на идентификацию макроса? Скажем, приоритет разрешить менять, а описание - нет.
John Doe wrote:И ещё одна мысль: изменять произвольные параметры
Сейчас многие выкладываемые скрипты содержат установки в начале файла. Например:
Мысль богатая, но возникает ряд вопросов. Скажем, в новой версии скрипта автор изменил тип переменной - со строки на таблицу. Или просто изменил формат строки. Как быть? Ситуация-то потенциально проблемная... Думаю, стоит заранее хорошенько подумать над возможными подводными камнями и путями их преодоления. Может, как вариант, хранить хэш-код файла скрипта и при его изменении выводить предупреждение?
IgorZ wrote: если Shmuel сделает поле "guid" обязательным для макросов.
Вот обязательным не стоит.
Достаточно просто поддержать его "из коробки", т.е. хранить в таблице макросов, проверять уникальность, может ещё что-то.
IgorZ wrote: Скажем, приоритет разрешить менять, а описание - нет.
Мне лично изменение описания не нужно, но я знаю что есть пользователи, которые действительно правят описания для своих целей.
IgorZ wrote: Скажем, в новой версии скрипта автор изменил тип переменной - со строки на таблицу.
Такой ситуации не будет, поскольку предлагаемая функция будет работать только с теми параметрами, которые предусмотрел автор скрипта явно.
Применительно к примеру под спойлером, чтобы rebind мог повлиять на параметр width, должна быть такая запись:
Идея с предупреждением или тем более с luamacro.ini мне не нравится (сложно). Фар не выдаёт предупреждений в случае двух плагинов с одинаковым гуидом и не предусматривает конфигурирование этой ситуации.
Могу сделать следующее: добавить опциональное поле uid (д. быть валидный GUID), а в случае совпадения с гуидом уже загруженного макроса/обработчика события - оставлять это поле пустым.
John Doe wrote: Вот обязательным не стоит.
Достаточно просто поддержать его "из коробки", т.е. хранить в таблице макросов, проверять уникальность, может ещё что-то.
Как разработчик, я предпочёл бы обязательное указание guid. Очень облегчило бы жизнь.
John Doe wrote: предлагаемая функция будет работать только с теми параметрами, которые предусмотрел автор скрипта явно.
На мой взгляд, если уж делать, то с возможностью заменять значение любой статической переменной. После загрузки содержимого файла это вполне реально. Иначе же теряется самый смак - текст скрипта всё равно должен быть предварительно правлен автором или пользователем. Причём, в случае правки автором лучше сделать ещё один шаг и начать хранить значение в БД.
John Doe wrote: Выдавать предупреждение, в котором будет предлагаться исправить/оставить/пропустить макрос.
При выборе "оставить" макрос заносится, но без поля guid.
Или же управлять этим поведением через luamacro.ini
Я бы добавил ещё один возможный вариант действий: сгенерировать uid по шаблону, наподобие того, как это делается сейчас из имени файла и описания, и дописать в исходный файл в определение макроса. Естественно, либо с согласия пользователя и под его контролем, либо если он явно укажет такой способ действия как умолчательный и не требующий подтверждения. Ну и сохранять старую версию файла с расширением ".bak".
Last edited by IgorZ on Thu 01 Jan, 1970 01:00, edited 0 times in total.
Reason:Удалён оверквотинг
IgorZ wrote: Как разработчик, я предпочёл бы обязательное указание guid. Очень облегчило бы жизнь.
Пользователи не оценят.
IgorZ wrote: На мой взгляд, если уж делать, то с возможностью заменять значение любой статической переменной. После загрузки содержимого файла это вполне реально.
После загрузки уже поздно.
Да и использования debug-функций очень хочется избежать.
IgorZ wrote: сгенерировать uid по шаблону, наподобие того, как это делается сейчас из имени файла и описания
Это не есть хорошо.
Но в rebind мы можем продолжать это делать, во всяком случае пока uid/guid как стандартное поле не будет принят большинством авторов.
IgorZ wrote: дописать в исходный файл в определение макроса.
luamacro не трогает макрофайлы, и не вижу причин для чего бы ему начинать.
Но это можно делать прямо в луа менеджере.
John Doe wrote: Мне кажется нет необходимости проверять на валидность гуида.
Идея гуидов в их уникальности, и широко используется в Фар. Но с другой стороны, если поле опциональное, то-есть допустимо вообще это не указывать, то можно разрешить любой стринг (и тогда, вероятно, сравнивать их case insensitive).
1. Возможность использовать в качестве идентификатора произвольную строку, с осмысленным названием.
Макрос ведь не бинарник, поэтому особая строгость и не нужна, имхо.
2. Возможность использовать "условно-постоянные" сгенерированные идентификаторы, на время пока (г)уиды не будут приняты большинством авторов Update хотя при желании гуид можно сделать и из хэша строки..