color scheme support #41435
Comments
JeffBezanson
added
display and printing
I suggested something like |
|
I thought it would be good to have a separate file for color settings since I feel like people will send around nice color themes and it would be good to be able to drop the file into the directory easily without overwriting other REPL settings. Perhaps that suggests a setup more like this: |
|
I think this is a great idea. It will:
The Problems In #40228, for example, user @nickrobinson251 finds that he has trouble seeing the filepath/line location of errors that are printed in muted grey (:light_black). I have no reason not to believe him. If Julia had a modifiable color scheme, he would be empowered to fix it himself. In addition, the existing color scheme is designed for people with normal vision. The incidence of color blindness is quite high - about 1 in 12 men and 1 in 200 women. 98% of those with color blindness are red-green color blind. Other people may have low vision due to contrast sensitivity or other issues. How Color Scheme Support Solves the Problems Accessibility of Julia would be improved for people with low vision by allowing customization of color schemes for people with low vision. I would hope and recommend that Julia would ship with four color schemes:
Technical Decisions Stephen asked a few questions -- for which I'll give my opinion, plus opinions on a few more things What needs to be specified? What format should the file for the color scheme be in? What does other software use? VS Code uses JSON, as they have significant hierarchy; for example: It looks like TextMate itself uses XML (barf): Should the user-color map completely replace the default, or just overwrite parts of it? What if they specify more hierarchy and colors in their color scheme? How should the color values be specified? You could require that they wrap it in hex(), or if it comes in non-hex, just convert it for the user. Or, strings of the named colors from the Colors.jl package. Of course, in addition to color, we have font weight as well: Anything else in the file? Semantic Coloring Some issues and pull requests have been input regarding semantic tokens and highlighting - #961, #1168, #847 . This would appear to be the best way to color output errors, etc. -- but perhaps it's too much to bite off at this point. In Conclusion [1] I actually think I threw up in my mouth a little bit. |
|
@blackeneth Nice writeup! The main reason to use TOML is consistency with other parts of the REPL (ie project.toml an dmanifest.toml). One thing to add is that it might provide a lot of value to let people map whole colors to other colors. This would make it much easier to customize if you basically like the built-in color profile, but want to change 1 color that is hard to read with the theme you use (looking at you solarized). |
|
One choice is easy: we are definitely using TOML, not any other configuration/serialization format.
The appropriate way to factor this is to have code that uses colors ask for something with semantic meaning, like "what color/boldness is the REPL prompt for shell mode" and then answer that question based on the config file. It would make sense for this to be open-ended so that packages like OhMyREPL (cc @KristofferC) can be configured this was as well. It would probably make sense to look at how TextMate color scheme work for this. I'm pretty strongly against putting any kind of executable code in this kind of config file. It's tempting because it's maximally flexible and avoids having to make real design decisions, but it's almost always a bad idea. For one thing, it would make this file a security attack vector 😬. For another it would require re-evaluating the entire file for every color decision since code is not generally pure so it might give different answers over time even if the file hasn't changed. Also, using We should probably also allow specifying display properties beyond than just those that are supported by terminals since we probably want to use the same color configuration mechanism for notebooks in the browser and maybe even other display mechanisms. That suggests maybe looking at CSS for display properties. |
|
Looking at http://web.simmons.edu/~grabiner/comm244/weekthree/css-basic-properties.html the properties that make sense to me are:
I don't think we need to stick with CSS syntax, however. I'm also not sure how much of CSS color syntax to support, there's quite a bit of it: https://www.w3schools.com/colors/default.asp Does anyone know if all the ANSI color names are supported in CSS? There are 140 color names supported in CSS. How do color fallbacks work in terminals? If we ask for a specific RGB color and the terminal doesn't support it, what happens? Do we need to specify a fallback or does the terminal automatically use the closest color that it supports? |
|
Decided:
Given #2, and the other discussion, I believe it is also decided that I would recommend the input be case-insensitive, so #6495Ed and "CornflowerBlue" would also be accepted. On Color Names ANSI color names are quite limited, and defined originally for ANSI escape sequences (and here). The ANSI colors are black, red, green, yellow, blue, purple, cyan, and white. Windows supports ANSI escape sequences and 24 bit color. Most of the "color name lists" out there derive from the original X10R3 list, with later modifications, and is often referred as the "X11 colors". The color names of crayons were often used. The sRGB color space (24 bit) is used. The named CSS colors are a superset of the SVG 1.1 color names. Note the comment on the CSS name color section:
See “Tomato” versus “#FF6347”—the tragicomic history of CSS color names There are many other color name dictionaries. Two of the best are probably ISCC-NBS (only uses names, designators, and categories) and Bang (and here) (which has fanciful color names). ISCC-NBS has 267 color names, and Bang has 678. Also popular is Resene 2010 , which has 1,378 color names. You see some of these systems listed in the W3 Color Schemes. For names, also need to decide if you're going to support "gray" (US) and "grey" (UK) names. Or, you could keep it super simple and support a very small set of names - red, green, yellow, blue, purple, cyan (6 colors), plus light/dark modifiers for each (12 more colors), plus black, white (2 more), and 8 shades of gray/grey (8 more). Total of 28 names. Every other color can be had by specifying the hex code. [1] What, no blink support? 😉 [for those too young to have been there, in the early days of the web, blink was over used on web pages and was very annoying -- such that every browser started ignoring the blink HTML tag] |
|
I would love to see a simple way to tell the REPL to use only the basic terminal ANSI colors (either 8 or 16). I think it's more common now with RGB terminals for people to set their preferred colors for the ANSI codes. Currently, there are various places in the REPL where extra colors are being used, e.g. stacktraces. I don't think more colors should necessarily be used just because they are available. |
Could you be a bit more specific about where those extra colors are being printed? AFAIU, we only use colors from the 16 ANSI colors in default Julia output. |
|
Woops, you're right, it's all using the base 16. I got confused because setting |
|
Why do we need fanciful color names at all? I can think of at least 3 reasons:
Easier to Remember than Hex Codes Julia has printstyled, which allows:
These are mostly the ANSI color names. If you want something else, you can specify an 8-bit color from 0-255. This is great--I can remember ":blue" and ":red" and make it easy to specify colors if I'm using Give you an idea of the hue, saturation, and lightness of the color Consider these two mocked-up config files. Using hex codes: In the above, I can figure out the first two are red and black; the rest I have little intuition for. Using color names: In the above, I am given better hints as to what the hue, saturation, and lightness is of each color used. Guide users towards good, or at least adequate, choices for color designs Users who don't want to learn about color theory may prefer to just choose from the color names available. Given that, the color names given to them could be selected such that the colors have uniform hue, saturation, lightness, and consistent variations thereof. Use of those colors would result is an adequate color design with no egregious problems. 24-bit Color 24 bit color is common today and should be supported. This allows the creation of beautiful color designs. It also provides flexibility for designing color schemes for people with color blindness, contrast sensitivity, or other low vision issues.
This is a graphic design issue. Bad color design is not uncommon. Excess use of colors can lead to an angry fruit salad color design. |
|
If I may say, this issue has actually two different layers:
(*) I use word API here in a rather generic sense, it can be a configuration file, dispatch functions, dictionaries of colors or anything else. By "applying colorscheme" i mean all those places, where instead of I think that while user layer is important, it is in some sense less important than the second layer. And the reason is the following: if I have a way to influence colorschemes some way, I am as a user can create any sort of package with any functionality I desire. Users can make packages which accept hex codes instead of human readable names, or they can use JSON instead of TOML or even they can upload configs from network in some binary form, it doesn't really matter for as long as there is a way to change themes. Of course, some way to work with themes should be presented in One possible way to organize this second layer is proposed in #41791: you put all your colors in a I am bringing it here, because even if #41791 is considered a bad approach and closed, I am thinking that the idea of decoupling configuration and usage part is important and a proper way to solve this issue. |
This seems like the most critical issue. Right now, there are lots of hardcoded colors in the standard library and core packages, most notably in Thus, all colors in core packages should have semantic keys in some kind of Julia colorscheme configuration. It would probably be a good idea to grep for It would also be great if the default values would take into account that people run both dark and light background terminals. Ideally, Julia could try to detect this, e.g. by looking for the standard |
|
Also, the color scheme should automatically transfer to the subprocess that |
|
Also, third-party packages should be able to register their own semantic color keys. Absent that, packages with color output would need to maintain their own config files. Having all colors defined in one central location arguably seems like a better solution. |
I don't think merging third-party package colors into the main color scheme file is a good idea. My understanding is that the main file will be environment-independent, so allowing packages to store information there will pollute other environments. I think it is better to have those packages that want colors implement a color scheme in the preference framework for the package (and that could be helped by an additional package someone were to write). |
|
"Having all colors defined in one central location" can become a disaster. Look at gtk/gnome. The "central location" has changed about 127 times since I started using gtk2 about 10 years ago. Takes days of trial and error on a new distro to figure out which of the ~/gtkrc*, ~/gtk*/, /usr/share/gtk/, , /usr/local/share/gtk/, /etc/gtk will actually change anything. And impossible to (eg) change the default theme on pacmanfm without also messing up firefox theme. Please don't do this. Each Julia program that wants to use custom colours should do it itself, within its own source files. |
One big reason why we are using the 16 base colors is that they are already themable! Just go into your terminal option and set them to whatever you want. |
|
That's a very tricky assumption, though. In a true 16 color terminal, those are all the colors you have to work with for both foreground and background. If you make yellow readable on white, you might make it unreadable, e.g., on a dark background in a status bar. I'd say, if you make assumptions about ANSI colors, assume that they are the default RGB colors for the different terminal emulators. I've certainly tweaked the ANSI colors in the past to be more aesthetically pleasing (pure cyan is particularly jarring), but changing their brightness values too much will inevitably break something. No matter how you slice it: at least without looking at I do take your point though that if you have to hard code values, using base ANSI colors is better than hardcoding RGB values. Still, by far the best option is to have configuration. Alas, I don't think anyone is really arguing against that, and this issue is just to flesh out the details (and some of my comments are just to create a small sense of urgency based on my personal mild frustration with Julia's color output on my admittedly non-fashionable white background terminal 😉) P.S.: I retract my comments about having third-party packages plug into the color configuration file. |
|
@brett-mahar, I don't think the fact that Gtk has totally bungled this is a particularly compelling argument for Julia not to have a single file that controls colors. In particular, Linux folks seem to have a fondness for pointless moving files around the file system that Julia has never been prone to. We're perfectly capable of picking a good design and a suitable location and sticking to it. |
|
After a lot of research, I have several updates Color Scheme File - TOML So I say abandon the fancy color names idea; just use hex codes. One is not going to be editing the file frequently. The TOML format would be something like this: The above is valid TOML file. You can read it into Julia as shown below. What will be created is a dictionary of dictionaries. Note how the TOML reader converted the Hex values to integers! Users could customize colors by putting whatever keys they want to change in a Note: While there is 1 Julia "default" color scheme, there would also be 3 more to support users with low vision:
About 10% of people have colorblindness, and MicroSoft reports that 4% of Windows users use a high-contrast theme. Determining Terminal/Console Color Capability This, alas, does not have a clean and tidy solution. Base has a function
OK, that determines if the console has color. But what color depth? As for what the foreground and background colors are, the Linux convention is again to set an environmental variable,
Where "15" is the 8-bit ANSI code for "white" and "0" is the 8-bit ANSI code for "black". This has a natural extension to 24 bit color:
For example, If you want to see your terminal's 24 bit color ability, the Crayons.jl package has a test function. Modifying Default Colors For Light Backgrounds
With 24 bit color support, this would be possible. I would restrict this adjustment to the existing ANSI colors that Julia currently uses (all other colors can be adjusted via the ColorScheme.toml file). The way it would work is to read the foreground and background colors from If the luminance contrast is less than 2.1, boost it up to 2.1. My testing has shown that any further boosting of the luminance will tend to change the chroma of the color severely. Here's how it would look like against two different white backgrounds.
Note that the ANSI white Julia uses is actually RBG(192,192,192). The only thing a little bit sketchy with the above is that the :white color is no longer white! Maybe that's a feature? Note that is contrast adjustment is not quite as nice when the console only has 8 bit color (this is on a white RBG(192,192,192) background):
Note you get some color shifts and :cyan is not fixed at all. It can probably be tweaked further, though. Packages Can Add Color Keys to Central ColorScheme File
I like the idea, not sure exactly how to accomplish it. I would think the Package manager would handle it. Packages would store a color scheme TOML file as an artifact. The package manager would download that TOML file, then append it to a One thing to avoid is multiple copies of package color keys being written to the packages_colorschemes.toml file. Say, for example, I deleted a package, then I installed it again. I wouldn't want the colors cheme to be re-added (note I'm assuming it wouldn't be removed when I deleted the package). The package manager could probably just check if the Packages dictionary is in the color "dictionary of dictionaries" -- and if it is, don't append the package color scheme again. @StefanKarpinski could provide some direction on a good approach here. |
|
@StefanKarpinski , fair enough! If the file stays in one place and is left in whatever format it was at the start, then most of my objection is gone. |
|
Thanks for making this more concrete... because this is actually not what I was thinking of as a "color scheme". I don't really want to change what "yellow" is. Instead, I'd like to configure what color/style should be used in different places. What I had in mind was a [Core]
# equivalent to JULIA_ERROR_COLOR etc
answer = ["black", "normal", "bold"]
warn = "orange"
error = "red"
info = 0x008080
[Shell]
prompt = "red" # color of the ;shell prompt
[Pkg]
prompt = "blue" # color of the ]Pkg prompt
action = ["green", "normal", "bold"] # for strings "Updating", "Resolving", "No Changes", etc
[Test]
passed = "green"
failed = "red"
summary = "black" # The "Test Summary" string that's currently "white"I suppose each entry should support foreground color, background color, and style (bold/underline); with different "shorthands" as I tried to indicate above (just one string/hex value would be the foreground color). Third party packages could have their own sections in this file. This file could be parsed into a global dict in Julia (similar to but separate from I would then simply extend printstyled("text", style="Test.passed")uses the style defined in the TOML file / internal dict. If there is no If you really want to, you could still have a sections I would however extend |
Users who have a white background, or a pale yellow background, very well might want to redefine what "yellow" is. Users with yellow-blue color blindness will certainly want to redefine what "yellow" is (as well as "blue"). Users with red-green color blindness will want to redefine what "red" and "green" are. The concept I'm following is: every color used is defined in the colorscheme.toml file. The only colors defined in code would be a small set of defaults used if the colorscheme.toml file could not be opened. TOML File Your example color scheme file is indeed not valid TOML. Your example: Is not possible -- there will be no "Test.passed". There will be a dictionary "Test" with keys "colors" and "styles", each which have keys that specify either a color or a style. Base.text_colors This dictionary won't change. It defines 279 names, most of them by number 1 - 256. Plus the symbols normal, :default, :bold, :black, :blink, :blue, :cyan, :green, :hidden, :light_black, :light_blue, :light_cyan, :light_green, :light_magenta, :light_red, :light_yellow, :magenta, :nothing, :red, :reverse, :underline, :white, and :yellow. This is for compatibility. Not every part of Julia will adopt the new color functionality at the same time. Semantic Colors Only The overarching concept is that code never specifies a color (e.g., :blue) or style (e.g,. :bold) directly -- instead, the colors and styles are read from a color scheme dictionary. My prior TOML example didn't have semantic colors for other functionality or packages, as I hadn't researched them yet. It only had definitions for the default colors in Julia. Here is the TOML file with some preliminary semantic color and style definitions for "stacktraces" Load it into Julia like this: Now, in addition to "base", we have another top level dictionary, "stacktrace". Now let's get the colors and styles dictionaries underneath "stacktrace": The colors also need to be post-processed to ANSI escape sequences. This is what Now the stacktrace styles Note that the stacktrace styles are booleans -- in contrast to base, in which they were ANSI escape sequence strings. This is because stacktraces make use of the This makes the point that how styles are defined can be module-specific. Some may want ANSI control sequences ("\033[1m" for bold), others may want booleans, or whatever. Using the Semantic Specifications Given the above, then, example calls to Fancy Color Names
Well, we could use fancy color names -- they would have to be defined in the It would require more post-processing to convert those fancy names to RGB(r,g,b) values. My proposal is to not define fancy color names -- just have users specify hex color values, 0xRRGGBB. Generic Semantic Colors Not every package developer would want to define their own color scheme for their package. For them, we could define a set of "generic" semantic colors. For example, we could add something like this to the |
That's fine... I don't mind if there's an option to change the definition of color names, in addition to which color names get used where. I'd just be primarily interested in the second part, personally.
Actually, it does happens to be valid TOML (not that that's what I was going for)! I don't think it would be very hard to flatten that into a dict Or, you could read the TOML it into a global
Please don't go down this road. I don't "need" to do anything. I appreciate that you've thought deeper into the details of the implementation, but that doesn't mean I can't engage in a conceptual discussion. Especially when your admonishments are factually unfounded!
Well, it's definitely possible, as I explain above.. You'd just have to transform the TOML into the internal dict a bit more than just reading it in. Or, use a slightly different argument for
Right, and in fact I was proposing not to change
I don't think our proposals are very far apart then. I'm not strongly invested in any particular details... as long as for every colored string that gets printed by the core packages, there's a setting somewhere where I can change the color/styling of that string (without redefining the definition of the color)
I'm not sure I could follow all those details, but it still seems to me like it would be elegant to have the semantic colors/styles available in printstyled("text", style="Test.passed")if you process the original TOML, or printstyled("text", style=Core.colorscheme["Test"]["passed"])if you just load the TOML into a global
I think that's an excellent idea! |
Speaking as someone who is partially red-green color blind, I NEVER redefine what the actual colors are - I will just change the color associated with an object to be something else. Changing what "red" is will cause me more annoyance than actually just using the original color scheme with red in it. Simply redefining the color to a different can create a lot of problems when color mixing happens, because the resulting colors will also all change. IMO the better (and more standard) way of handling color blind accessibility is to design a theme distinctly for those users, not by redefining what the base colors are but by reassigning the higher level mapping to use different base colors. |
Woah, please cool it a bit here. First, the TOML example is valid. Second, I don't think anyone should have to become a TOML expert before they can express an opinion here.
This is perfectly possible. We can interpret |
|
Just as a note, putting raw ANSI codes in a TOML is unlikely to be a good idea. You want something higher level and then it is up to the system displaying the color to decide how that is done. |
|
Especially since we want these styles to be applicable not only in the terminal but also in HTML-based environments like Juypter and Pluto as well as elsewhere that we haven't thought of yet. |
Maybe worth noting that this is both more and less general than current code. More, in that the present code doesn't apply colour to half these things. Of course it could be generalised to break things up into many more separate print statements each referencing the appropriate global options (whose names are documented somewhere). But deciding to do that widely sounds like a step beyond just building a mechanism for adjusting existing colours. And less, in that modules aren't one colour. They are drawn cyclically from a list |
|
I realized that |
|
We can always add capabilities to |
|
I would also point out that what I have in mind would be easy to implement progressively in a series of separate PR's. In particular, it would be easy to get started without much impact on the code base, and no impact on the user-facing parts of Julia PR 1
If with_output_color(f, color, background, io, args...; kwargs...)the values of I think that's all there is to get started. I could make that PR pretty easily! PR 2Go through the code base, and for every instance where At that point, all changes would be completely internal, but that would already be sufficient to have a "hackable" theming support, in the same way that people currently modify PR 3Add support for a Also, if the same TOML should also have a section to redefine color names as @blackeneth proposes (presumably modifying This is where the internal changes become user-facing and need documentation. There's also lots of technical details that would need to be addressed here or in a subsequent PR, such as watching and reloading the file, modifications to the environment variables and/or command line flags Julia uses, etc. Those would definitely be out of my league in terms of the required familiarity with Julia's internals. PR 1 is pretty easy, though, and PR 2 is easy but a bit tedious. There could also be a PR 4 that adds an interface for third-party packages to define their own keys into @StefanKarpinski let me know what you think and if I should submit "PR1". Someone else might have to help with "PR2" and definitely with "PR3". |
The following would probably be pretty good (except for obscuring the keyword arguments in the function printstyled(io::IO, msg...; namedstyle::Union{Nothing, String}=nothing, kwargs...)
if namedstyle ≠ nothing
style = named_styles[namedstyle]
properties = merge(style.properties, kwargs)
color = pop!(properties, :color, style.color)
else
properties = copy(kwargs)
color = pop!(properties, :color, :normal)
end
with_output_color(print, color, io, msg...; properties...)
end |
|
Wow, a lot of great input and ideas. Fancy Color Names Then @StefanKarpinski mentioned:
Well, that clinches it. It also means we need to use the W3C CSS3 or CCS4 color lists. Might as well packages define their own custom color palettes as well (see below) Color Cycling Well, let me say - it's an "example," not a "proposal". Someone who knows the stacktrace coloring much better than I would have to define to actual keys. So if I added "more," feel free to disregard it. However, you comment on "less" brought forth another requirement -- color cycling. A tuple of colors to cycle through. Accessibility @imciner2 gave some perspective as someone who is red-green colorblind. I really glad you came by to give some input. Not being color blind myself, I've been following the published guidelines for colorblind support. Highly valuable to have the input of someone with actual experience. Let me ask you a couple of questions if you don't mind:
Yes, I think that is where we want to get to. Until that is achieved, some people might want to redefine base colors. Either because they want higher contrast (move :red from (128,0,0) to (255,0,0)) or for their light background. However, the I would say the reason the base colors are in the TOML file isn't because I would expect a lot of people to redefine them. The reason is to just completely separate the color definitions from the code. It always seems if something is hard coded, someone always wants to want to change it to be configurable. So just get all the color definitions out into a file. TOML Format I think the only exception might be in [base.styles], as those definitions are just replacing Julia code. Otherwise, use "bold", "underline", etc. ... and since we're reading in color name strings ("cornflowerblue"), might was well allow HTML hex codes ("#RRGGBB") ... and since we'll the CSS3/4 color names, might as well let packages define their own custom palettes for their private use. Below you will see definitions for an imaginary package "weigart", which defines a private palette. That private palette can then be used in the [weigart.colors] section. ... and packages can refer to colors from [base.colors], but not from other packages private palettes. Also below in [stacktrace.colors], see a tuple of colors defined for "module" for color cycling. Let me add that the above file is designed to have as "flat" a structure as possible. If people prefer more hierarchy, well ... that could work too. |
|
That TOML file is 100% compatible with my implementation outline. It’s maybe a bit more verbose (due to being “flat”) than what I was considering, but I’d be perfectly happy with either format, or anything similar. In any case, the exact TOML format wouldn’t have to be nailed down until “PR3” in my outline |
|
@goerz Regarding PR1: Ah, I see where you're going. You want more complex style you pass along, and it specifies everything. Just pass that one thing along, and it has it all. My approach is much simpler: the ability to look up a color for an element. Think simple programming. Very simple. Say I can look up in a dictionary, "pathcolor" Then I use it as follows: Ideally, the TOML format could support both. Package developers have varying levels of programming ability. Some may want to define named styles, others may just want to grab some colors. |
|
I understand... My motivation was more like "what is the minimum amount of code I'll have to change". Hence, I'm grouping collections of color and styles together with a single semantic name, and then I just have to give For what you have in mind, you'll want to keep all of the information from your TOML file separately accessible, so that a developer could look up a semantic color separately from a semantic style (bold etc). That's obviously more flexible. Although strictly speaking, even with my proposed global const named_styles = Dict{String, NamedTuple{(:color, :properties), Tuple{Union{Symbol,Int}, Dict{Symbol, Bool}}}}someone could still do It'll be up to the maintainers (@StefanKarpinski) to decide what internal structure they'd prefer. |
|
I didn't explicitly take into account color cycling for e.g. stacktraces, but for that, I would do modulestyles = Iterators.cycle(["stacktrace.module1", "stacktrace.module2"]) # ...
for (style, modname) in zip(modulestyles, modulenames)
printstyled(modname, namedstyle=style)
end |
|
Technical Notes The ANSI escape sequence syntax for 24-bit color is: For example, The input formats we have discussed so far are:
Color Storage Formats ANSI in-band escape sequences need color information as RGB(R,G,B) -- for example, (100,149,237) -- so the escape sequence ESC[38;2;⟨r⟩;⟨g⟩;⟨b⟩m can be constructed. HTML users may prefer the fancy color name, "cornflowerblue", or the Hex code, "#6495ED" -- as these plug more directly into HTML/CSS code. Data Structures That leads to the question -- should we have parallel data structures for colors? Some that store color as (100,149,237), another that stores it as "#6495ED", and another as "cornflowerblue"? Or do you pick 1 color format, and convert it on the fly as needed? |
As suggested here: #41423 (comment) it would be good to support theming Julia's colors. There's also #41295 but I think that may overcomplexify things. Without @staticfloat's input, I'm not entirely clear on how using Preferences in Julia would work, whereas I have a pretty clear idea about how adding a config file to theme Julia's colors would work: Instead of hardcoding colors, if Julia is run in color mode, it would look in a file called
~/.julia/config/colors.tomlthat maps uses of colors as keys to some kind of color description as values. Here are some questions:#123abcstrings? ANSI color names? Either?I think for usability we'd probably also want to have changes to this file take effect immediately, so we'd want to remember the inode, size, mtime and ctime and if any of them changes, reload the file. We also want to take care that if we're not using color the file never needs to be looked at.
The text was updated successfully, but these errors were encountered: