Repository: spyder-ide/spyder

Issue:
Improve "Spyder Dark" syntax highlighting theme
<!--- **PLEASE READ:** When submitting here, please ensure you've completed the following checklist and checked the boxes to confirm. Issue reports without it may be closed. Thanks! --->


## Overview

Currently, the text colors of Spyder-Dark don't look too good, mostly because the color choices were designed around the light background and don't look good in the dark one. Furthermore, a major user desire on #2350 for their dark syntax theme to match the colors in the rest of the UI, etc. match those elsewhere in the UI so Spyder maintained a cohesive and seamless look. None of the built-in themes come even close, and have a number of related and other problems as well (full rationale reproduced below, for posterity's sake and to keep #8266 cleaner).

Therefore, I'd recommend replacing the current Spyder Dark colors with a much better set tuned to its new dark UI theme. As a matter of fact, I already have such a theme that I have been using across many different editors (Spyder, Rstudio, Notepad++, etc) and a myriad of document types for the past year and a half, and only needed a few minor tweaks to strategically pick up the appropriate colors from the rest of the UI for the new Spyder Dark theme.

![image](https://user-images.githubusercontent.com/17051931/48866619-0c7b8180-ed99-11e8-960b-95cb2d5c43e2.png)

What do you think about that as a starting point for replacing the current colors of the Spyder dark theme? Feedback or suggestions about where we should iterate from here @jnsebgosselin ?

----

## Details

![image](https://user-images.githubusercontent.com/17051931/48866606-f968b180-ed98-11e8-9bcc-2ecbda24973f.png)

The overall design is a sequence of red for keywords, orange for builtins, yellow for class and function definitions, light tan for instances, and finally white for variables and function calls, to create a conceptual hierarchy from fundamental constructs down to individual variables. Numeric literals are cyan and string literals are green for strings (to contrast well, and with colors matching their appearance in other themes and their conceptual "feel"), and comments are a desaturated mauve to look "lighter" than and clearly distinct from the rest of the executable content but still be very legible. Most of these colors also, incidentally, echo lighter versions of the ones used for the value column in the Variable Explorer. 

Meanwhile, the background matches the pane background color, the side panels match the dark gray variable explorer name (and df index) column color (vs the standard foreground UI color) for a more subtle, modern look and better contrast with the line numbers, while the current line color matches the lighter gray in the type/size column and used for the background of objects, true/false in the VarExp Editors for something more visible at a glance that doesn't overly distract or reduce contrast on the text too much.

The occurrence color is a lighter and more cyan version of the standard selection color, to balance contrast with the dark background and with the light text colors, and balance distinctness and conceptual linkage with the main selection color. The cell color is a slightly darker and purpler version of the background, to both increase contrast and subtly draw the eye to the active cell, while maintaining a conceptual link to the purple-colored cell separator comments and horizontal rules. Finally, the matched and unmatched paren and link colors are just modestly lighter variations of what they are in the current dark theme, for easier visibility.

Here is the full theme, which can be pasted in your config file:

<details>

```
custom-1/background = #1a222f
custom-1/currentline = #31363b
custom-1/currentcell = #17172d
custom-1/occurrence = #509ea5
custom-1/ctrlclick = #179ae0
custom-1/sideareas = #222b35
custom-1/matched_p = #0bbe0b
custom-1/unmatched_p = #ff4340
custom-1/normal = ('#ffffff', False, False)
custom-1/keyword = ('#ff5855', False, False)
custom-1/builtin = ('#ffc341', False, False)
custom-1/definition = ('#ffff7f', True, False)
custom-1/comment = ('#aaaaff', False, False)
custom-1/string = ('#50ff50', False, True)
custom-1/number = ('#88ffff', False, False)
custom-1/instance = ('#dcb886', False, True)
custom-1/name = Spyder-Dark-V2
```

</details>

----

## Comparison Screenshots

I encourage you to test each theme for yourself, since these small screenshots obscure a lot of smaller issues with each theme and make it difficult to fully grasp how they'd look full-size and full-screen.

### Current Spyder-Dark:

![image](https://user-images.githubusercontent.com/17051931/48864881-91639c80-ed93-11e8-88e2-e67400cc5720.png)

### This Proposal:

![image](https://user-images.githubusercontent.com/17051931/48864954-bce68700-ed93-11e8-9f15-c1511081676e.png)

### Emacs:

![image](https://user-images.githubusercontent.com/17051931/48865611-be18b380-ed95-11e8-9b9e-33ae1f04bd69.png)

### Monokai:

![image](https://user-images.githubusercontent.com/17051931/48865665-ea343480-ed95-11e8-9344-eb8df3129d12.png)

### Solarized Dark:

![image](https://user-images.githubusercontent.com/17051931/48865730-19e33c80-ed96-11e8-8c3d-4ca41a4b0a30.png)

### Zenburn:

![image](https://user-images.githubusercontent.com/17051931/48865774-341d1a80-ed96-11e8-8eeb-9f3a5a986c4d.png)

----



## Full Rationale (for reference)

* Their colors look really out of place with the Spyder UI's own dark theme—Monokai and especially Zenburn are much too light and have a very warm hue, Zenburn is bright cyan, and Emacs is pure black, while the Spyder UI is a mild bluish-gray. None of the colors, synchronize with or even really complement the UI colors. Furthermore, in #2350 users have expressed a clear preference for a default Editor BG matching the standard panel BG.
* Each of the various themes have different contrast issues when implemented within Spyder's dark UI theme, making some text in each (comments/cell names, line numbers, etc) very hard to read, even with a good display and glasses
* Most proper editors and IDEs I'm aware of usually come with their own stock syntax theme that meshes with their UI colors—e.g. Rstudio, VSCode, Atom..—all their dark themes look like a natural part of the UI and pick up many of the same colors, not a bolted-on, stylized third party choice
* The proposed theme (and even Spyder-Dark) looks much closer to the default dark themes of those other editors than any of the third-party ones, irrespective of UI color
* We want the default look to be as "neutral" as possible, so it attracts the widest range of users (who might be put off by more heavily stylized look one way or another) as well as doesn't distract from the rest of the Spyder UI
* It gives users an easy and obvious way to switch back and forth between dark and light syntax themes, without having to manually flip through ones checking if they are dark or light, and prevents users being dissatisfied if they switch to the current bad Spyder Dark
* The low contrast overall of all the themes but Emacs can make text more difficult to read, particularly for users with colorblindness, vision or other accessibility problems and those with less expensive monitors. At least our default theme should be relatively accessible to a wide variety of users.
* Not picking one of the big, popular, stylized themes over the others as a default doesn't get people riled up who prefer one of the others or think we're favoring one
* If our own dark theme looks bad enough to not be considered for the default, why even bother including it without improving it? 




Discussion:
@ccordoba12 Do you want me to link this to #8068 or not?
Yes, please. Thanks!
@CAM-Gerlach, I think your proposed changes are very similar to the Atom theme:

![imagen](https://user-images.githubusercontent.com/365293/48874256-4d3ac100-edc0-11e8-89c7-20ab2c243765.png)

so I'd prefer that one instead. This is because the green and yellow you're using are too strong for my taste, whereas the Atom theme ones are lighter. 
> I think your proposed changes are very similar to the Atom theme:

Interesting coincidence, I'd never even heard of Atom when I originally came up with them and I've never actually seen Atom's native theme before you showed me that (since all I could readily find on their website was Atom skinned in various different colors). However, the basic design is indeed similar, although many of the specific color choices are different and Spyder's syntax highlighting likely behaves somewhat differently, at least from what I can see there. Its a good sign that its similar, since we want to it be pretty comparable to other modern editors/IDEs (Atom, VSCode, etc).

> so I'd prefer that one instead.

Are you saying we should switch full-on, or just those two colors? If the former, any particular reason why we should switch full-on, other than the green and yellow being too intense (which I'm happy to fix)? For starters, if you can point me to some canonical source of the default theme colors for everything, I can create a Spyder theme based on those basic colors for us to look at and compare. As it stands, despite some Googling I can't find a clear resource that states them so I have no way of properly evaluating, never mind fully implementing this suggestion. Thanks!

> This is because the green and yellow you're using are too strong for my taste, whereas the Atom theme ones are lighter.

Sure. The above image was a JPEG and so the colors aren't exact, but I could could measure them pretty closely with Photoshop and attempted to reproduce something similar in the current proposed theme. For the green, I dropped the saturation to near their lower value, and pushed the hues to something closer to their yellower tone. I didn't reduce the brightness down to their level, since it became a little hard to read.

As for the yellow, theirs actually had a higher saturation than those here, but I dropped the latter even further as well as a modest reduction in the brightness close to theirs. I only made a more modest shift in the hue (theirs is much closer to orange) because as you can see in the above screenshot, it is quite difficult to distinguish between that and orange, especially if they weren't right next to each other.

Let me know what you think:

![image](https://user-images.githubusercontent.com/17051931/48876344-2af67280-edc3-11e8-9c64-c67a50730270.png)

![image](https://user-images.githubusercontent.com/17051931/48876351-35187100-edc3-11e8-8bb4-1dde3ba35fed.png)

![image](https://user-images.githubusercontent.com/17051931/48876333-17e3a280-edc3-11e8-9f3a-e3468629fedb.png)

> Any particular reason why we should switch, other than the green and yellow being too intense (which I'm happy to easily fix)?

Yes. None of us is a graphics designer, so I really prefer to use an existing theme instead of trying to invent one by ourselves.

> Furthermore, we would either make our default theme "Atom" which would be weird

The theme is called `One Dark Pro`, so no Atom name would be involved:

https://marketplace.visualstudio.com/items?itemName=zhuangtongfa.Material-theme

> I don't see the harm in it looking similar in principle (as it already does independently), but different in details, particularly considering a lot of those details need to be necessarily different because of the differences between the software and our dark theme palette

I don't see anything wrong with introducing differences in our theme to adapt it to our own palette.

> For starters, if you can point me to some canonical source of the default theme colors for everything, I can create a Spyder theme based on those basic colors for us to look at and compare.

Please see the page I referenced above. It's GH repo has the theme colors and how they are applied.

I think you should open a PR for it, so we could continue the discussion there.
>  None of us is a graphics designer, so I really prefer to use an existing theme instead of trying to invent one by ourselves.

Great point. Its certainly good to take advantage of an existing design by someone with more expertise than us, if practicable, and it also helps people who are familiar with that popular theme to adapt more easily. On the other hand, compared with VSCode (which is built on very similar CSS/JS frameworks to Atom), it won't be entirely trivial to adapt it since I'll need to manually find and extract the relevant colors from the CSS and JSON, and a fair number the colors on our side don't either don't have direct equivalents, or are dictated by our different UI scheme (e.g. current cell, current line, background, side areas, occurrence, links...). Furthermore some colors, like comments, will likely then need to be tweaked to retain sufficient contrast with your background, cell, line and highlight/selection color.

> The theme is called One Dark Pro, so no Atom name would be involved:

Thanks! FYI, ODP is the unofficial VSCode addon; the original version is called One Dark and is available [here](https://github.com/atom/atom/tree/master/packages/one-dark-syntax).

> I don't see anything wrong with introducing differences in our theme to adapt it to our own palette.

Sure, we lose a lot of the benefits of adapting a single coherent theme created by a expert designer, and this solution tends to look more and more like the alternative, iterating what we have to adopt colors we like from One Dark where desired.

> I think you should open a PR for it, so we could continue the discussion there.

Okay. What I could do is add both this theme and Atom's (with the needed baseline alterations/additions) and then we can compare them directly. If we end up going with this one (as Spyder-Dark or whatever), we can still keep One Dark as a user-selectable option, while if we got with one dark we can fixup the Git history to just remove Spyder Dark instead (since there's no point keeping it if it looks bad, isn't even coherent with our UI and isn't our default). What do you think @ccordoba12 @jnsebgosselin ?
> and this solution tends to look more and more like the alternative, iterating what we have to adopt colors we like from One Dark where desired.

Yeah, we can't use plain One Dark because we need to adapt it to our needs.

> What I could do is add both this theme and Atom's (with the needed baseline alterations/additions) and then we can compare them directly

Ok, I think that's a good plan.
@dalthviz, please work on this one. What we need here is:

1. Add "One Dark" to our default set of themes. Please use for the background the same color used by QDarkstyle.
2. Make "One Dark" the default theme.
If we've all firmly decided on that approach, we should also remove ``Spyder Dark`` as part of this since it makes no sense to have as "our" theme one that A. looks, bad, and B. isn't even the default. We should also consider calling our version of One Dark something like "Spyder One Dark" since it will need substantial alternations from the original to match the Spyder UI as mentioned, and to make clear its not a modified version of the original adapted for Spyder and not officially endorsed by the creators (just like the unofficial VSCode port is called "One Dark Pro").
>  we should also remove Spyder Dark

Ok, no problem.

> We should also consider calling our version of One Dark something like "Spyder One Dark"

Sure, no problem.
On a second thought, @dalthviz please work on top of the "Spyder dark" theme, i.e. don't remove it or rename it to "One dark".

Resolving patch:
diff --git a/spyder/config/main.py b/spyder/config/main.py
--- a/spyder/config/main.py
+++ b/spyder/config/main.py
@@ -471,7 +471,7 @@
               'names': ['emacs', 'idle', 'monokai', 'pydev', 'scintilla',
                         'spyder', 'spyder/dark', 'zenburn', 'solarized/light',
                         'solarized/dark'],
-              'selected': 'solarized/dark',
+              'selected': 'spyder/dark',
               # ---- Emacs ----
               'emacs/name':        "Emacs",
               #      Name            Color     Bold  Italic
@@ -589,22 +589,22 @@
               # ---- Spyder/Dark ----
               'spyder/dark/name':        "Spyder Dark",
               #           Name             Color     Bold  Italic
-              'spyder/dark/background':  "#131926",
-              'spyder/dark/currentline': "#2b2b43",
-              'spyder/dark/currentcell': "#31314e",
-              'spyder/dark/occurrence':   "#abab67",
-              'spyder/dark/ctrlclick':   "#0000ff",
-              'spyder/dark/sideareas':   "#282828",
-              'spyder/dark/matched_p':   "#009800",
-              'spyder/dark/unmatched_p': "#c80000",
+              'spyder/dark/background':  "#19232D",
+              'spyder/dark/currentline': "#3a424a",
+              'spyder/dark/currentcell': "#17172d",
+              'spyder/dark/occurrence':  "#509ea5",
+              'spyder/dark/ctrlclick':   "#179ae0",
+              'spyder/dark/sideareas':   "#222b35",
+              'spyder/dark/matched_p':   "#0bbe0b",
+              'spyder/dark/unmatched_p': "#ff4340",
               'spyder/dark/normal':     ('#ffffff', False, False),
-              'spyder/dark/keyword':    ('#558eff', False, False),
-              'spyder/dark/builtin':    ('#aa00aa', False, False),
-              'spyder/dark/definition': ('#ffffff', True, False),
-              'spyder/dark/comment':    ('#7f7f7f', False, False),
-              'spyder/dark/string':     ('#11a642', False, True),
-              'spyder/dark/number':     ('#c80000', False, False),
-              'spyder/dark/instance':   ('#be5f00', False, True),
+              'spyder/dark/keyword':    ('#c670e0', False, False),
+              'spyder/dark/builtin':    ('#fab16c', False, False),
+              'spyder/dark/definition': ('#57d6e4', True, False),
+              'spyder/dark/comment':    ('#999999', False, False),
+              'spyder/dark/string':     ('#b0e686', False, True),
+              'spyder/dark/number':     ('#faed5c', False, False),
+              'spyder/dark/instance':   ('#ee6772', False, True),
               # ---- Zenburn ----
               'zenburn/name':        "Zenburn",
               #        Name            Color     Bold  Italic
@@ -751,7 +751,8 @@
 #    or if you want to *rename* options, then you need to do a MAJOR update in
 #    version, e.g. from 3.0.0 to 4.0.0
 # 3. You don't need to touch this value if you're just adding a new option
-CONF_VERSION = '47.1.0'
+CONF_VERSION = '47.2.0'
+
 
 # Main configuration instance
 try:


Test patch: