Quirks and inconveniences when configuring syntax highlight styles

[nurbles]

It seems that the very first color I tried to set does not exist in the Codist color set! I didn't feel like exploring to find out how many other colors I rely on are not supported, but I'm going to expect there will be more if I search.

Since this is an important color for me (and Codist doesn't start with my current colors, requiring me to manually find them all over again), this potentially great feature is not usable for me at this time.

[wmjordan]

I don't quite understand your situation.
I guess that you have trouble configuring syntax colors for specific syntax classification.

Theoretically Codist supports highlighting styles of all languages.
And you don't need to "find out" syntax elements.

Just open the syntax highlight customization window, click on the syntax symbol in your code, change the color, and you are done. All changes take place visually. What you see is what you get.

[nurbles]

OK. I still have issues: (Sorry for the length, if you'd prefer a number of separate issues let me know and I'll resubmit these separately.)

1. With the explanation you provided here and the documentation, I had expected the appropriate "Syntax style" (the name on the list in the Codist dialog) to be selected. Instead, the SET of colors containing the appropriate element is opened and no more, so I need to manually select the correct color to change. I don't understand why, if Codist knows the type of style element I clicked, why that element cannot be automatically selected in the list and its settings displayed as if I had selected it. (That's how I expected this to work.)

2. After changing a color, there seems to be no way to "undo" the change. So far in my experimentation, the "Reset" button is having no effect on the displayed source code, unlike choosing a color or style. When I manually selected cppType and changed the color to WHITE (#FFFFFF), it changed them from ltcyan (#00FFFF) to white. When I clicked 'Reset', they remained white.

3. When I enable Codist's Syntax Coloring, it applies to subsequently opened files, as documented. When I disable it, though, the colors get "wierd" until VS is stopped and restarted.

4. When I enable Codist's Syntax Coloring (and make NO CHANGES), the next file I open has some other set of colors that I did not choose and, IMHO, are quite poor choices. So in order to use this feature, I must first rediscover (I don't remember everything!) and reapply all of my color preferences. It would be much better to start with the colors already configured into Visual Studio. (Once I choose colors, they remain across restarts -- whether or not I have EVER pressed the 'Save' button in Codist's syntax color dialog.)

5. Some colors are not correctly displayed at startup. the color used for cppType is #00FFFF (the same color as identifier) when it should be #FFFFFF, according to Codist's settings. Not sure how many colors this affects, but it happens consistently for me: Every time I I start Visual Studio or enable Codist's Syntax Coloring:
   

6. I also noticed that the Codist settings I make in VS2019 are picked up and used by the Codist installed in VS2022 (on the same computer.) We consider such sharing to be a very bad default (and worse, only) option. We have been lobbying Microsoft for years (unsuccessfully) to at least offer an option for different instances of Visual Studio to share settings.

7. It is also slightly disturbing when a variable is colored two different ways (sometimes on consecutive lines!) For example:

      HRESULT hr = pfd->GetCurrentSelection( &psi );
      if( SUCCEEDED( hr ) )

The first instance of the variable hr is colored as cppLocalVariable while the second instance is colored as identifier. It would be great if it were possible for you to correct this (it also happens with cppMemberFunction colored as identifier and maybe more). Unfortunately, Microsoft's built-in syntax coloring seems to have the same issue.

8. Finally, custom colors are not saved [or maybe just not restored?] (in the ChooseColor dialog), so I am required to manually record any color I may want to re-use or use as a base for another color.

[wmjordan]

1. With the explanation you provided here and the documentation, I had expected the appropriate "Syntax style" (the name on the list in the Codist dialog) to be selected. Instead, the SET of colors containing the appropriate element is opened and no more, so I need to manually select the correct color to change. I don't understand why, if Codist knows the type of style element I clicked, why that element cannot be automatically selected in the list and its settings displayed as if I had selected it. (That's how I expected this to work.)

It is impossible to select the one style.

The display of a symbol can be a composition of several syntax styles, thus Syntax Styles lists all styles that correspond to the selected / clicked place in the code editor.
For instance, a symbol can be of static and a class at the same time (in other languages rather than C++). The static symbol has a classification tag for it. And a class has another classification tag. Codist has no idea which one you want to configure, since bother of them can be possible. It is up to you to select the correct classification tag (syntax style) listed there and make corresponding configuration.

If you want the old-school configuration way like the Fonts and Colors, click the "All languages" in the Syntax Categories box, where all configurable symbols are listed.

[nurbles]

It is impossible to select the one style.

So I click on something rendered in RED and you show me the three styles that may apply: One each RED, GREEN and BLUE. And it is not possible to determine which one I'm trying to change? Clearly for the RED object I clicked, it is the ONLY possible style I could be changing. I could (possibly) understand if more than one color in the applicable list matched what I clicked, but still, Codist must've made a final choice as to what style it was using to render the clicked item ... or does it render all of the potentially applicable styles? If the latter, does that mean colors can change as I'm moving through the file? If the selected color is consistent (and therefore predictable) then, once again, it seems that it should be possible to select the correct item in the style list.

Sorry to sound so argumentative. It just baffles me that, if the correct syntax style is always selected for rendering, I cannot comprehend why that suddenly becomes impossible later. I'm guessing some lousy code from Microsoft, as I so often encounter in my own work.

[wmjordan]

Thank you for taking so much time with valuable feedback.

2:
Bug reproduced and confirmed.
This bug might also affect your subsequent configurations and operations, since the highlight states got corrupted.

3:
The disabling of highlight will not restore all settings.
It is a known issue.
It can take some time to fix this.

4: It would be much better to start with the colors already configured into Visual Studio.
Hmm, your suggestion makes sense.
I will change the behavior of Codist.

5:
The highlight states sometimes get corrupted. I spent quite a lot of time to figure out how the highlight system works but there can be quirks there. If you can post more screenshots demonstrating the reproducing steps that can help more.

6:
I also encounter this issue while I was debugging with another instance of VS.
It is possible, with some efforts, since this requires a substantial reconstruction of the configuration system.

7:
It is up to the classifier and/or tagger which do the magic, and out of the control of Codist.

8:
Hmm, this can be a future enhancement.

[wmjordan]

Codist must've made a final choice as to what style it was using to render the clicked item ... or does it render all of the potentially applicable styles

Unfortunately, Codist is not the final one.
It is the VS, which combines all possible styles and mixes them down.
Codist just tells VS that, for instance, the CppType should be colored in RED and BOLD. It is up to VS's choice whether a symbol being classified or tagged as CppType is rendered in RED and BOLD eventually. If you open a C# code file with the Syntax Highlight Customization window opened and you can see that the styles are quite complicated--a token in the code file can have quite a few syntax styles at the same time. It is a hard time to decide which one is the most possible one.

Nevertheless, in your case, and most common cases in C++, it is quite possible to find out the "most possible" syntax classification and have it selected in the Syntax Style by default. I will give it a try.

[wmjordan]

There's a new beta version which addressed some of problems (1, 2 and 4) you posted above.

Please download it from #283 and give it a try.

BTW, due to the limitation of VS API, Codist has no idea about the actually rendered style of a code symbol on the screen.
For instance, a symbol on screen can be rendered in purple, but it is possible that the symbol is a composite of several syntax styles that are in red, in white, in purple individually. We don't know the final result of the mixture of those styles. Codist has to "guess" one, when it automatically selects a style in the customization window.

[wmjordan]

I can not reproduce problem 5 here.

[wmjordan]

As for request 8, I remembered why the custom colors were not used. Quite a few years ago. I once tried to use those custom colors during the customization, however, I found the experience was not so good. Thus I removed the already written code.

The implementation of the ColorDialog is quite absurd.
Codist sets the selected color to be the color of the current syntax style.
If you press the "Add to custom color" button in the ColorDialog, it always overwrites the 1st custom color.
If you try to click the other custom color slots in that dialog, it immediately overwrites the selected color.
Thus you can seldom easily set the selected color to a specific color slot without the selected color being overwritten by the color on that slot.
That is a very frustrating experience, making the Custom colors in the ColorDialog hard to organize, unless you only use the first slot in that dialog.

Hence I added two items, "Copy color" and "Paste color", to the drop-down menu when you click on the color button. You can use those two menu commands to reuse colors.

[wmjordan]

Today I tried a way to prepopulate a set of colors based on currently used color that can be candidates for syntax colors.

I guess that the situation of request 8 can be improved by writing a custom color picker, which can be better tailored to the syntax highlight customization scenario.

[wmjordan]

@fitdev
You also use the syntax highlight function.
Care about joining in this discussion?

[fitdev]

It is working well for me for the most part, apart from a few issues with things like record struct or ref struct or record but it mostly due to double classification of something as a record and a struct, so not critical. I have not really noticed any major issues with the syntax highlight.

[nurbles]

Thanks! I will give the test version a try, but since part of it is to choose better colors the first time syntax coloring is enabled after installing Codist, I must ask about possible saved settings: I plan to

1. remove the existing Codist extension (from both VS2022 and VS2019)
2. restart both Visual Studio products without the extension
3. close both VS products
4. install Codist in VS2019 (which is my primary environment)
5. start VS2019 to see how the test version works

Will that process get me a "clean" install of Codist, as if I had never had it installed before? If not, what do I need to remove/clean up between steps 3 and 4 to ensure the test is "clean"?

---

For number 5 [At least one color does not work correctly at VS start up]...

This one is consistent for me. If there is anything I can check and/or test for you, please let me know. I would much prefer to have the same behavior you are reporting, but I do not.

The color assigned to custom data types (cppType) is always the identifier color. If I open the Codist color settings and select the white color that is already selected for the cppType, then the color of those symbols changes to white, as I would've expected when I load Visual Studio.

