Тестовая версия для работы с Coder 18.7 и выше. Сейчас вся обработка обычных правил и правил с регулярными выражениями происходит в одном цикле, что избавляет от проблемы наложения правил при горизонтальной прокрутке.
Добавлено: возможность использовать правила в "Quotes:" из "QuotesRE:". Требуется AkelPad 4.9.7 или выше.
Added: possibility to use rules in "Quotes:" from "QuotesRE:". Required AkelPad 4.9.7 or higher.
почему-то как блок подсвечивается вся строка. Ожидается подсветка только начального script и конечного, по аналогии, как это сделано в других тэгах, имеющих атрибуты.
Posted: Tue Oct 20, 2015 10:32 am
by YuS
VladSh wrote:почему-то как блок подсвечивается вся строка. Ожидается подсветка только начального script и конечного
Как бы это помягче сказать... Вы ведь не первый день с программированием имеете дело.
У меня так и подсвечивается:
Файл xml.coder из стандартного комплекта...
Posted: Tue Oct 20, 2015 10:44 am
by YuS
Instructor
в css.coder после перемещения секции "QuotesRE:", артефакт остался:
- в секции "Quotes:" присутствует шапка и правило со структурой от секции "QuotesRE:"
Так и должно быть?
Posted: Tue Oct 20, 2015 11:13 am
by Instructor
YuS wrote:Так и должно быть?
Да. Новые версии плагина и программы это позволяют.
Posted: Tue Oct 20, 2015 11:30 am
by VladSh
YuS
В новой версии плага заработало. Не обновлял, т.к. не знал как он будет работать с 4.9.6.
В body y Вас тоже атрибуты раскрашиваются, как например в div?
Posted: Tue Oct 20, 2015 11:59 am
by YuS
VladSh wrote:YuS
В body y Вас тоже атрибуты раскрашиваются, как например в div?
Нет, не подсвечивается. Но там в html.coder куча правил и надо разбирать их иерархию, чтобы определить почему захватывает не тем правилом, которым хотелось...
В принципе, ведь тег <body> ничем не отличается от других, т.е. надо просто составить четкую иерархию для всех правил, которые могут пересекаться.
Для примера:
если перелопатить Folds, т.е. выключить правило:
- а вот если их оба отключить, то уже будет работать новое правило с регуляркой, и всё будет подсвечиваться и выделяться именно блоком <body></body>
Правда, не совсем понял, почему указанная выше пара правил имеет больший приоритет, ведь они в списке находятся ниже, чем новое правило, но это уже вопрос к автору, видимо...
Posted: Tue Oct 20, 2015 3:22 pm
by Instructor
YuS
Нет нужды писать правило для body. Достаточно закомментировать имеющееся:
Instructor wrote:YuS
Нет нужды писать правило для body. Достаточно закомментировать имеющееся:
Тогда не будет блока, т.е. закрывающим будет, соответственно правилу, тег ">", а не "</body>...
Posted: Tue Oct 20, 2015 5:07 pm
by YuS
Instructor,
Тут ещё один интересный момент:
Если в том же файле html.coder, с работающим правилом для блока <body\s++.*?> </body>, добавить аналогичный блок для "table":
то ломается структура блока "body"...
Вот тут подготовленный комплект, надо только раскомментировать правило для "table". Выключение всех блоков, где присутствует </table>, не помогает...
Posted: Tue Oct 20, 2015 5:48 pm
by Instructor
YuS wrote:Тогда не будет блока, т.е. закрывающим будет, соответственно правилу, тег ">", а не "</body>...
Просто хотел отметить, что не следует усложнять там, где нет необходимости. Конструкции вида "<table\s*+.*?>" нужны только для "Rule file". И эксперименты со сложными html файлами (тем более, когда изначально структура битая, из-за использования "//--></script><noscript></noscript></td>") я бы ставил, когда понимал действие каждого правила.
Posted: Tue Oct 20, 2015 6:35 pm
by YuS
Instructor wrote:
YuS wrote:Тогда не будет блока, т.е. закрывающим будет, соответственно правилу, тег ">", а не "</body>...
Чего-о?
Сори, за косноязычие.
Имелось ввиду, что при отсутствующем правиле для body, с простым комментированием ";--Ignore tags--", получим "<single" and ">", вместо "<tag" and "</tag>"...
Ну, это, естественно, на приложенном сложном файле можно пронаблюдать.
И это же относится к вопросу:
Instructor wrote:И эксперименты со сложными html файлами (тем более, когда изначально структура битая, из-за использования "//--></script><noscript></noscript></td>") я бы ставил, когда понимал действие каждого правила.
Структуру не я побил Просто взял для примера dom-структуру данного форума, т.е. фактически, пример из жизни
А учитывая послабления в HTML5, где с тегами вообще может какая угодно чехарда случиться (т.к. многие закрывающие теги стали просто необязательны, как и вообще, в принципе, использование таких тегов как html, head, body...), при реальном использовании редактора на "живых" файлах, таких ситуаций может возникнуть масса...
Теги body и table, и правила с регэкспами были просто использованы для тестов, как раз для улучшения понимания процесса работы правил.
На простеньких, тестовых файлах, всё более-менее понятно работает, но вот когда DOM-структура запутана (что не редко присутствует в реальных файлах), то ошибки становятся неизбежны...
Posted: Tue Oct 20, 2015 8:29 pm
by Instructor
YuS wrote:... получим "<single" and ">", вместо "<tag" and "</tag>"...
Ну, это, естественно, на приложенном сложном файле можно пронаблюдать.
- а вот если их оба отключить, то уже будет работать новое правило с регуляркой, и всё будет подсвечиваться и выделяться именно блоком <body></body>
Видимо надо пояснить, что фолдинг теряет смысл, если есть, например, такая структура:
В данном случае нельзя увеличить приоритет <table></table>, до такой степени , чтобы он выровнял структру файла, необходимо просто закрыть тег <a>.
Начнем с того, что я ведь ни на чем не настаиваю, если нельзя, то нельзя... просто констатирую факт. Возможно, что учет всех подобных тонкостей равнозначно созданию подобия браузера, что противоречит концепции AP (быть маленьким и быстрым)...
А вот пример не совсем удачный, т.к. по стандарту у элемента "a" открывающий и закрывающий тег обязательны, это просто конкретная ошибка структуры (хотя и этот момент, вроде бы, редактор должен учитывать, хотя бы каким-нибудь предупреждающим сообщением, типа: нарушена структура, поэтому извини - фолдинга не будет совсем ). Весь вопрос в том, что допускается использовать и другие элементы, в которых открывающий или закрывающий теги, могут быть не обязательными. Например, "area" или "base", или тот же "body", у которого и начальный, и конечный теги вовсе не обязательны - как учесть такие моменты при разборе структуры? Ведь абсолютно все существующие элементы, атрибуты и их сочетания в правилах не опишешь...
В качестве конструктива: Может быть ввести какую-либо иерархию по RuleID (раз уж они уже есть), которая в зависимости от цифры, могла бы позволить при поиске закрывающего тега игнорировать все вложенные теги, либо наоборот при найденном открывающем теге совсем не пытаться искать закрывающий, либо в сочетании? Или как-то более строго учитывать... не знаю, я ведь не представляю всех сложностей в создании этого, поэтому могу только "генерировать идеи".
Posted: Wed Oct 21, 2015 4:10 pm
by Instructor
YuS
Сейчас возможности Coder'а стали существенно шире, подумаем.