Я было подумал, что всё-таки дело в этом
Leency писал(а):
3. Можно открыть файл после закачки в браузере и не парится с обработкой INI файла ассоциаций.
А что там париться-то?
Leency писал(а):
2. У @OPEN есть диалог "открыть с помощью" для неизвестных типов файлов.
Ну так есть
OpenDialog, типы же всё равно неизвестные.
Leency писал(а):
4. Больше свободного места в образе.
>> дополнительная программа
Ну, конечно, больше
Leency писал(а):
1. Да, @OPEN нужен, чтобы каждый ФМ не лисапедил свой лисапед по открытию файлов. Одна из причин.
В таком случае никто не мешает читать только один файл
assoc.ini. По факту это как раз @open налисопедили.
Leency писал(а):
в коде запускалки каждого ФМ
Ну берёшь просто и запускаешь, не? А ты просто написал так, будто там такой большой и сложный код.
Leency писал(а):
5. Лучше жизнь для тех, кто обновляет ассоциации, уменьшение вероятности ошибки как в INI разных ФМ, так и в коде запускалки каждого ФМ.
Leency писал(а):
Я так понимаю, тебя устраивает твой код запуска файлов и никто не заставляет переделывать запускалку FNav, но... если ты захочешь никто останавливать тоже не будет...

Я не случайно привёл содержимое файлов для сравнения.
Вряд ли пользователь станет разбираться с тем, как устроен
assoc.ini. А потому его вообще логичнее было сделать не текстовым, а бинарным.
Но если говорить конкретно обо мне, то, разумеется, меня устраивает мой вариант.
Я вообще стараюсь по возможности не использовать ничего
кривого, даже если оно уже вдруг попало в сборку(хотя сейчас это примочка Eolite-only, и вполне вероятно таковой и останется.).
Но, как не странно, этот вариант появился уже позже моего. А ведь можно было что-то из этого извлечь. Я вот потому как раз и привёл для сравнения.
Мой вариант отредактировать — элементарно(впрочем,
kfm.ini и
kfar.ini — тоже). А этот
assoc.ini — вообще не разберёшь, чего там нагородили. Потому, лучше его сделать бинарным, если уж так беспокоиться о свободном месте в образе.
Но я не в обиду автору @open, он ведь всё-таки старался, наверное.