Всем привет!

Мы планируем выложить новую версию компонента SynUniHighlighter 2.0 на этой неделе.
Если у нас не получится закончить в срок, то следующий релиз будет только аж в сентябре
Нужна ваша помощь в некоторых идеологических моментах...

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

1). Обобщённое название для открывающего и закрывающего "тегов" диапазона. Понятие "тег" включает в себя совокупность как строковых значений, так и значения некоторых свойств (таких как PartOfTerm - "часть слова", StartLine - "начинается с начала строки" и т.п.). Пока что соответствующий ему класс зовётся TSynSymbol и TSynMultiSymbol (из-за добавления мультитеговости). В файл раньше писался по отдельности, теперь же вынесен в отдельные теги OpenTag и CloseTag.
Но название "тег" для этого понятия немного не подходит, так как под "тегом" понимается нечто другое. "Symbol" или "Keyword" уже немного ближе, но тоже не очень стыкуется со смысловой нагрузкой. А "Word" - имхо, совсем не подходит...
Есть еще какие-нибудь идеи?

2). Обобщённое понятие пары откр. и закр. тегов. Нужно придумать хорошее словечко для них. Если не получится, то можно попробовать множественное число от пункта 1)., но это мне видится плохим решением...
Может что-то вроде "CoupleTags"... Но как-то по короче... И по правильней...

3). Обобщённое понятие мультитеговости, то есть множественности строковых значений для тегов (подробнее читайте здесь). Раньше звалось "MultiTags", возможно подойдёт просто как приставка Multi ко второму или первому пункту.

4). Название для откр. и закр. символов задающих CodeFolding.

5). Если нужно поменять название других составляющих подсветки, то пишите скорее сюда, так как после выхода версии 2.0 не хотелось бы снова серьёзно дорабатывать формат файла и менять название элементов дизайнера...

1. "Token" или лучше "RangeToken"
2. TwinRangeTokens
3. MultiRangeTokens или RangeMultiTokens
4. FoldingTokens, OpenFoldingToken, CloseFoldingToken
5. Вроде нет.

Годится?

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 00:57

Цитата(StayAtHome @ 3.8.2005, 19:58)

Годится?

Да! Очень симпатишная идея!
ИМХО, это самое оно. "Token", "PairTokens", "MultiTokens".
Если не найдём варианта еще лучше, то, наверное, будем юзать именно этот!

Может быть заодно решить проблему с KeyList (Keywords)? Обзовём его TokenList?
Ведь в нём на самом деле не только ключевые слова хранятся. В нём и список символов присутствует. А в скором времени и список регулярных выражений будет... Так что название KeyList, имхо, для него уже очень не подходит... устарело...

Цитата(Quadr0 @ 4.8.2005, 00:25)

Vitalik, а чем теущие неустраивают? И, кстати, менять их мы вроде не можем, они же ведь к SynEdit привязаны будут. Или я что-то не так понял?

Да, ты что-то не так понял.
Мы думаем над форматом файла и над интерфейсом дизайнера. То есть какие слова использовать в файле и естественно стараться такие же на форме дизайнера
Отностиельно нашего компонента, таким же образом потом можно и классы назвать.
Правда для выбора слов для CodeFolding нам, наверное, придётся быть более консервативными и не уходить далеко от названий классов/свойств в реализации этого самого CodeFolding'а

1. bracket, paranthesis;
LeftBracket, RightBracket

Цитата

2. TwinRangeTokens

а как вам TokenPair? или BracketPair?

Цитата(Sagara @ 4.8.2005, 11:26)

bracket, paranthesis

Дело в том, что открывающими и закрывающими символами для диапазонов ведь являются не только скобки... Даже наоборот скобки реже всего встречаются...

Но спасибо за вариант!

Скобки бывают круглые, квадратный, угловые... Bracket может быть использовано в абстрактном смысле. ну или в функциональном -- они определяют границы некотой "фразы" (в расширенном смысле этого слова).
Нужно название для класса объектов -- что-нть вроде AbstractBracket... но Bracket короче... и опять же сами по себе скобки и так бывают разные.

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 00:59

Цитата(Quadr0 @ 4.8.2005, 12:15)

Тогда, я думаю, эти названия нужно как-то с названиями диапазона синхронизировать.

Синхронизировать было бы, конечно, не плохо... Но всё же с CodeFolding там немножко по-другому...

Цитата(Quadr0 @ 4.8.2005, 12:15)

Т.е. FoldingTokens подойдут.

Ну... Там только пара отдельных "токенов", поэтому может тогда те теги в файле обозвать OpenToken и CloseToken? Обсуждение здесь.


Это сообщение отредактировал(а) Vitalik - 4.8.2005, 17:07

Итак, идея с "Tokens" мне очень понравилась! Она очень универсальна и очень хорошо отражает суть вещей!
Предлагаю следующим образом изменить названия внутренних классов для большей понятности и наглядности исходников.

• Был раньше такой универсальный класс TSynSymbol. Он использовался и как откр./закр. теги для диапазона, а также в списке токенов и в дереве токенов. Но с появлением многотеговости это уже можно разбить на три отдельных связанных наследственностью класса:
  • Класс родитель. Содержит свойства токена. Используется в дереве токенов.
    Варианты названия: TTokenProps, TTokenProperites, TAbstractSynSymbol, TCustomSynToken, ... ваш вариант?..
  • Наследник первого класса с добавлением свойства-строки. Используется в списке токенов. Это и был раньше TSynSymbol.
    Новое название: TSynToken
  • Тоже наследник первого класса, но добавляет список строк (мультитеговость). Это класс используется в качестве откр./закр. символов диапазона.
    Новое название: TSynMultiToken
