olegvsk
Спасибо большое за обнову! Пробежался по всем исправлениям — при беглом тесте всё работает исправно. Особенно порадовало исправление обработки UTF-16 — у меня файл 130 Мб плагин (на 32 битах) открыл за 4 сек, и перемещение/поиск/подсветка найденного в нём работают без лагов (чуть только при перемещении, но малоощутимо, но и размер-то файла немаленький). Также, добавки в редакторе темы сейчас позволяют шустрее заниматься настройкой, так что можно теперь сосредоточиться на экспериментах с детальными раскрасками.
Несколько наблюдений. Думал как их лучше расположить, и решил в порядке чрезвычайности ))
Применение VCL к меню ПКМ смотрится прекрасно, но с ними неожиданно приключился «ой». Дело в том, что помимо плагина они «хакнулись» во всём Total Commander и во всех других плагинах
До инициализации CodeViewer они одни, а после — к ним ко всем применяется VCL. Но это бы ладно, а есть и одно неприятное последствие: «отключается» отображение пунктов в тулбарах, подключенных как меню. Видимо, Гислер там что-то намудрил, а наши нововведения его перемудрили. Причём оказалось, что плагин PE Viewer (последняя beta, выложенная здесь на форуме, в соседней ветке) использует такой же или родственный способ для отображения своих ПКМ-меню — ну, и они, соответственно, тоже «отключились». Чтобы много не писать, вот скриншоты, на них всё, кажется, очевидно. Я специально включил ForceDarkModeOptions=2 для наглядности.
Я прошу прощения, что своими дилетантскими хотелками вверг Вас в эту историю. Но с другой стороны, не косячит тот, кто ничего не делает. Если получится ограничить область действия VCL-ПКМ-меню только плагином, то очень хорошо. Если нет, то есть ForceDarkModeOptions=1.
В редакторе темы теперь отредактированные ключи выделяются наклонным шрифтом — это хорошо. Быть может было бы последовательным выделять наклонным также и категорию, в которой располагаются это отредактированные ключи? Чтобы когда все категории свёрнуты, видеть те, где произведены изменения. На скриншоте ниже я проиллюстрировал.
В редакторе темы новая кнопка «Удалить тему» располагается на одной плашке с назначением темы хайлатеру. Понятно что тут двойная ф-ция: и назначение, и выбор темы для редактирования. Но наглядность у них равная. У меня при 1м взгляде на данную кнопку возникла чёткая ассоциация, что это сброс назначения темы, а не удаление самого файла темы. Только пощёлкав, разобрался что к чему. Быть может стоит немного перекомпоновать кнопки для пущей очевидности? Например, всё что касается управления файлом темы внизу, а назначение/выбор отдельно, как то так:
Логика активности кнопки Delete при этом могла бы сохраниться: при выбранной теме в верхнем списке активна, при <пусто> — не активна.
Подсветка фолдинга стала работать адекватней. Но в целом с фолдингом пока не всё ясно. В скриптах AutoIt я заметил, что если условие If...Then располагается в одну строчку, то фолдинг не воспринимает конструкцию как завершённую, а всё равно ищет EndIf. Кроме того фолдинг срабатывает если строка закомментирована, что не есть верно. Но возможно здесь надо внимательно изучать хайлайтер и искать причину в нём. Я пока туда не лазил. Но на всякий случай скриншот:
И последнее (на сегодня). Поскольку сейчас в плагине спокойно открываются файлы > 100 Мб, и основные необходимые при просмотре ф-ции в них работоспособны (подсветка, перемещение, поиск), я у себя отредактировал детект-строку, повысив порог фильтрации. Однако теперь надо следить, что при открытом файле-за-100 случайно не нажать/не вызвать WRAP, потому как если «ой», тогда только kill process. В связи с этим озарила мысль: а можно ли в плагине сделать доп. фильтрацию на WRAP? Т.е. чтобы выше определённого размера она просто блокировалась? Тогда бы стала доступна след. схема: в ДС прописано ограничение 150 Мб (к примеру), а в плагине 10 Мб (к примеру) для активации WRAP. Это могло бы стать переключателем к существующей опции про WRAP: либо «Open without word wrap», либо «Word wrap only in files less then ___ ».
[/cut]
.
Приходится постоянно работать и с такими, и с такими. Добро, как получится.
