Monokai.tmTheme edit for selection background colors

[mark.stewart]

Can Sublime show different background colors for cursor-location selection and for other same text strings in the document?

I am maybe a little color blind, and so right now if I select say “blockquote” and all “blockquote” words in an HTML document are highlighted, then all of the words “blockquote” look the exact same background color and foreground color to me. Where are the key-string sections in Monokai.tmTheme to edit the background and foreground to differentiate color for selection at cursor-location and color for same-word not selected but highlighted by Sublime?

I have found these keys, but I am not sure if they are what I am looking for:
selection
selectionBorder
There could be other relevant keys too.

[FichteFoll]

You’re probbaly looking for these: http://docs.sublimetext.info/en/latest/reference/color_schemes.html#find

I’m not entirely sure that these will do it. I do remember having problems dertermining what a few exotic settings were doing and am not 100% sure our docs are correct.

[RiverLeaf]

FichteFoll… et al. Thank you. Your resource link does not answer the question.

Sublime Text Unofficial Documentation – Topmost Elements in Color Schemes Files – Find (see also – Selection)

There are two (2) distinct XML formats for theme coding: the old (simple) ST2 theme topmost element section or ‘forward’ XML includes an easy two-line XML format key-string - the ‘forward’ is followed by multi-line dict fork XML, relative gibberish to a Chimp (designer), gibberish being used to complete the rest of ST2 theme files and all of the new beta ST3 theme XML. The dict fork stuff is obviously more technical, programmatic. I don’t mean to be unkind at all! Machine forking gibberish is for more technical users who can fly through code jungles like Gibbons. Me, clumsy chimp I’m afraid (feet up, sipping tea).

Sublime Chimp code ‘forward’
<key>findHighlight</key>
<string>#11262c</string>
<key>findHighlightforeground</key>
<string>#c9e0f9</string>

Sublime Gibbon finesse ‘fork-zone’
<key>name</key>
<string>User-defined constant</string>
<key>scope</key>
<string>constant.character, constant.other</string>
<key>settings</key>
<dict>
<key>foreground</key>
<string>#AE81FF</string>
</dict>

Perhaps it would help to more clearly isolate Chimp and Gibbon code into two separate XML segments in the theme file, one for the programmer Gibbons, another (existing forward) for the designer Chimps. Give Chimp expressions absolute priority over the Gibbon moves. Let Gibbon moves do more intricate things with the Chimp ruckass. Complicate Chimps and Gibbons with separate XML files for each? In any case, update Unofficial documentation to catalog all of key-and-string ‘forward’ combos that can be safely edited, without irritating the Gibbons. Personal exploration: half of what’s added to the Chimp zone is ignored by Sublime.

A key value common in most themes might not be included in the edited theme. Sublime in the background should add support for any key value from the [needed! for public] list of ‘registered key values’, when that key is added by public to the edited theme. Conversely, Sublime would then remove suppport for any key-string topmost element removed by Chimp user. Gibbon support likewise regulates used/needed in the theme when key is removed from “light” or “dark” theme’s topmost element area. Regardless, a new policy is required where each theme includes packagecontrol.io documentation listing key names for all Chimp ‘friendly’ key values for each theme, implemented retroactively. Programmatically, editable topmost elements in theme file should be commented string list comma separated at top of theme file. Each Gibbon authoring a theme, required to keep theme ‘Chimp friendly’ with in sync list check (prn update/correction) when saving the authored theme. Calm in the jungle!

BTW, concerning the complaint that launched this thread, the issue relates to standards-based display settings. as I noted above (flagged by some inebriate as inappropriate and hidden), CAD works fine with Sublime in Monokai except for the findhighlight-findhighlightforeground. Since Monokai is the Sublime pet, and sine on to the fact that there are millions of CAD displays out there, Sublime might want to address that issue which I very kindly pointed out. Not hide its Chimpy head in the sand. Where is the public Chimp ‘friendly’ list of all “Topmost Elements”, i.e., default themes ‘forward’ area key names, please?

Sublime also needs a new ‘forward’ default key-string. Visually, similarshighlight-similarshighlightforeground. That missing structure could help to fix the current Sublime defect in CAD dislay. An architectural review. HTH

machine: mac pro 6-core dual d-500
display: benq bl3200ph

[RiverLeaf]

Apparently folks love your 3127 colors. So you can probably make sense of CAD same_as_selected_word words crisis. The solution was as expected 100% hinkey (sorry). Fresh OS Sublime setup (smell those lovely spring flowers!): Theme Soda SolarizedDark then Theme Monokai then Sublime color scheme Solarized (Dark). I hear you… CRAZY!

But here is what happens. SolarizedDark dumps a lot of beautiful default Sublime Monokai code theme extras. Forcing Theme Monokai like this brings back Monokai extras. Something even hand coding the new ST3 XML ‘dict’ forks cannot do. Sublime loves that real WHOMP thing!

FYI Apple Sierra is not only having issues with FontBook and local web aliases flunking, also wasted screen font aliasing. That’s why font_options no_round (noting that Wilma Mankiller and Katherine Weiss jointly declared, “no_round makes no_sense,” in 2002 - milestone typography advances aside, for Sublime no_round makes code easy to read and sub pixel_antialias is sensible insurance around Apple these days. Otherwise, all other packages and settings specifically fix issue advanced in this thread. Notice that Sublime automatically removes Theme Monokai from User Settings, where it was placed, while retaining some Extras like fixed highlight.

{
“color_scheme”: “Packages/Color Scheme - Default/Solarized (Dark).tmTheme”,
“font_face”: “Menlo”,
“font_options”:
[
“subpixel_antialias”,
“no_round”
],
“font_size”: 14,
“highlight_line”: true,
“ignored_packages”:
[
“Vintage”
],
“match_brackets_angle”: true,
“tab_size”: 2,
“theme”: “Soda SolarizedDark.sublime-theme”,
“translate_tabs_to_spaces”: false
// font_options no_antialias gray_antialias subpixel_antialias no_round
// highlight_line allows to see focus in multiple windows
// match_brakets_angle makes tag coding easy
// translate_tabs_to_spaces stops Sublime adding spaces on re-open
}

<key>selectionBorder</key>
<string>#99ccff</string>
<key>inactiveSelection</key>
<string>#0099ff30</string>

BenQ 1.2 billion colors CAD

BenQ 1.2 billion colors RGB (Adobe/MIT 2015)

Previously, 3126 CAD selection and same_word looked identical, without the Monokai trick.

Kindly refer to my CHOAS club follow-up.

[RiverLeaf]

Right indeed you are, Fichte! Some very gifted themers discover amazing things. Take Daniel Siepmann info@layne-obserdia.de ‘Nice Blue Soda, so much unpacks un-themable… until you plug in Hammer Theme’s Operator, Misc’ with this:

<string>keyword.operator, constant.other.color, punctuation, meta.tag, punctuation.definition.tag, punctuation.separator.inheritance.php, punctuation.definition.tag.html, punctuation.definition.tag.begin.html, punctuation.definition.tag.end.html, punctuation.section.embedded, keyword.other.template, keyword.other.substitution</string>

rainbows everywhere!

WISHLIST ST4 includes theme doctor, to keep rainbows shining.