Page 1 of 3
Файлы .coder : предложения по улучшению формата
Posted: Tue Jul 20, 2010 6:57 am
by DV
Самый первый, поверхностный, взгляд на файлы .coder выявляет следующее (на примере файла
cs.coder):
Code: Select all
;----------------------------------------------;
; AutoComplete ;
;----------------------------------------------;
;====================================
;Set variables for "Blocks:" section.
;
;VAR "VALUE"
;====================================
Variables:
INDENT " "
Что я хочу сказать: в файлах .coder
уже есть механизм поддержки внутренних переменных.
Соответственно, представляется разумным использовать этот же механизм для секции
HighLight, дабы не задавать цвет для каждого ключевого слова в отдельности, а использовать для этого внутренние переменные.
Например,
Code: Select all
;----------------------------------------------;
; HighLight ;
;----------------------------------------------;
Variables:
clr_delims #C048E0
clr_words1 #0000FF
clr_words2 #008080
...
Delimiters:
1 0 0 0 " "
1 0 0 0 " "
;1 0 clr_delims 0 =>
1 0 clr_delims 0 (
1 0 clr_delims 0 )
1 0 clr_delims 0 {
...
;Keywords
1 0 clr_words1 0 abstract
1 0 clr_words1 0 as
1 0 clr_words1 0 base
...
1 0 clr_words2 0 break
1 0 clr_words2 0 case
1 0 clr_words2 0 catch
...
Можно пойти ещё дальше, и задавать не только цвета, но и стиль полностью, например:
Code: Select all
;----------------------------------------------;
; HighLight ;
;----------------------------------------------;
Variables:
stl_delims "1 0 #C048E0 0"
stl_words1 "1 0 #0000FF 0"
stl_words2 "1 0 #008080 0"
Любой из этих подходов
на порядок упростил бы модификацию файлов подсветки.
Posted: Tue Jul 20, 2010 7:27 am
by se7h
когда редактируешь файлы подсветки, невольно возникают такие же мысли
двумя руками ЗА стили
более того, предлагаю хранить стили ОДНИМ ОТДЕЛЬНЫМ файлом, тогда редактирование и создание новых цветовых схем сразу для всех языков колоссально упрощается и любой сможет сделать свою схему без особого напряжения и поделиться ей с другими
Posted: Tue Jul 20, 2010 8:00 am
by Fr0sT
Уже высказывал это предложение когда-то.
Плюс, вот такая конструкция
Code: Select all
Words:
1 0 #3333CC 0 bool
1 0 #3333CC 0 char
1 0 #3333CC 0 wchar_t
1 0 #3333CC 0 void
прямо просится в такую
Code: Select all
Styles:
Keyword 1 0 #3333CC 0
Words:
Keyword bool char wchar_t void
Posted: Tue Jul 20, 2010 8:41 am
by VladSh
Согласен с коллегами
Но представлю свой вариант:
Code: Select all
Variables:
fnt_0 = 0
fnt_cn = Cоurier New
...
flg_0 = 0
flg_bi = 4
...
clr_0 = 0
clr_cyan = #0000FF
clr_sea = #008080
clr_red = #FF0000
...
Styles:
;==============================================
;Style Flag Font Color Color
;name style text bkgrnd
;==============================================
wrd_cmdbase = flg_0 fnt_0 clr_cyan clr_0
wrd_cmdadd = flg_0 fnt_0 clr_sea clr_0
...
Words:
;==================================
; Word Style
;==================================
abstract wrd_cmdbase
as wrd_cmdbase
...
break wrd_cmdadd
case wrd_cmdadd
...
Можно не затачиваться в наименованиях стилей на цвета, как например, clr_
cyan, можно оставить цифры, просто в комментах ставить описание, например:
clr_1 = #0000FF ;cyan
это даст большую динамику, т.е. каждый для себя прописав стили потом не будет их менять, и не будет постоянно менять файлы конфигурации...
Основные принципы:
1. Variables и Styles в отдельных файлах.
2. Формировать Styles на основе Variables.
3. Для каждого Word указывать ОДИН стиль, этого вполне достаточно.
4. Ключевые слова и команды в секции Words должны идти впереди и в алфавитном порядке.
- Впереди, т.к. при подсветке мы анализируем слова, т.е. нашли слово, проще в списке будет его найти и применить стиль; это будет работать быстрее всего, т.к. в списках значение вытягивается по указателю.
- По алфавиту - желательно для оптимизации, но если будут использоваться списки, то необязательно.
Умоляю! Сделайте переменные, в частности INDENT, где-нибудь в отдельном файле! После каждой смены формата запариваешься лазить и исправлять 2 пробела на символ табуляции. И ещё можно было бы брать разделитель из настроек, - это было само правильно. Например INDENT = $Settings брало бы разделитель из настроек.
Posted: Tue Jul 20, 2010 8:46 am
by VladSh
Fr0sT
Тогда так:
Code: Select all
Words:
wrd_cmdbase: bool, char, wchar_t, void
/мы уже это обсуждали - "оно" может состоять из 2-й слов/
Posted: Tue Jul 20, 2010 10:52 am
by Fr0sT
VladSh, а, точно, было. Ну да, разделитель уже сделать как удобнее, хоть ";", хоть "|".
И да, определения стилей, indent и прочего надо вынести в один общий файл. А то либо заколебаешься менять все подсветки, либо будут разношёрстные. В то же время, оставить возможность указать свои настройки для отдельного файла (если есть, они будут накатываться на общие). В таком случае, и время считывания файлов сократится намного, и редактировать удобнее будет.
Posted: Tue Jul 20, 2010 1:15 pm
by VladSh
Fr0sT wrote:разделитель уже сделать как удобнее, хоть ";", хоть "|".
Просто сейчас ";" - это комментарий.
Posted: Tue Jul 20, 2010 1:51 pm
by Fr0sT
Просто сейчас ";" - это комментарий.
Ну и что? Комментарий - когда он первым символом идёт, а если в середине строки - то очень даже разделитель
Posted: Tue Jul 20, 2010 2:36 pm
by se7h
Двоеточие логичней
Posted: Tue Jul 20, 2010 2:58 pm
by VladSh
Fr0sT wrote:Комментарий - когда он первым символом идёт, а если в середине строки - то очень даже разделитель
А когда я в конце строки коммент захотел поставить?
Лучше принять какой-нить стандартный, который лучше видно... например //.
Posted: Tue Jul 20, 2010 3:13 pm
by FeyFre
VladSh, se7h, Fr0sT, хватит придумывать новый язык. Если Вам так нужно расширить конфигурационность плагина, то просите Инструткора не доделывать синтаксис конфига, а использовать один из пригодных для этого интерпретируемых/скриптовых языков, которых Вам с головой хватит сразу, и на всегда. Гибкости уйма. И ни вы, ни Инструктор не будете больше гадать как бы лучше правило в конфиг внести, и сразу можно будет позаботится о функционале.
Posted: Tue Jul 20, 2010 3:32 pm
by se7h
FeyFre wrote:VladSh, se7h, Fr0sT, хватит придумывать новый язык. Если Вам так нужно расширить конфигурационность плагина, то просите Инструткора не доделывать синтаксис конфига, а использовать один из пригодных для этого интерпретируемых/скриптовых языков, которых Вам с головой хватит сразу, и на всегда. Гибкости уйма. И ни вы, ни Инструктор не будете больше гадать как бы лучше правило в конфиг внести, и сразу можно будет позаботится о функционале.
мы предлагаем доработать существующий, а Вы заново создать новый - чувствуете разницу?
Posted: Tue Jul 20, 2010 3:48 pm
by FeyFre
мы предлагаем доработать существующий, а Вы заново создать новый - чувствуете разницу?
Вы предлагаете переизобретать велосипед, а я предлагаю использовать изобретенный 20 лет назад(5,10,15,25,30,35,40 нужной подчеркнуть). Да, разницу я вижу, а Вы?
Posted: Tue Jul 20, 2010 4:00 pm
by se7h
FeyFre wrote:мы предлагаем доработать существующий, а Вы заново создать новый - чувствуете разницу?
Вы предлагаете переизобретать велосипед, а я предлагаю использовать изобретенный 20 лет назад(5,10,15,25,30,35,40 нужной подчеркнуть). Да, разницу я вижу, а Вы?
а что проще Александру, как Вы думаете??
Posted: Tue Jul 20, 2010 4:44 pm
by FeyFre
se7h
Не буду предполагать в принципе, ибо в принципе не лазил в исходники Coder-а, рылся только в AutoComplete и HighLight и то точно не в частях чтения конфигурации.
И тем не менее в SpellCheck-е я не занимался переизобретением велосипеда, а использовал готовый язык LUA для задания белых списков, что заняло у меня 10 минут в том числе скачивание исходников, подключения к постройке, дописывание одной вспомогательной функции(для того что-бы помирить Windows со стандартами C) и расширения языка на предметную область. Собственно реализация Scripts у Инструктора заняла не на много больше времени(если не учитывать капризы COM).
Вы предлагаете расширить конфигурацию одним путем, я - вторым. Чей лучше - по сути не важно. Главное - развитие функционала изза этого не притормозить.