Need user preferences for near-invisible widgets

[GlenPerkins]

Bracket matching is nearly invisible (opacity: 0.1!) and secondary cursors are nearly as bad, and it's unclear whether these things are even themable. Whether they are or not, you shouldn't have to go searching for a whole different theme or learn to build your own themes just to make a basic widget usable.

You could start by just putting a few of these in the global preferences, ex: Bracket matching style: [outline, underline, background] Bracket matching color: [rgba()] Secondary cursor width: [1px, 2px, 3px] Secondary cursor color: [rgba()]

Just those two would be a great improvement, but an even nicer approach would be an additional user settings file (like Atom's "styles.cson") that offered a large selection of options for styling non-themable items and overriding individual settings in the current theme. Some things such as the subtle distinction between 2-shade highlighting schemes (ex: all found items vs. the one current found item) or the faint ghost outline used by some themes as the current line highlight are too subtle to see at a glance, even with good vision, and it would be great if we could make it easier for users to see comfortably (or distinguish shades of color) by simply filling in a few style: [x | y | z] or color: [rgba] settings in a "styles overide" file rather than requiring a time-consuming detour from your real work into research on the issue of what can be themed and how.

[alexdima]

@GlenPerkins I agree, the current theme story only really covers token colors and a bit of the generic editor concepts (selection color, etc.).

We have to revisit this and figure out how we can make it possible for someone to change all of the built-in styles in a "sane" way.

In the meantime, I pushed a simple change that makes the bracket matching more visible in the dark theme.

[GlenPerkins]

Alexandru, thank you. As you know, style isn't just esthetics; it can enhance or destroy usability. If I'm momentarily confused about the role of some piece of an overly deep hierarchy, the speed and likelihood of recognition of my error can depend on the salience of the bracket matching highlight: how much it jumps out at me. Many such features can vary from annoyingly distracting to very helpful to barely usable to utterly useless depending on visibility, and visibility can depend on highly variable factors (ex: sun's glare at different times of day).

An easy way to make style adjustments is a major advantage for an editor, and I'm glad you are looking for a "sane" way to do it. I like the fact that Atom lets me specify a style for almost anything in its "styles.cson" file, but I don't like having to puzzle through how to describe "matching bracket" in terms of their CSS selectors involving multiple classes describing the text layer, selection layer, background layer, DOM vs shadow DOM, etc. I would MUCH rather it just offered me "Matching bracket style: [options]" and let me just specify the options (border/underline, thickness, color).

I'd love to see a gradual rollout of a layered approach to styling, offering ability to:

1) Select theme; easily switch themes whenever you like (already does this) 2) Easy item-by-item overriding of the style of each browser widget and syntactic category in the current theme (comments, strings, keywords, etc.); you are offered the categories, so you don't have to figure out how to specify them yourself; you can take the combination of original theme and your custom overrides and "Save as..." a new theme, which you can then switch to at any time using mechanism 1). 3) Write a little code (in something common like JavaScript, which also offers built-in regex) to add your own custom, named "syntactic categories" (using the term loosely), whose style you can then specify with the mechanism in 2). These would just be code snippets stored in a prefs file that VS Code would use as definitions of additional syntactic categories available for styling. For example, you define an "AlertWords" category that's just a customized list of strings ("TODO", "FIXME", "CAUTION", etc.), or "DateTime" that recognizes your style of timestamp, or an "EmbeddedJS" that can be used to give JS inside an HTML doc a different background color. This isn't a full syntax parser, just an override mechanism for adding a few features to an existing parser (or all parsers). Users could just share these code snippets in a discussion forum ("just put these lines in your syntax prefs to highlight timestamps...") instead of having to write and install "extensions".

[GlenPerkins]

The new theming system takes care of this. Thanks.