There may be other colors that have this issue, but with 394 different colors to set in my Fonts & Colors | Text Editor dialog, there's no way I can check them all!

---

Also, a comment on the custom colors in the not-so-great ChooseColor dialog:

I agree it is a clunky interface, but after using it for literally decades, I personally, have gotten used to how it works. Yes, it is annoying that it resets the selected color when an "empty" customer color slot is selected, but it is really selecting the color currently in the slot, which is what the user wants after a custom color has been assigned. I've simply learned to look at and remember the three RGB values I want and type them back in after selecting an "empty" custom slot.

Some programs even save the custom colors to reload after program restarts, but that's not nearly as important as being able to save and reuse a color during a single work session. As it stands, I need to write down the RGB for specific colors I wish to use in multiple settings so that I may type them in every time I open the ChooseColor dialog -- I was hoping I could do that only once.

---

Finally, does formal language really need to be listed in the syntax color lists? If so, wouldn't it simply be the default color when no specific classification fits? (If that is even possible) I can understand that it is the base type (I hope that's a good term) for ALL of the classification types, but I would be surprised if it is actually a type that can actually exist. I'm probably wrong, just following what I consider logic (which, apparently, often is not.)

[wmjordan]

Nice to hear from you, @nurbles.
You don't need to uninstall Codist to "clean" it.

1. Click the "Open Config Folder" button in the Options page.
2. Press OK or Cancel button to dismiss the Options dialog.
3. Close VS.
4. Delete or rename the "Config.json" file in the folder.

Now the Codist is reset.

[wmjordan]

For number 5 [At least one color does not work correctly at VS start up]...

This one is consistent for me. If there is anything I can check and/or test for you, please let me know. I would much prefer to have the same behavior you are reporting, but I do not.

If the problem is consistent, that'll be relatively easier for us to fix it.
Please upload the config.json file mentioned in my previous comment and let me test on it.

[wmjordan]

the not-so-great ChooseColor

I usually use the aforementioned "Copy Color" and "Paste Color" to reuse colors.
To create a harmonious theme, usually we set the Saturation and Lightness (or Brightness) to a fixed value and change the Hue value. The Copy color function can help us to do the job.

If I were to rewrite our own the ColorDialog, I will consider listing standard colors and existing colors in current highlight configuration in two arrays of buttons. Another array of "color variance" buttons may be there to help users to quickly formulate their color themes too.
A textual preview of the selected color is possible too.

However, the Color Spectrum on the ColorDialog is kind of difficult.
If there are plenty of standard colors and existing colors listed to help us start up, do you think the Spectrum control a necessity?

[wmjordan]

The ColorDialog with color variances mentioned in #282 (comment) is released in beta 8926.

[nurbles]

Here's the config.json that you requested.
Config-json.zip

---

If there are plenty of standard colors and existing colors listed to help us start up, do you think the Spectrum control a necessity?

As long as there's a mechanism for selecting a precise color (like RGB) and making adjustments to an existing color (like HSL), I think we can make it work.

If you're interested in an custom color selection dialog that may have gone overboard, you might want to check out the ColorPicker extension I'm fond of his method for providing gradients to select colors, but he also allows direct entry in more formats than I realized existed!

[wmjordan]

does formal language really need to be listed in the syntax color lists?

It is really questionable. The thing is the base type of many classification types. However, it is not necessary the base of all syntax classification types. For instance, vsMarkdown_url (the URL in Markdown file type) is base of text but not formal language.
Thus I still want to leave it there.

[wmjordan]

Here's the config.json that you requested. Config-json.zip

I will check it out later.

If there are plenty of standard colors and existing colors listed to help us start up, do you think the Spectrum control a necessity?

As long as there's a mechanism for selecting a precise color (like RGB) and making adjustments to an existing color (like HSL), I think we can make it work.

Yes, numeric value boxes or sliders will be there.
But I can't guarantee the color spectrum control can be implemented.

If you're interested in an custom color selection dialog that may have gone overboard, you might want to check out the ColorPicker extension I'm fond of his method for providing gradients to select colors, but he also allows direct entry in more formats than I realized existed!

I have seen similar implementations alike the ColorPicker.
They use color gradients (fixed hue, varied saturation and brightness in the big box).
I would like to have the color spectrum in the current ColorDialog better, since it helps me quickly setup both Hue and Saturation in the big box.

[nurbles]

Sorry I forgot to mention this...

You did such a good job automatically selecting the appropriate syntax style that it took me a while to remember that was a new function! So far, everything I've found to check it with has worked perfectly! THANKS! To me, this makes a very good feature into a great feature!

[nurbles]

Another observation on the test version...

Because Codist can save and restore its own colors, I hoped I would finally be able to save my colors, switch to a dark theme and restore my colors after the theme completely messes them up. And it worked. Somewhat, at least.

I needed to leave my desk to a while, so I powered off my displays. When I returned home and powered them on, as usual Windows had moved and resized Visual Studio because I run it on a 4K TV rather than a purpose-built computer monitor (the TV was almost 10 times cheaper than an equivalent size/resolution monitor!) Unexpectedly, this had a side effect of all the fonts and colors returning to the theme's defaults!

