Page 1 of 2

Развитие экспорта/импорта

Posted: Thu 14 Feb, 2019 08:21
by ccaid
Экспорт/импорт настроек Far позволяют работать с человеко-понятным вариантом настроек: просмотривать, сравнивать несколько вариантов, редактировать. Но есть исключение: Lua-плагины хранят свои настройки в виде Lua-кода, закодированного в hex-строку. Из коробки — это настройки для MacroBrowser. hex-строка непригодна для _непосредственной_ работы с ней. это примерно, как если бы бинарные базы преобразовывались не в xml, а в hex-дамп: формально текст, но что с этим делать? — ничего. паллиатив есть: написать скрипт, который декодирует заданную hex-строку — собственно, я так и сделал, когда мне было нужно посмотреть, в чем отличие двух вариантов настроек плагина.
но было бы удобно и полезно, чтобы штатные экспорт/импорт расширили свои возможности по доведению настроек до человеко-понятного вида и обратно.
а еще очень длинные hex-строки не перевариваются colorer'ом, и он начинает раскрашивать несуществующие ошибки.

Развитие экспорта/импорта

Posted: Thu 14 Feb, 2019 10:04
by 2useven10

Развитие экспорта/импорта

Posted: Thu 14 Feb, 2019 11:18
by DrKnS
ccaid wrote: Thu 14 Feb, 2019 08:21Lua-плагины хранят свои настройки в виде Lua-кода, закодированного в hex-строку
А причем здесь фар и импорт/экспорт?
Luamacro пожелал хранить данные в db виде opaque блобов - фар так и делает, понятия не имея, что там внутри.
Если хранить как строки - будет читаемо.

Развитие экспорта/импорта

Posted: Thu 14 Feb, 2019 12:13
by Shmuel
В LuaMacro это касается функций mf.msave и mf.mload. Там надо просто заменить FST_DATA на FST_STRING.
Но, скорее всего, после данного изменения, сохранённые прежде данные не загрузятся.

Развитие экспорта/импорта

Posted: Thu 14 Feb, 2019 12:38
by ccaid
2useven10 wrote: Thu 14 Feb, 2019 10:04 Редактор БД плагинов ?
еще больший паллиатив, со своими заморочками. вместо того, чтобы одной командой сохранить все, там надо выковыривать изюм. но ладно, экспортировал, и что я вижу: вместо одной длинной hex-строки используется одна длинная текстовая строка с \n вместо перевода строки. лучше уж я своим скриптом, если будет очень надо. а еще, если какой-либо плагин не загружен, то и к его настройкам доступа нет.
или вот. сохранил я текущие настройки, и желаю сравнить их со своим Default.farconfig, например, чтобы выявить новых кандидатов в дефолт. и как поможет DBEdit доступиться к настройкам в Default.farconfig?

Развитие экспорта/импорта

Posted: Thu 14 Feb, 2019 12:46
by ccaid
DrKnS wrote: Thu 14 Feb, 2019 11:18 А причем здесь фар и импорт/экспорт?
исключительно добрая воля фара, поэтому виш, а не претензия. потому как цель экспорта/импорта предоставить доступ к человеко-понятному варианту настроек, и если она достигается не в полной мере, то есть есть куда улучшаться.

Развитие экспорта/импорта

Posted: Thu 14 Feb, 2019 12:49
by HaRT
Shmuel wrote: Thu 14 Feb, 2019 12:13 надо просто заменить FST_DATA на FST_STRING.
Но, скорее всего, после данного изменения, сохранённые прежде данные не загрузятся.
Есть ли техническая возможность при считывании узнать, с каким из двух типов сохранено значение? Если есть, то можно было бы писать только строкой, а читать и строку, и блоб (для перехода с прежних версий).

Развитие экспорта/импорта

Posted: Thu 14 Feb, 2019 14:12
by Shmuel
HaRT wrote: Thu 14 Feb, 2019 12:49 Есть ли техническая возможность при считывании узнать, с каким из двух типов сохранено значение?
Возможность есть.

Развитие экспорта/импорта

Posted: Fri 15 Feb, 2019 09:15
by ccaid
Shmuel wrote: Thu 14 Feb, 2019 12:13 В LuaMacro это касается функций mf.msave и mf.mload.
как я понимаю, в остальных плагинах останется прежнее поведение.
по-хорошему, решать бы в одном месте: в экспорте/импорте фара.

Развитие экспорта/импорта

Posted: Fri 15 Feb, 2019 09:41
by 2useven10
ccaid, В 'классических' плагинах и так всё читаемо. Разве нет?

Развитие экспорта/импорта

Posted: Fri 15 Feb, 2019 10:02
by Shmuel
2useven10 wrote: Fri 15 Feb, 2019 09:41 В 'классических' плагинах и так всё читаемо. Разве нет?
Здесь, видимо, противопоставляются LuaFAR-плагины и "классические"?
Это некорректный подход, поскольку в LuaFAR есть всё необходимое для сохранения данных в "классическом" виде.
Поэтому речь здесь может идти только о конкретных LuaFAR-плагинах, авторы которых избрали "неклассический" (но более удобный) способ сохранения.

Развитие экспорта/импорта

Posted: Fri 15 Feb, 2019 10:10
by 2useven10
Shmuel, Я не спорю...
Основное в моём посте 'и так всё читаемо'.
У меня сложилось впечатление, что ccaid считает, будто ВСЕ плагины сохраняют настройки "неклассически".

Развитие экспорта/импорта

Posted: Fri 15 Feb, 2019 10:16
by Shmuel
Пример LuaFAR-плагина, сохраняющего данные в "классическом" виде - FastFind Enhanced.

ccaid, как мне кажется, не полностью видит картину, возлагая ответственность за читаемость на экспорт Фара.
Фар сохраняет данные в том виде, в котором ему указывают плагины.

Развитие экспорта/импорта

Posted: Fri 15 Feb, 2019 10:34
by ccaid
ccaid wrote: Thu 14 Feb, 2019 08:21 Lua-плагины хранят свои настройки в виде Lua-кода
ccaid wrote: Fri 15 Feb, 2019 09:15 в остальных плагинах
то есть я имел ввиду остальные Lua-плагины, которые хранят строки кода в виде hex-строки.
Shmuel wrote: Fri 15 Feb, 2019 10:16 возлагая ответственность за читаемость на экспорт Фара
нет, я отдаю себе отчет, что это не недоработка фара. просто есть две альтернативы: исправить во всех Lua-плагинах (скриптах) — сначала убедив всех авторов (но старые версии станут несовместимыми). или доделать в одном месте — экспорте/импорте фара, функция которого как раз конвертация настроек в пригодный для человека вид. да, фар не знает, что хранят плагины в своих настройках, но если задаться целью, вопрос может быть решен — как определить, какие настройки нуждаются в дополнительном декодировании/кодировании.

Развитие экспорта/импорта

Posted: Fri 15 Feb, 2019 20:51
by zg
а что вообще за ересь здесь происходит? настройку можно сохранить в бинарном виде и там будет не обязательно строка, можно в виде строки. это разные вещи. и на уровне фара интерпретировать бинарные данные как строку — это какой-то бред.