По дизайнеру (1.8)
- В редакторе списков слов (Keywords) - зачем кнопка "Spaces to EOL". т.е. зачем нужна такая функция?
- В редакторе диапазонов (Range) - зачем чекбоксы ¶ ?
- дополнительные опции для Range (которые в менюшке в кнопке справа от поля ввода тега) - "Open tag is first (non-space) symbols on line" стоит заменить на "Open tag must be a first (non-space) symbols in line"? не заметил эффекта опций вида "Open tag is part of term"
- SynUniDesignerForm>TfmDesigner.TotalUpdate 

зачем SynUniSyn.MainRules.Reset, если предыдущая строка делает тоже самое?
зачем переключение хайлайтера у SampleMemo? чтобы SynEdit пробежался по тексту и обновил Range для каждой строки? 
зачем запоминание/восстановление SelStart\End? вроде бы нигде между ними выделение не сбрасываецца...

По подсветкам (тем, что идут вместе с бетой4):
- С++ source: зачем список слов "Number '0'" ?
- Delphi: зачем в Remarks (которые {}) дочерний set "Numbers"? зачем в Remarks (которые //) дочерний set "Russian symbols"?

По компоненту:
- зачем в дистрибе SynEdit.inc? потому что он юзаецца в SynUniHighlighter.inc? так правильнее будет юзать SynEdit'овский SynEdit.inc т.к. юзер (я например ) мог его изменить. и за что отвечают опции из SynUniHighlighter.inc?
- SynUniHighlighter.pas>TSynUniSyn.GetIdentChars

т.е. IdentChars SynEdit'a зависят от текущего range. представим себе такую ситуацию: в каком-то месте моего кода есть вызов TSynEdit.GetHighlighterAttriAtRowCol, в результате меняется CurrRange и косвенно IdentChars. где-то дальше в этом-же коде (т.е SynEdit не перерисовывался и CurrRange не менялся) вызываецца TSynEdit.GetWordAtRowCol (или что-нибудь другое, использующее IdentChars). в результате будут использовацца не те IdentChars, ведь позиция, для которой вызван GetWordAtRowCol может не попадать в CurrRange. 
немного путанно, но думаю понятно. по-моему лучше будет сделать вот так:


- SynUniRules.pas>TSynSet - поле BreakType: TBreakType используецца только в одном месте в коде, притом для чтения (SynUniRules.pas>TParser.GetToken) (а учитывая что оно не инициализируецца, лежать там будет скорей всего TBreakType(0), но не факт). поле StartType: TStartType вообще нигде не используецца. пережитки прошлого? 
- куча хинтов и варнингов при компиляции - что не есть тру. 
- общий дизайн классов - непонятно по какому принципу поля и методы разделены на public, private, protected etc; кое-где чтение/запись полей организовано через свойства, но в большинстве своём поля просто объявлены как public. всё это не критично, но некрасиво.
- стринги не передаюцца в процедуры как const
- почему для хранения объектов используюцца TList, а не TObjectList?
- SynUniClasses.pas>TSynScheme.GetStyleName - стоит переименовать в GetStyleByName ? 
- SynUniFormatNativeXml20.pas

точно, не нужно, лучше в VarToBool передавать Default=false
- SynUniHighlighter.pas>TSynUniSyn.GetDefaultAttribute

во-первых имхо правильнее будет возвращать не Attributes а ValidAttribs. во-вторых надо бы вообще пересмотреть этот метод. объясняю: на SYN_ATTR_IDENTIFIER и SYN_ATTR_KEYWORD можно забить - они нигде не юзаюцца кроме стандартных хайлайтеров (ну, вообще-то они могут юзацца каким-нить сторонним кодом, думающим что использцецца обычный хайлайтер...). а вот с остальными сложнее:
SYN_ATTR_COMMENT юзаецца SynEdit'ом при отрисовке - если последний токен в строке имел атрибут=Highlighter.CommentAtribute, то он (атрибут) будет использовацца для отрисовки 1. SynLineBreakGlyph в конце строки если включена опция eoShowSpecChars; 2. для отрисовки текста в конце строки, который не был пропарсен хайлайтером (if fHighlighter.GetTokenPos < Length(sLine) then) (а такое возможно?). если же атрибут<>Highlighter.CommentAtribute то для этих целей будет юзацца Highlighter.WhitespaceAttribute; 
также SYN_ATTR_COMMENT юзаецца в GetMatchingBracketEx - для того чтобы не искать скобки в комментариях (и строках - см. ниже)
SYN_ATTR_STRING юзаецца только в GetMatchingBracketEx для того же, что и SYN_ATTR_COMMENT
SYN_ATTR_WHITESPACE юзаецца при отрисовке для получения цвета фона, если цвет фона текущего токена =clNone. также юзаецца в SynEditExport.pas для получения цвета фона.

отсюда вывод: т.к. сейчас в юнихайлайтере нет механизма определения чем являецца текущий токен - строкой, комментарием или зелёным чёртиком , то на SYN_ATTR_COMMENT и SYN_ATTR_STRING лучше отвечать nil. на SYN_ATTR_WHITESPACE по-моему лучше всего отвечать отдельно созданным атрибутом, содержащим текущие цвета SynEdit'a, но можно и MainRules.ValidAttribs

- метод SynUniClasses.pas>TSynAttributes.Create написан так, что AName не учитываецца. нехорошо... я добрый час мучался пока понял какого ... текст не раскрашиваецца. имхо если в конструктор передаёцца имя, оно должно учитывацца, если нет - то и конструктор такой надо убрать.


- нелохо бы чтобы все исключения, генерируемые компонентом, были наследниками какого-нибудь уникального класса, например ESynUniException=class(Exception). тогда в try except end можно было бы определить кем сгенерировано исключение: компонентом, парсером, vcl'ом или ещё кем.


предложение по стилям:
1. каждый TSynRule должен иметь доступ к ActiveScheme (что бы в любой момент получить из неё атрибуты своего стиля)
2. и иметь свойства UseParent(ForeColor|BackColor|FontStyle) - сигнализируют о том что надо использовать родительские цвета\стиль шрифта
UseStyle(ForeColor|BackColor|FontStyle) - использовать цвета\стиль шрифта из стиля
3. в GetValidAttrs на основании этих свойств генерировать актуальные цвета и стиль шрифта (кстати, может переименовать GetValidAttrs в GetActualAttrs?) (для этого и нужен доступ к ActiveScheme)
4. в TSynUniHighlighter.SetActiveScheme не менять Attributes у правил - Attributes должно хранить те атрибуты, которые переопределил юзер, а решение о том, какие использовать (из стиля, родительские, пользовательские) принимаецца в GetValidAttrs.
5. каждый стиль должен иметь флаги IsComment, IsString (можно ещё придумать) - появицца механизм распознавания комментариев, строк и зелёных чёртиков 
в результате имеем: юзер может выбрать для правила стиль, может перекрыть любые его параметры своими (изменить Attributes и установить UseStyle(ForeColor|BackColor|FontStyle) в false), может указать что например, цвета используюцца родительские, а стиль шрифта из стиля и т.д.
именно так я скорее всего и сделаю в своём проекте, вопрос в том - будет ли это моя ветка развития юнихайлайтера, или это будет в официальном дистрибе. для меня естественно предпочтительнее второе. я готов заняцца этим если мантайнеры дадут добро.


ну вроде всё пока, пойду дальше ковыряцца 
с нетерпением жду ответа

to Vitalik: как у вас там с инетом в общаге, скоро предвидицца?

Поддерживаю.
По поводу всего остального - нужно сделать чтобы эти усложнения и схемы были очевидны для пользователя. Ведь именно из-за простоты написания своей подсветки компонент так популярен. 
Лично мое мнение по поводу следующих версий: схемы не так важны, как правила с использованием RegEx =)

Это сообщение отредактировал(а) Sep. - 26.8.2006, 09:54

хм, а так ли нужны регэкспы? я так понимаю они будут использовацца в TSynRange для поиска начала\конца range'a?
по моему в большинстве случаев для одного range'a достаточно двух-трёх варинатов, а это реализуемо уже сейчас через CoupleTags (не уверен что правильно написал, что-то похожее). но в общем я не против регэкспов

и как я уже написал, если Виталик даст добро, изменением логики стилей могу заняцца я, пока он будет занимацца регэкспами 

лично я его использую не из-за простоты а из-за отсутствия аналогов

Seldon, спасибо за проведенное исследование, но сообщение получилось просто огромнейшее... 

И как модератор я вынужден сказать следующее:

!  Vitalik

Один вопрос (или группа схожих вопросов) - одна тема! Не стоит в одной теме объединять сразу много абсолютно не связанных ветвей разговора.. Это и модерировать не удобно, и следить за нитью разговора, и в последующем искать нужные мнения в этой теме тоже сложнее..

Так что на часть вопросов я все таки отвечу в тех темах-"сателлитах", которые были созданы прежде этой темы:


Ответ в теме "Вопросы по компоненту (дизайнер, подсветки)".


Ответ в теме "Вопрос по .inc файлам".

Сразу извиняюсь за то, что не удается отыскать время на ответ в этой столь нужной и необходимой теме.. 

Мы с Seldon'ом уже немного поговорили в асе (совсем немного) и договорились, что он попробует провести рефакторинг кода компонента.
Поэтому я прокоментирую соответствующие замечания:


Многие из этих варнингов оставлялись для напоминания о некоторых мыслях или идеях, которые нужно обдумать или реализовать...
Поэтому убирая хинты и варнинги, пожалуйста, помечай эти изменения 


Согласен.
Я думаю нужно создать отдельную тему и подробно обсудить в ней к какому дизайну классов стоит прийти.
Seldon, создашь соответствующую тему?


Абсолютно не возражаю против этих изменений 


И правда. Согласен. 
Но дело в том, что эту идеологию и технологию работы со стилями все равно нужно перепродумать и перепрограммировать.. (уже в который раз..) 


Согласен. Эти две строчки можно убрать, так как теперь ParentForeground по умолчанию и так присваивается False.


Сюда закралась жестокая оппечатка.. 
Нужно написать не так
inherited Create(Name);
а так:
inherited Create(AName);


Не возражаю. Это было бы очень интересно! 


P.S. По поводу остальных вопросов выскажусь позже (возможно перенесем их в отдельные темы) 

ok, но имхо лучше оставлять напоминания стандартным Add To-Do item {TODO : }
а изменения я помечу, т.к. всё-таки они затрагивают логику работы, а, как я понял, в компоненте хватает "хитрых" мест  про которые знают только разработчики...

создам тему с моим видением идеологии стилей

!  Vitalik

Для обсуждения вопросов, связанных со стилями и дизайном классов, созданы соответствующие темы:

Тема: "Идеология стилей" (обсуждение реализации стилей)


Тема: "Дизайн классов" (обсуждение внутреннего дизайна классов)

Согласен 


Тоже верно..