| Цитата(Quadr0 @ 9.8.2005, 01:04) | | А это зачем? Подсветки не предназначены для xml редактора. Они предназначены для компонента SynUniHighlighter. Слышал о таком? |
| Цитата(Quadr0 @ 9.8.2005, 01:04) | | Зачем нам гнаться за этой XML совместимостью? Кому она нужна, и что она нам даст? |
| Цитата(Quadr0 @ 9.8.2005, 01:04) | | В файлах подсветки комментариев вроде нет (да и зачем они?). |
Может я как-то непонятно изъясняюсь... Сейчас попробую пояснить свою мысль...
Но сначала, ты должен уяснить одну идею. Компонентом пользуемся не только мы и не только те, кто появляется на этом и другом форуме, но и еще большое количество людей со своими личными предпочтениями.
Теперь ближе к делу. Совместимость с xml-ем нужна, так как:
1). есть люди, которые не пользуются дизайнером, а предпочитают предоставлять пользователям своей программы менять файлы подсветки вручную. Благодаря этому файл подсветки может произвольно разбиваться пробелами и табами, а также может содержать поясняющие комментарии, описывающие назначение правил или элементов файла... И вот поэтому мы должны уметь считывать такие файлы. С этим согласен?
2). допустим, кто-нибудь захочет использовать другой парсер для считывания файлов подсветки. Если формат подсветки будет несовместим со стандартами xml, то у него ничего не получится. Также нужно, чтобы xml-ка просматривалась во всех просмотрщиках и редакторах xml-я. Например, хотя бы в том же Internet Explorer.
| Цитата(Quadr0 @ 9.8.2005, 01:04) | | Я уже говорил. Подсветки имеют строгий формат. |
А я уже говорил, что этот формат не такой уж и строгий!
Уже есть ТРИ формата! И что для каждого формата свой парсер писать? Нерентабельно! 
Плюс учитывай, что в будущем формат файла также может поменяться (никто не застрахован).
| Цитата(Quadr0 @ 9.8.2005, 01:04) | | Более разумным было бы написать свой парсёр, заточенный только под файлы подсветки. Будет и скорость и отсутствие ненужного кода. |
- Скорость... А почему ты думаешь, что будет большое увеличение скорости? За счёт чего она может значительно увеличиться? Ведь принципы считывания будут те же самые.
- Отсутствие ненужного кода... Вот как раз если выделить самостоятельный парсер в виде отдельного файла - тогда и не будет нагромождения ненужного кода в файлах самого компонента!
Плюс Monty высказал интересную мысль: "например, я использую TMyXML ... а в вашем компоненте есть другой TVashXML ... так что делать? Смирится с +120кб или использовать ваш? Или же переписать компонент под свой TMyXML ...". Выделение парсера в отдельный независимый файл позволит более гладко переходить на другой xml-парсер (в случае необходимости).
| Цитата(Quadr0 @ 9.8.2005, 01:04) | | Может, юникода хватит? |
Кодировка Windows-1252 (или подобная) должна поддерживаться в любом случае. Так как именно эту кодировку используют старые файлы подсветки.
А на счёт юникода. Пока что в нём нет абсолютно никакой необходимости, так как наш парсер ("токенов") об юникоде ничего не знает. И официальный SynEdit тоже.
Вот когда будет доделан UniSynEdit и когда (если) мы возьмёмся за добавление юникода в наш парсер, то можно будет и подсветки в юникоде хранить 
Но, в принципе, реализовать поддержку юникода можно уже и сейчас (единственно, что она будет востребована не на всю катушку). При чём UTF-8 тоже тогда был бы полезен.
|