• Класс для правила KeyList (Keywords). Старое название: TSynKeyList.
  Новое название: TSynTokenList (причины читайте выше)
• Класс TSymbolNode - узел дерева токенов.
  Новое название: TTokenNode или как-то так...
• Класс TSymbolList - список узлов в дереве токенов
  Новое название: TTokenNodeList

Это сообщение отредактировал(а) Vitalik - 4.8.2005, 20:17

На самом деле эти вещи, на мой взгляд, лучше назвать лексемой (lexeme). В принципе, token тоже переводится как лексема, но во-первых, у token есть у другое понятие (маркер, метка), во-вторых, термин token уже используется в highlighter'e именно для того, для чего он более подходит - выделенная последовальность рассматриваемая парсером. То есть token - это то, что мы можем рассмотреть как лексическую единицу, а лексема - это конкретная лексическая еденица имеющая смысл. Мне так кажется понятнее и менее запутывающе.

Соотвественно мои варианты были бы:
1. Lexeme. TLexeme (или THglLexeme). - Лексема. Лексема подсветки.
2. Lexeme pair. RangeLexemePair - Лексемная пара диапазона.
3. MultiLexeme - Множественная лексема.

A может так:

1. SignRange
2. DoubleSigns
3. MultiSigns
4. OpenFolding, CloseFolding (OpenFold, CloseFold)
5. Нет

Добавлю и я свою ложку дегтя

А чем вам слово тэг не нравиться? Тем что не нравиться? Или тем что на HTML-ое слово похоже?

Имхо - то что доктор прописал.

Цитата(jasny @ 5.8.2005, 08:43)

А чем вам слово тэг не нравиться? Тем что не нравиться? Или тем что на HTML-ое слово похоже?

Мне в принципе оно до сего момента очень нравилось, да и привык я к нему.
Но Quadr0 высказал мысль о том, что тега - это <...> и не подходит для нашего случая...
Поэтому я и создал эту темку.
А StayAtHome предложил интересную мысль о "токенах". Она мне понравилась тем, что немного лучше отражает суть вещей в парсинге подсветки. Так как что ключевое слово, что откр./закр. символы диапазона - это в конечном счёте суть просто "токены".

Цитата(ActioN @ 4.8.2005, 23:06)

1. SignRange 2. DoubleSigns 3. MultiSigns

Sign - это больше "знак", "символ", "буква"... Так что немножко не подходит по смыслу.
Во-первых, у нас не одиночный "символ", а, во-вторых, у этих классов должно быть что-нибудь общее от "лексемы", "тега" или чего-то в этом роде...
Но спасибо за мнение!

Цитата(Fantasist @ 4.8.2005, 22:52)

На самом деле эти вещи, на мой взгляд, лучше назвать лексемой (lexeme). Соотвественно мои варианты были бы: 1. Lexeme. TLexeme (или THglLexeme). - Лексема. Лексема подсветки. 2. Lexeme pair. RangeLexemePair - Лексемная пара диапазона. 3. MultiLexeme - Множественная лексема.

Хм... Лексема... Неплохая идея!..
Но пара моментов:
1). см. ниже (через две) мотивацию выбора token...
2). Небольшой минусик (личного характера): Lexeme - это три слога, а Token - два...

Цитата(Fantasist @ 4.8.2005, 22:41)

В принципе, token тоже переводится как лексема

Даже так: "лексема" переводится как "lexeme" только в лингвистическом и научном словарях, но как "token" в компьютерном и политехническом!

Цитата(Fantasist @ 4.8.2005, 22:41)

но во-первых, у token есть у другое понятие (маркер, метка)

В принципе да... но ведь у многих слов есть разные значения... Я не думаю, что это было бы серьёзной помехой, тем более:

Цитата(Fantasist @ 4.8.2005, 22:41)

во-вторых, термин token уже используется в highlighter'e именно для того, для чего он более подходит - выделенная последовальность рассматриваемая парсером.

Да, термин токен используется при выдаче SynEdit'у участков подсвеченного текста с помощью функций: GetToken, GetTokenAttribute, GetTokenKind, GetTokenPos...
Но также верно, что в списке токенов и дереве токенов используются именно эти классы "токенов", а мы просто отдаём SynEdit'у информацию об этих токенах... То есть в парсере мы работаем с "токенами" и отдаём информацию о токенах...
По-моему довольно логично и красиво

Цитата(Fantasist @ 4.8.2005, 22:41)

То есть token - это то, что мы можем рассмотреть как лексическую единицу, а лексема - это конкретная лексическая еденица имеющая смысл.

В приницпе что-то в этом есть... Но:

Цитата(Fantasist @ 4.8.2005, 22:41)

Мне так кажется понятнее и менее запутывающе.

Но это смотря как посмотреть... Так получается у нас вводится как будто бы еще одно новое понятие Lexeme, хотя на деле Token и Lexeme мало бы чем отличались...

Fantasist, удалось мне тебя убедить или мои доводы всё же слишком слабы?..

P.S. Что там по поводу ActiveX, сможешь заняться? Темка здесь