Bug 1211 - Improvements to syntax styles system
Summary: Improvements to syntax styles system
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: Trunk
Hardware: PC Mac OS
: Lowest enhancement
Target Milestone: ---
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2011-10-03 18:48 UTC by Mikayla Hutchinson [MSFT]
Modified: 2013-02-18 01:49 UTC (History)
1 user (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Mikayla Hutchinson [MSFT] 2011-10-03 18:48:19 UTC
Currently syntax styles are somewhat ad-hoc. Any syntax scheme can use any style name, and color schemes can define any style. Styles cascade, for example if a syntax scheme uses styles foo and foo.bar but the color scheme only defines foo, then it will cascade to the implicit child style foo.bar.

In some ways this is nice, as it allows syntax schemes to trivially define new color names that could then be provided by custom color schemes. However, if would be good to be more consistent. For example, number constants in the C# syntax engine are highlighted as the "string" color, but elsewhere "constant.number" is defined. What would make more sense would be to use "constant.string".

Note also that the color scheme editor doesn't show all available styles, and doesn't show the cascades. It would also be nice if it allowed previewing several kinds of file.

It's also been proposed that color styles are improved the following ways:
* use JSON to make them easier to read/write by hand
* reflect the cascading of styles in the format, by nesting child styles in parent styles
* support simple expressions with functions to lighten/target/combine/invert named colors
* allow for schemes that "subclass" other schemes
These latter two would also make it possible to create a scheme with a few base named colors, and that defined many styles derived from these. This scheme could be subclasses and just the base colors overridden.
Comment 1 Mike Krüger 2012-11-08 06:25:03 UTC
I've played around a bit to become familiar with JSON a bit - how about that:
 
 {
 	"name":"MyScheme",
 	"inherits": "Oblivion",
 	"palette":[
 		{ "name":"butter2", "value":"#edd400" }
 	],

 	"colors":[
 		{ "name": "Bookmark Top", "color":"white" },
 		{ "name": "Bookmark Bottom", "color":"skyblue" },
 		{ "name": "Error underline", "expression":"Alpha(red, 50)" }
 	],

 	"text":[
 		{ "name": "Text Color", "fore":"black", "back":"white" },
 		{ "name": "Text Color (Selected)", "expression":"Invert ('Text Color')" }
 	]
 }

I think the syle cascading is doing more bad than good and maybe that text colors and other colors should be splitted. The schemes are now defining not just text colors - borders, lines etc. as well. And the 'name' should be a bit more descriptive to make it easier to read & understand what it means.
Comment 2 Mike Krüger 2013-02-18 01:49:56 UTC
Implemented - You can review it, I would love getting suggestions :)

+ JSON
- Cascading Styles (that made the scheme files hard to maintain -> adding colors 99% broke it) and that nesting was very unique to our IDE (read: it was hard to write scheme importers)
- Simple expressions - I can't really find a justification working on that - this should also be supported in the scheme editor then, makes things more complicated than helpful IMO
+ Subclassing of other schemes