I was able to open Codist's color settings and reload my saved colors, but having the colors changed due to a monitor change like that was VERY unexpected. It appears that something in the monitor loss/detect triggered Codist to reload the current colors from Fonts&Colors, as if it had just been started and was first creating the color config. I would only expect that to happen once, perhaps with a button to trigger that function on demand if I changed the theme and wanted Codist to start with the new theme.

So, while you did a great job copying the pre-existing colors, it seems to me that the copy function may be called at some additional and unexpected times.

[nurbles]

[Apologies for these long posts. I try to ensure I'm clearly describing what I see and to provide whatever useful information I can (sometimes as suggestions {smile})]

For the monitor switching issue, I don't have two monitors thus I can not reproduce that issue.
It might be a problem of VS, I guess.

It is possible (but probably unlikely) that the loss of a monitor might trigger the save events. That would require physical disconnection of a purpose-built computer monitor, since they have some special EDID circuitry that apparently even works when the monitor is powered off so that Windows "knows" the monitor is still attached.

My issue is definitely a Windows issue at its root, since Windows thinks my TV monitor is, well, gone forever I guess as opposed to temporarily powered off, which seems to be how Windows deals with computer monitors. This causes Windows to move all icons and applications from the TV monitor (which is the central of 3 screens) to the other two screens, with Visual Studio ending as spanning both of the other two screens.

How Visual Studio deals with this event is beyond me. Before installing Codist, I didn't notice any changes other than Window size and position because my TV screen is 3840x2160 while the other two screens are only 1080x1920 and 1280x1024, so VS is always taller than the other two screens and often wider than both put together.

If you would like me to run any tests, including instrumented versions of Codist, just let me know.

---

the copy function may be called at some additional and unexpected times.

That may not be a good idea.
The "copy function" has to be run in the UI thread.
In one of my theme, more than 100 styles are set. Reapplying the styles can take some considerable time. The periodically called "copy function" can block the user interface and bring bad experience to us.

I think you misunderstood a possible issue for a suggestion. I was not asking for the copy function to run more often -- I was suggesting that it is running too often already. I suspected this because the colors revert to the VS selected colors at unexpected times. Two examples I can remember right now are when I loaded the theme and after the screen issues described above. I believe there was at least one other time I accidentally triggered the colors to return to the theme's colors, but I failed to record it on paper, in a file or (sadly) in my own aging memory (I started writing code 45 years ago.) If I see the colors revert to the theme again, I will actually write it down so that I may report it to you.

---

I loaded the config file and it seemed to be working as expected.

Sorry, after cleaning the old config out and installing the test version I got some unexpected color changes at first. For example, control keywords changed from #00FF00 to the kinda dull blue in your image. However, after going through the colors and adjusting the ones that weren't what I expected and setting a couple that were new to me (like a special color for labels, thanks!) I have not seen and incorrect colors at the initial VS load time.

---

I was curious about the requirement to use the VS Fonts&Colors to change the default foreground & background colors for the Text Editor. I wondered if changing the background for formal language might actually turn out to be the default colors. It does seem to be the default colors for the syntax elements, but it is not the default color for the entire Window, i.e. anywhere that produces the "No syntax highlight is applied to active position in code window," message in Codist's color dialog.

Are the default colors (called "Plain text") unavailable to Codist or have you chosen not to present them? Just curious, since I can still use the VS setting to control them.

---

Finally, while I was searching the Codist syntax styles for "Plain Text" (or something that might be plain text), I was using the All languages category. This spawned these suggestions:

1. There are apparently some colors that I have set with the same FG/BG colors, so they appear as empty list items. Perhaps those could be presented in a way that still shows the name and font selected, but uses a pair of frames boxes to show the FG/BG color? Or something so that the name is at least visible? (Yes, I noticed that selecting the invisible item shows its name below the list, but (to me, at least) it is preferable to see the names without requiring the user to take additional action and look outside the list to see a list item's name.
2. I'm sure there is some sort of logical ordering to the list, but it can be difficult to scroll through when one is unsure of the name desired. It occurred to me that [at least] two other sequences might be nice to have as options for this list: Sort by name; Sort by FG color, name. The first is obvious. The second would allow us to scan through for an unknown name by looking for a color match. Granted, the "Selected code" feature eliminates almost any need for the "All languages" category, but... for those of us that might want to preset colors before loading files with all the necessary syntax styles, this would be a nice feature.

[nurbles]

I just loaded VS2022 and noticed two things:

1. The color for the cppDataType symbols was using the identifier color again. This time I had to change the cppDataType color and then change it back to the correct color to get it to apply. In the past I only needed to reselect the same (currently selected) color to get it applied. So it seemed to work OK in VS2019, but the test version is still having an issue for me in VS2022 -- at least this time. Hmmm... I just exited and restarted VS2022 and this time the colors loaded right, but the code editor font somehow reverted to the theme's font instead of the font I prefer. Since I modified the Fonts&Colors "Plain Text" font setting to my preferred font, a third restart of VS2022 worked fine.
2. When I switched VS2022 to dark mode and then imported my previously saved Codist style colors, I noticed that Codist does not "know" about the color for visible white space. Clearly that's not a syntax element, so I'm not sure it is possible, but I was using a very dark gray (on black) so the symbols were barely noticable, but there if I wanted to look for them -- the dark mode theme made them #009999, which was far too visible and once again required me to visit the VS Fonts&Colors. So yes, I am being a whiny baby because I've found some colors that Codist doesn't "know" about and therefore doesn't export/import. Feel free to ignore! (smile)

[wmjordan]

[Apologies for these long posts. I try to ensure I'm clearly describing what I see and to provide whatever useful information I can (sometimes as suggestions {smile})]

It is always good to have kind and rational discussions. No matter long or short. 😄

I was not asking for the copy function to run more often -- I was suggesting that it is running too often already. I suspected this because the colors revert to the VS selected colors at unexpected times.

You have not met with these kind of situation before since you have not used Codist to override the syntax styles.
Codist does not rewrite the Fonts and Colors configuration entries (some entries such as "keyword", "number", etc. may be reconfigured at runtime in memory, but not written into the registry) but uses its own configuration system, which includes many extended styles. When it works, the loads and then overrides the Fonts and Colors configurations.
And Codist is as lazy as possible. It won't kick in after first time initialization, unless it gets notification.
If the colors revert to VS selected colors at unexpected time, it might re-read those settings from the registry, not from the overridden memory entries. If so, it is not so likely that Codist is doing too much job, but on the contrary, it fails to get notification that the color theme is reset or handle the theme that has been reset.

I only have a laptop computer so it is impossible for me to unplug the monitor to reproduce this.

the default foreground & background colors for the Text Editor

The formal language entry is not the way to go.
The current implementation of syntax color system in VS does not include editor foreground or background.
It is somewhere else. Partly exposed by the IEditorFormatMap interface.
There should be another configuration window to configure these aspects.

For instance, the following code, if uncommented, will change the editor background into light green when a new code window is open.

Codist/Codist/SyntaxHighlight/HighlighterFactory.cs

Lines 31 to 40 in 1529a84

	//var formatMap = ServicesHelper.Instance.EditorFormatMap.GetEditorFormatMap(textView);
	//ChangeEditorFormat(formatMap, "TextView Background", m => m[EditorFormatDefinition.BackgroundBrushId] = Brushes.LightGreen);
	}
	static void ChangeEditorFormat(IEditorFormatMap formatMap, string propertyId, Action<System.Windows.ResourceDictionary> changer) {
	var m = formatMap.GetProperties(propertyId);
	if (m != null) {
	changer(m);
	}
	formatMap.SetProperties(propertyId, m);

There's already quite a few extensions which can change editor background in the marketplace. And changing the text color of the code editor via Fonts and Colors options page is easy. Therefore I have not code such a configuration window to do similar things.

There are apparently some colors that I have set with the same FG/BG colors

Those things are usually LogPoint and SnapPoint styles. Their background colors are implemented via text adornments and can not be configure via the syntax color configuration system--maybe the IEditorFormatMap interface can touch them once again.
I guess they should be hidden from the configuration window.
If some else styles have the same foreground and background, you should actually avoid that kind of configuration.

I'm sure there is some sort of logical ordering to the list, but it can be difficult to scroll through when one is unsure of the name desired. It occurred to me that [at least] two other sequences might be nice to have as options for this list: Sort by name; Sort by FG color, name.

The "All language" list is ordered by syntax priority of the syntax highlight system. Prior entries have lower priority and latter ones have higher priority, typically.

Currently there's a filter box on top of the list which can help you find out the entries you want.
Sorting by name is possible.
Sorting by foreground color is not so viable, since some entries do not have foreground color specified.

The color for the cppDataType symbols was using the identifier color again

From the "All language" section in the configuration window, we can see that "CppDataType" should have a higher priority than "identifier". However, the implementation in VS can somehow break the priority rule. Thus you will see odds in the final result (style of identifier overrides style of CppType, previously). There's no documentation to explain why these odds can happen. It took me quite a few years to get any inches to get around the odds in the system. And obviously, they are not yet surmounted.

Codist does not "know" about the color for visible white space

No, it doesn't. The visible white space is in another place, not in the syntax highlight system.
There should be another specific configuration window for such kind of things, if it is implemented.

[wmjordan]

A short conclusion about odds remained:

1. Syntax highlight override may get lost after monitor switch.
2. Syntax styles can still sometimes messed up that style priorities are not enforced.
3. Custom colors in ColorDialog is not saved.

And some requests maybe implemented in the future but not guaranteed:

1. Some aspects such as editor background, foreground, visible white space, line number, etc. requires a new configuration window.
2. It is better to being able to sort the syntax styles by name in the "All languages" section.

[nurbles]

You have not met with these kind of situation before since you have not used Codist to override the syntax styles. [...plus the remainder of this paragraph...]

OK, here's what I had hoped would be happening:

1. When Codist is first installed and the syntax coloring is first activated, Codist will extract the existing VS font&color settings to use as Codist's initial values. This would never be done automatically again.
2. There probably should be a button in Codist's color settings dialog that allows me to manually request number 1 to be performed again.

But what I think I see happening, and your comments seem to support this, is that at least one of the events that Codist responds to is used to trigger number 1 (above) and, unfortunately, this event occurs more often than expected (at least, "expected by me"). Also, there is nothing in Codist that records that number 1 has already been performed, so that it is not performed again, possibly destroying the user's updates to fonts & colors within the Codist color settings dialog. That automatic loss of settings is the issue that frustrates me -- once I have enabled Codist's syntax coloring and number 1 has been performed to provide a familiar starting point, step number 1 should never be performed again unless specifically requested by the customer, either by pressing a new button to trigger the function, or by removing the config file while VS is not running so that the next startup is "initial" again.

---

The current implementation of syntax color system in VS does not include editor foreground or background.
It is somewhere else. Partly exposed by the IEditorFormatMap interface.

It is called "Plain Text" in the Fonts&Colors, Text Editor color list. Changing the background of plain text changes the entire edit window background color, including all empty space. It also changes the background of everything using "Default" as the background color, so it is clearly where the overall default is for all "unclassified" areas, as well as the defaults for any "classified" symbols that are configured to use the default. That said, some classifications clearly have their own, unique defaults and I have no idea where those would be set (I suspect they are hard-coded somewhere.)

"Visible white space" is the same as this. It is one of the hundreds of colors in the Fonts&Colors list and, while not actually a syntax element neither does cppInactiveCodeClassification seem to be a syntax element, since, technically, it is not currently part of the code at all, yet that color is supported (albiet differently than the way VS uses the original color, but dimmed, while Codist makes all inactive code a single color).

---

And changing the text color of the code editor via Fonts and Colors options page is easy. Therefore I have not code such a configuration window to do similar things.

OK, I can accept that. (smile) It might save users a little time if there was some space in the color settings dialog that mentioned the fact that some "non-syntax" colors must still be controlled using the original Fonts&Colors (or whatever extension the customer already has to do that, I suppose.) Personally, I think I spent almost an hour experimenting with different colors in Codist before finally giving up and assuming that some colors were "uncontrolled" by Codist.

OHOT, if you could add a second panel (tab?) to Codist's color dialog where at least the most common of the non-syntax colors could be set (and therefore saved & restored!) that would be fantastic! But a small note (as mentioned above) somewhere would be helpful until you feel like tackling this new functionality (if ever.)

---

The thoughts about the "All language" list were mostly just ideas. I had seen and used the filter feature, but sometimes I have no idea what the correct term is that I'm searching for until I actually see it. I have similar issues with all search engines: sometimes I cannot find what I'm searching for until I already have the answer.

My mind finds it easier to scan a sorted list than a "chaotic" list. I don't know why, but that's apparently how I process information best. (smile)

The "sorted by color" idea also seems to be a natural because it would allow me to see if I have the same (or a very similar) color for a syntax style that is present in my current file, but may appear with styles that I've already defined. I agree that a visual search by color is made unnecessary by the ability to click on the item in question, so that was dumb (sorry, I think I was channeling Microsoft's dialog when I wrote that.)

---

re: Short Conclusion 1: I cannot determine whether Codist stops applying colors or the event that triggers Codist to copy the existing VS colors fires. I suspect the latter, since I doubt there is any way that Codist would just "stop" applying syntax colors. My thoughts on copying existing VS fonts & colors were detailed above.

re: Short Conclusion 2: I think this refers to an element sometimes rendering with a different color from its "family" of styles (e.g. a cppDataType rendering with the identifier color). If so, I am no longer seeing this happen reliably. Sometimes I see it when I switch between VS2019 and VS2022 (or back). Sometimes it is the cppDataType, but other times it has been the cppControlKeyword or cppKeyword. If I ever manage to get a reliable repro of this, I will let you know. Until then, I'll leave it alone unless you come up with an instrumented build you'd like me to use until it triggers.

---

FWIW, Codist is, so far, the closest I've found to an extension that allows me to save my Text Editor Fonts&Colors before applying a Theme and restoring them after. Themes have a nasty habit of changing FONTS to things I cannot see (I'm mildly vision impaired) and Codist helps me recover from that, so thanks! I'm mostly complaining due to frustration that I'm still finding some font and color settings that are not saved -- especially the default font, foreground and background, since I have almost all syntax elements set to use the default font and background.

---

I've submitted a feature request to "fix" the theme system and a bug report for the two different colors for the same variable name, in case you want to vote for them. (smile)

[nurbles]

I found a way to trigger an unexpected Codist syntax color theme change:

I was running VS2019 and everything looked fine. I opened VS2022 (while VS2019 was still open) to check something, which included loading and displayed source code, and then closed VS2022. When I returned to VS2019, the colors had changed to the dark mode theme defaults.

I used Codist to re-import my saved font/color settings and all was well. But this is a repeatable issue that should not cause the fonts/colors in either IDE to change.

[wmjordan]

I was running VS2019 and everything looked fine. I opened VS2022 (while VS2019 was still open) to check something, which included loading and displayed source code, and then closed VS2022. When I returned to VS2019, the colors had changed to the dark mode theme defaults.

Perhaps you are roaming VS settings.
I found the behavior of the roaming sometimes can be the source of trouble.
My fonts got changed after switching VS versions.
Once before the time, while I had opened VS for quite a long time and was coding as usual, the whole theme was changed without any notification. I got astonished to see that and turned off VS setting roaming after manually fixing mutated settings.

Codist won't reset syntax styles unless you press the Reset button or apply new Codist syntax themes in the customization window. When VS theme changes, it is the weakest moment that Codist can get lost. (see this issue, years ago I begun to fight against it: #14 )

[nurbles]

Both VS environments are set like this:

As you can see by the search for 'roaming' this is the only page VS has that might apply, yet there's no actual mention of roaming on the page that I could find!

I, personally, despise the fact that VS synchronizes all my setting by default because it is impossible to install (not update, I mean a new install) a new VS version (e.g. a new preview to test) without messing up settings in existing editions, since we aren't allowed to disable sharing settings until AFTER the install completes and it is too late. I've had several bug reports in for that, but MS never seems to understand -- or care.

[wmjordan]

Besides that, I forgot to say that I used a free Chinese firewall (Huorong) to block all Internet connections from most all VS processes, except devenv.exe and setup.exe.

[wmjordan]

I managed to find an open-sourced control which implemented the color spectrum in the color picker.
The new color picker will interact with the VS interface.
When we change the color, we can immediately see how it looks in the code editor window. It is much easier for us to tweak the syntax highlight colors now.

The only thing left is the custom colors part.

[wmjordan]

Hi,

There's a new beta version.
The new color picker has integrated into the VS much better. While you change the color for a syntax style, the change will immediately displayed on the code editor.
The custom colors part is also ready.

A filter which displays only customized styles is now placed in top right corner of the customization window.

This beta version has spent me 3 days' holiday! 2 days on the WPF color picker.
Please try it and give some feedback.

[wmjordan]

@nurbles
I managed to reproduce the bug that class name colors could go wrong after theme change.
I will see how to fix it.

[nurbles]

Sorry for my delay in testing ... I had some minor surgery last Wednesday and have been AFK until now.

I really, really like the new ChooseColor dialog that you found and the way it works! I was really impressed that I could see the colors change as I dragged the selector around the color spectrum box!

I also like the filter to show only customized styles! As always, I have a couple thoughts:

1. I was wondering about making the 'show only customized' filter "sticky" so that it keeps/restores its value when the dialog is closed/reopened. Of course then then requires an answer to: What if the appropriate selection is NOT customized? So I'm not sure how to deal with this or if there's any value.
2. Perhaps you could mark the customized styles in the list somehow? My first thought would be to use a different color (or shape?) for the checkboxes that are already being drawn. But you may not be in control of the list rendering code, so anything else would be OK, too. So would nothing -- your code, your choice. (smile)

These are just ideas, in case you're interested in them.

It just occurred to me that (if you haven't already) you might want to make a note that this could be a useful way for the colorblind to get syntax highlighting, since you support different fonts for every syntax. I think this is a great accessibility feature!

This beta version has spent me 3 days' holiday! 2 days on the WPF color picker.

I might need to make a second donation! (smile) Holidays are important, please enjoy them! I'm never important enough for you to lose any quality time! Then again, I once "lost" a four day holiday weekend writing my own web server from scratch, just to learn how to do it, so I can also understand getting hooked on helping your creating achieve its fullest potential! Thanks for your dedication!

[wmjordan]

I had some minor surgery last Wednesday and have been AFK until now.

Oh, I am sorry to hear that.
Hope you will recover soon and well.

1. Of course then then requires an answer to: What if the appropriate selection is NOT customized?

Yes. This is really the problem.
According to my experience:
we usually do not want to filter and customize already customized items, but want to change those we don't like 😛 .
Those we don't like and want to customize ones are usually visible--we see it, we want to fix it, thus we click it and customize it -> Problem fixed.

2. Perhaps you could mark the customized styles in the list somehow? My first thought would be to use a different color (or shape?) for the checkboxes that are already being drawn.

Yes. It is possible. That is what I once thought about.
The hardest part is the color. It has to be part of the VS theme. It can take some time to look for the appropriate color and try the shape for the mark.

However, when focusing on what we are doing, we usually use this customization window to create or fix the syntax styles, what we see is on the screen. We usually do not need to care whether a style is customized or not, but whether the style looks good to us. The appearance of the styles tell us which ones need to be fixed :)

The useful moment of the "customized" mark may be the time we want to export the syntax theme and share it with others. We need to make sure which ones will be exported (only customized styles are exported) and which ones are inherited from VS theme.

this could be a useful way for the colorblind to get syntax highlighting, since you support different fonts for every syntax

I have not yet realize this. Your feedback is really valuable. I would love to share it with my team.

Holidays are important, please enjoy them!

Thank you for this suggestion!!
Although programming Codist and sharing it with friends all over the world is funny. I've got to spend some more time with myself and my family.

[nurbles]

The useful moment of the "customized" mark may be the time we want to export the syntax theme and share it with others. We need to make sure which ones will be exported (only customized styles are exported) and which ones are inherited from VS theme.

Hmmm... is there any chance that there could be an option to export ALL colors, customized or not? I realize that once imported, all colors would them be customized, but that's OK for my purpose. I'm hoping to use Codist's export/import colors (and fonts) to avoid having strange, unexpected colors appear in my code if I change themes. I had the same problem with Microsoft's export/import .vssettings because they only export fonts & colors that were changed from default, resulting in some truly strange and unexpected combinations after a theme change and import of the text editor colors (I manually removed everything else from the saved settings file.)

So, while I understand why this isn't the default, it would be nice to have the option to export all current colors in order to ensure that an import results in the exact same color scheme instead of a mixture of two.

[wmjordan]

is there any chance that there could be an option to export ALL colors, customized or not?

In most cases it is possible to do so without great difficulty, at my first thought.

But unfortunately I found that sometimes some items were absent from the "All languages" list and I could not figure out the reason--perhaps those missing styles were generated dynamically as transient ones which would not appear in that list.

[wmjordan]

I found a way to trigger an unexpected Codist syntax color theme change:

I was running VS2019 and everything looked fine. I opened VS2022 (while VS2019 was still open) to check something, which included loading and displayed source code, and then closed VS2022. When I returned to VS2019, the colors had changed to the dark mode theme defaults.

I am working on the color theming problem.

Today I found that SOME colors could go wrong if the VS theme changed with the Syntax Highlight Customization window opened. Those "went-wrong" colors could be the ones listed on the "Select code" category on the customization window. If we closed the customization window before changing the VS theme, all things would go well.

[yekanchi]

Is it possible to set styles for collapsed xml docs Separately?
of course, this may be visual studio limitation.

[wmjordan]

Is it possible to set styles for collapsed xml docs Separately?

No API for this.

[wmjordan]

Is it possible to set styles for collapsed xml docs Separately?

I will keep an eye on it. Maybe I can dig out the API in the future.

[wmjordan]

@nurbles

How are you doing?
I've updated the new beta which addresses some weirdness mentioned above.
Please give it a try.

[yekanchi]

Is it possible to set styles for collapsed xml docs Separately?

I will keep an eye on it. Maybe I can dig out the API in the future.

once I saw a extension doing something over it. i will try to find it and reference it here.
by the way this is a nice extension i use recently:
https://marketplace.visualstudio.com/items?itemName=OlivierJacot-Descombes.PrettyDocComments
https://github.com/OJacot-Descombes/PrettyDocComments

[nurbles]

@wmjordan Well... I had been using v7.6.0.9098, which was working as I hoped and expected. After seeing your prompt, I looked back through the thread and found a link to v7.6.0.9239 (from the Beta 7.7 #288 page), so I downloaded it and gave it a try.

I'm not exactly sure what's going on, but it doesn't look like the syntax coloring isn't working.

• Many of my colors are different from what I normally use.
• I tried importing my previously exported colors, but that had no effect (and produced no message about incompatibility, if that's what went wrong.)
• When I try to change a color, The associated button in the Codist syntax color dialog is the only thing that updates to show the new color. Neither the syntax styles list, nor my source code changes (even after I click Save and re-open the dialog as shown below)
  
• The "live" updating of the selected color in the code while I'm working with the Codist dialog is no longer happening.

So, all in all, I think I'm going to try to revert to 7.6.0.9098 for now. But, I'm currently working on building up some embedded linux systems and not spending much (if any) time in Visual Studio 2019 or 2022 (though I will be in VS Code) for a while. However, if there's anything you'd like me to test out for you, please let me know.

[wmjordan]

@nurbles
Thank you for your time and feedback.

Oh, that is really bad.

I only tested C# projects and thought it was fine until I read your post.
I managed to reproduce your issue while I opened a C++ project.

Please download the new beta which should have fixed this.

EDIT: The new beta fixed the WYSIWYG code preview. However, it could not probably save/load the styles. Please revert to 7.6 at this moment. I will address it later when I have the chance to think and test it thoroughly.

[wmjordan]

The new beta 9263 should be correct now.
However, the new syntax highlight format is incompatible with previous versions, please keep your old backup in case of problems.