In create table Orders (count int, id serial PRIMARY KEY) (advanced mode), the identifiers Orders, count, id and the type keywords int, serial all render in the same teal color in the echoed input line.
Expected
Type keywords should be visually distinct from identifiers. Conventional choices: types share the keyword color (e.g. the same shade as PRIMARY KEY), or get their own dedicated type-keyword color.
### Observed
In `create table Orders (count int, id serial PRIMARY KEY)` (advanced mode), the identifiers `Orders`, `count`, `id` and the type keywords `int`, `serial` all render in the same teal color in the echoed input line.
### Expected
Type keywords should be visually distinct from identifiers. Conventional choices: types share the keyword color (e.g. the same shade as `PRIMARY KEY`), or get their own dedicated type-keyword color.
### Pointers
- Theme: `src/theme.rs`
- Input echo styling / token classification: walker token classification → UI styling in `src/ui.rs`
Root cause: Node::Ident and the Word struct both carried a highlight_override: Option<HighlightClass> field, and both were dead — the walker driver destructured the Ident's to _ and walk_word hardcoded Keyword. So column types (int, serial, …) rendered identically to table/column names in the echoed input.
Fix: wired both overrides through the walker, and added a dedicated HighlightClass::Type with its own theme colour tok_type (a pink/deep-magenta in both light and dark themes, distinct from keyword-purple and identifier-teal). The three IdentSource::Types slots opt in, so:
canonical types (int, serial, text, …) render type-coloured in both simple and advanced mode;
advanced-mode single-word SQL aliases (float, varchar, integer, … per ADR-0035 §3) ride along for free;
the two-word double precision alias opts in via a new Word::type_keyword constructor so it matches its synonyms.
Chose a dedicated type colour over reusing the keyword colour (per the pedagogy-wins-ties principle): a learner can now tell a type from a clause keyword from an invented name — three roles, three colours.
Documented as ADR-0022 Amendment 4. Covered by dsl_type_keyword_classified_as_type, advanced_type_keywords_classified_as_type (this ticket's exact example), advanced_double_precision_classified_as_type, type_colour_is_distinct_from_keyword_and_identifier, plus extended theme tests.
Fixed in d20f765.
Root cause: `Node::Ident` and the `Word` struct both carried a `highlight_override: Option<HighlightClass>` field, and both were dead — the walker driver destructured the Ident's to `_` and `walk_word` hardcoded `Keyword`. So column types (`int`, `serial`, …) rendered identically to table/column names in the echoed input.
Fix: wired both overrides through the walker, and added a dedicated `HighlightClass::Type` with its own theme colour `tok_type` (a pink/deep-magenta in both light and dark themes, distinct from keyword-purple and identifier-teal). The three `IdentSource::Types` slots opt in, so:
- canonical types (`int`, `serial`, `text`, …) render type-coloured in both simple and advanced mode;
- advanced-mode single-word SQL aliases (`float`, `varchar`, `integer`, … per ADR-0035 §3) ride along for free;
- the two-word `double precision` alias opts in via a new `Word::type_keyword` constructor so it matches its synonyms.
Chose a dedicated type colour over reusing the keyword colour (per the pedagogy-wins-ties principle): a learner can now tell a type from a clause keyword from an invented name — three roles, three colours.
Documented as ADR-0022 Amendment 4. Covered by `dsl_type_keyword_classified_as_type`, `advanced_type_keywords_classified_as_type` (this ticket's exact example), `advanced_double_precision_classified_as_type`, `type_colour_is_distinct_from_keyword_and_identifier`, plus extended theme tests.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Observed
In
create table Orders (count int, id serial PRIMARY KEY)(advanced mode), the identifiersOrders,count,idand the type keywordsint,serialall render in the same teal color in the echoed input line.Expected
Type keywords should be visually distinct from identifiers. Conventional choices: types share the keyword color (e.g. the same shade as
PRIMARY KEY), or get their own dedicated type-keyword color.Pointers
src/theme.rssrc/ui.rsFixed in
d20f765.Root cause:
Node::Identand theWordstruct both carried ahighlight_override: Option<HighlightClass>field, and both were dead — the walker driver destructured the Ident's to_andwalk_wordhardcodedKeyword. So column types (int,serial, …) rendered identically to table/column names in the echoed input.Fix: wired both overrides through the walker, and added a dedicated
HighlightClass::Typewith its own theme colourtok_type(a pink/deep-magenta in both light and dark themes, distinct from keyword-purple and identifier-teal). The threeIdentSource::Typesslots opt in, so:int,serial,text, …) render type-coloured in both simple and advanced mode;float,varchar,integer, … per ADR-0035 §3) ride along for free;double precisionalias opts in via a newWord::type_keywordconstructor so it matches its synonyms.Chose a dedicated type colour over reusing the keyword colour (per the pedagogy-wins-ties principle): a learner can now tell a type from a clause keyword from an invented name — three roles, three colours.
Documented as ADR-0022 Amendment 4. Covered by
dsl_type_keyword_classified_as_type,advanced_type_keywords_classified_as_type(this ticket's exact example),advanced_double_precision_classified_as_type,type_colour_is_distinct_from_keyword_and_identifier, plus extended theme tests.