11 ms·

No_color

• treve 3y ago
  This is interesting, and standardization is great. but I'm also curious why they cared. Most CLI tools will not output color when piped to something else, so I'm curious if this was created to fix a peeve or if there's other practical benefits.
  • drewtato 3y ago
    They also won't output stuff like progress bars, width-aware content, and may change other behavior. It would also annoying to pipe everything.
• chroma 3y ago
  Instead of trying to get every CLI tool in existence follow this standard, it makes much more sense to put this support in the terminal emulator or shell. Both can know what process is in the foreground and can strip color or let color through based on a user-configured whitelist/blacklist.
  • jeroenhd 3y ago
    Colors are usually stripped when the output is piped, so simply piping a command through cat should already do this most of the time. Using a global standard for color configuration would be nice, though. I often want coloured output and am left with all kinds of command line flags or environment variables just to get tools to output text normally.
    • comradesmith 3y ago
      That’s still up to the developer of the producer to implement
    • esprehn 3y ago
      Piping to cat won't work for an interactive tool though.
  • ktpsns 3y ago
    I think the main reason for disabling color output is the programmatic use of the output. It is easy to remove color within pipes (c.f. https://stackoverflow.com/questions/17998978/removing-colors-from-output https://stackoverflow.com/questions/17998978/removing-colors...), however quite cumbersome to clean the output of each potential program just to make sure nothing breaks. I guess the terminal should not start putting hands into this game since stdout is generally assumed to be binary (not even text).
    • nerdponx 3y ago
      I don't know all the intricate details of how these things work, but my general impression is that the terminal should really not be able to see or modify data being sent over pipes. The shell can, but you wouldn't want it unconditionally scraping and "cleaning" what is usually an opaque binary stream (even if it contains mostly text). So you can make it an option, but wouldn't it be better if programs just provided a standard way to turn off color coding?
    • n2d4 3y ago
      Shouldn't you rather use $TERM=dumb (or unknown) for this, since there are plenty of other escape sequences that you also wouldn't want? The author has a use case (I believe their issue is that unlike $NO_COLOR, setting $TERM takes precedence over any configs or --color flags), though to me it seems like a rather niche problem. Anyways, if you support $TERM, it's easy to support $NO_COLOR as well, so there's not much of a reason to not follow the standard.
      • bitwize 3y ago
        > Shouldn't you rather use $TERM=dumb (or unknown) for this, since there are plenty of other escape sequences that you also wouldn't want? Lots of software out there, especially from nodebros, blithely ignores $TERM and just barfs ANSI escape codes to standard out, under the rubric that, well, everybody uses macOS Terminal/iTerm/Alacritty.
        • JdeBP 3y ago
  • rice7th 3y ago
    Yeah. If you don't like colors just diable them from the terminal.
  • noitpmeder 3y ago
    They address this FAQ on the linked page: > The terminal is capable of color and should be able to print color when instructed. NO_COLOR is a hint to the software running in the terminal to suppress addition of color, not to the terminal to prevent any color from being shown. > It is reasonable to configure certain software such as a text editor to use color or other ANSI attributes sparingly (such as the reverse attribute for a status bar) while still desiring that other software not add color unless configured to. It should be up to the user whether color is used, not the software author.
    • Waterluvian 3y ago
      Is there some reason why we can’t just implement this once in each terminal? Go into the settings, set “no colour” and it just strips all the escape codes from the stream? Or just outright ignore them? I guess it feels weird to want to make this the problem of every CLI application developer.
      • deleted 3y ago
        [deleted]
      • emmelaich 3y ago
        You could copy an existing terminfo entry and remove the colour. Or use an existing one like ansi-mono
      • kps 3y ago
        I want colour, in certain places, under my control. I don't want every random tool spewing confetti.
        • cat_plus_plus 3y ago
          So you want every developer to spend time on both color and non-color options but are not willing to contribute a patch for that?
          • alpaca128 3y ago
  • aumerle 3y ago
    terminal emulators dont actually know this. Just think of executing something via ssh. In this case the primary foreground process is ssh.
  • TheRealPomax 3y ago
    No, it really doesn't. There are so many tools that already respect this variable that if you're writing a new tool, and you're not looking for that variable, you are being a bad actor and need to be told to shape up.
  • slmjkdbtl 3y ago
    Agree, but even for terminal emulators imo it's better to put that as an option in the config menu / file instead of an ENV variable
  • geocar 3y ago
    I personally don’t like having to ask a friend to adjust a bunch of terminal settings (or worse, use a specifically accessible terminal like you are suggesting) just so I can look over their shoulder without my eyes bleeding. I also don’t think anyone is asking you to go change all the software in the world to support NO_COLOR=1 just to help people out. I do think it would be great if the next time you thought about putting a little colour in your application that you consider supporting $NO_COLOR to disable it. It would help me and others out if I ever found myself using your software. I do agree that the terminal you suggest (if it existed and were common) _would_ be better than NO_COLOR=1 but I hope you can also understand we don’t live in that world, and that the “best” solution in one way, isn’t always the best way to help people out. Finally, I hope very much that you can think about accessibility in the future: asking the disabled to work harder is not a kindness- it may be unrealistic to do anything else, but you can try to make it as easy as you can, and that is a kindness.
• tedunangst 3y ago
  Previously: https://news.ycombinator.com/from?site=no-color.org https://news.ycombinator.com/from?site=no-color.org
  • jwilk 3y ago
    Expanded: 2022: https://news.ycombinator.com/item?id=30483417 https://news.ycombinator.com/item?id=30483417 (201 comments) 2019: https://news.ycombinator.com/item?id=21171274 https://news.ycombinator.com/item?id=21171274 (9 comments) 2018: https://news.ycombinator.com/item?id=16322116 https://news.ycombinator.com/item?id=16322116 (53 comments)
• adeon 3y ago
  For any new programs I make that involve terminal, I'm going to make them respect NO_COLOR as it seems pretty trivial. > "If your software outputs color by default, please consider not doing so." I'd love to hear good reasoning why using color by default is bad. I can think of some arguments for doing so but the website is not elaborating. E.g. default color choices assume dark terminal or they are not modifiable or developers in general tend to do a bad job at it or something along those lines etc. I think color can make reading faster and easier, it's why syntax highlighting exists.
  • bombcar 3y ago
    When most everything is b/w a splotch of color is very eye catching - but when your terminal always looks like a technicolor yawn a red error flashing by will be unnoticed.
  • fiddlerwoaroof 3y ago
    > default color choices assume dark terminal Unless you’re using the 24bit color extensions, the default color choices are pretty abstract: if they are readable in one color scheme and unreadable in another, the problem is in the color scheme’s selection of colors.
    • arp242 3y ago
      > the problem is in the color scheme’s selection of colors. Application can also set the background colours. If I "fix" things so that it will work well on a light background then it will be broken on applications that explicitly set a dark background.
      • lolinder 3y ago
        Is there a good use case for applications explicitly setting a dark background? If you're playing games in your terminal I can see it, but I'm having a hard time imagining a good use case beyond that.
        • 3y ago
• pcthrowaway 3y ago
  Is behaviour defined for programs with a `--color=always` flag set in combination with NO_COLOR? I'd assume `--color=always` takes precedence
  • ksherlock 3y ago
    Yes; as you assume, a compliant program disables color by default when NO_COLOR is set but a command line flag, etc, could turn it back on.
• wyldfire 3y ago
  If you do end up emitting color by default, please at least make it contingent on isatty() - maybe the user can override that but I rarely want it when redirecting.
  • rocqua 3y ago
    As a counter-example, I hate that piping to less will generally strip colour unless I tell both less and the command to really output color.
    • joosters 3y ago
      It would be nice to be able to have something like 'colorless <command I want to pipe to less>', and the 'colorless' command will run the given program, fake a TTY so that the isatty() check passes and it outputs color, then pipe it into the pager. Unfortunately, calling it colorless would be exactly the wrong name for it!
      • account42 3y ago
        Considering less is more, wouldn't colorless be exactly the right name?
      • jwilk 3y ago
        Check out lesstty from https://github.com/kilobyte/colorized-logs https://github.com/kilobyte/colorized-logs. (Or https://github.com/jwilk/pagerboy https://github.com/jwilk/pagerboy, which supports pagers other than less.)
        • joosters 3y ago
          Thank you! That looks very useful. The associated program 'ansi2txt' could also solve a similar problem for me from the other way round: I tend to have grep aliased to 'grep --color=always', simply because often I'm going to pipe the results to 'less' and I still want the colors. But this sometimes trips me up if I have a series of greps: The first grep output has color codes, making the followup greps fail. If grep could be made to strip out color codes prior to running, everything would work just as expected. In general, if you're running a series of connected commands, it's only the last one that you want to get the colors from, with the special case exception of when the last command is 'less' - in which case, the next-to-last one should keep the colors. All ways that make this happen automatically are useful!
• endgame 3y ago
  NO_FOO variables seem to me like bad design: it makes it hard to override/explicity ask for FOO. In general, I think allowing a set of options like FOO=always,never,auto gives a lot more flexibility and extensibility.
  • rippercushions 3y ago
    Where's the fun in that? Use NO_FOO=enable,disable to maximize ambiguity.
    • serpix 3y ago
      To increase confusion the variable name should contain the verb as well: NO_COLOR_DISABLED=enabled
  • kps 3y ago
    Yes, it would be better if colour were opt-in.
• jsd1982 3y ago
  Sounds broken by spec without a false/disable value or values defined. It says to always assume true for any non-empty string, which would include things like "no", "off", "false", "0", etc.
  • ericpruitt 3y ago
    It's a common standard for UNIX environment variables to be treated this way, and it greatly simplifies the logic needed to handle the value. Here's how this can be simply implemented in Python: if os.environ.get("NO_COLORS"): ... In POSIX shell: if [ "$NO_COLORS" ]; ... or, when nounset is used: if [ "${NO_COLORS:-}" ]; ... Adding sentinel values when you only need a true/false indicator just complicates things.
• numbsafari 3y ago
  Why not implement a program that reads from stdin, strips any ansi color, and writes to stdout?
  • taftster 3y ago
    Interactive programs wouldn't work very well with this idea. And then you're what, stuck with always piping through some anti-color application each time too? Seems cumbersome.
    • hnlmorg 3y ago
      Those problems are solvable with a PTY. Like how ‘screen’ and ‘tmux’ work. I already have some code in my own shell to wrap everything in a PTY (ironically to add colour: highlight stderr in red) but I could just as easily do the opposite and strip all colour escape sequences.
  • deleted 3y ago
    [deleted]
  • aidenn0 3y ago
    Most programs disable color output when piped, so just piping to cat already accomplishes this.
• interfixus 3y ago
  > By adopting this standard, users that prefer to have plain, non-colored text output can export NO_COLOR=1 to their shell’s environment and automatically disable color by default in all supported software. If your software outputs color by default, please consider not doing so. If you insist, please implement this standard to make it easy for your users to disable color and then add your software to this list by submitting a pull request. I have tried NO_SLOPPY_GRAMMAR=1, but I still get meaningless text about users adopting a standard and me not outputting color if my software does.
  • EdwardDiego 3y ago
    And I tried NO_POINTLESS_SNARK=1, and yet here we both are.
• stefantalpalaru 3y ago
  [dead]
• anotherpaulg 3y ago
  [flagged]
  • lolinder 3y ago
    GPT stuff is so dominant in basically every other part of the site these days, I would really prefer that people not pull it in to completely unrelated threads.
    • anotherpaulg 3y ago
      Completely fair point. I was just happily surprised at how easy it was to add the support.
      • self_awareness 3y ago
        > self.console = Console(force_terminal=not pretty, no_color=not pretty) I don't think it's not a good idea to not use more negations so it's not more complicated to understand what's going on ;) (I think it's a good idea to use less negations to understand what's going on)
• deathless 3y ago
  > It should be up to the user whether color is used, not the software author. I don't understand this sentiment. As well say "it should be up to the user what the function of the software is, not the software author". If you don't like what a particular piece of software is doing, fork it and fix it, or replace it. (To be clear -- I support the idea of `NO_COLOR` and other standards generally, and I strive to implement relevant standards when I can. I just think the above sentiment is bananas).
• epage 3y ago
  See also https://bixense.com/clicolors/ https://bixense.com/clicolors/ for CLICOLOR and CLICOLOR_FORCE env variables. In my applications and CLI libraries (like Rust's clap), I support both. FORCE_COLOR is a de facto variable without a de facto meaning, so I don't bother to support it.
  • IshKebab 3y ago
    Yeah this is an earlier and better standard. It's really disappointing that someone felt the need to push an incompatible and worse alternative. I'll give them the benefit of the doubt that they simply didn't search for existing solutions, but when it was pointed out to them they really should have said "ok yeah you should use that". Instead it isn't even mentioned on their website.
• lolinder 3y ago
  It seems like most of the complaints that people have with color could be resolved by a few simple rules: * All color schemes shall have the 15 colors that are not the background contrast well with the background. * Terminal applications shall not specify white or black as the foreground color. * Terminal applications shall not specify the background color. * Terminal applications shall not output escape codes when piping or otherwise being used programmatically. TFA seems to have pretty serious issues with color in general, so I'm curious to know from those here if the rules above would address your complaints or if there's something more going on that I'm just missing.
  • geocar 3y ago
    They would do nothing for me. High-color terminals and apps beak out of the 16-color limit. Changing my “color theme” when someone wants to look at my screen sounds like more work than typing NO_COLOR=1. If I need to look at someone else’s screen what can I possibly do about their choice of colors and terminal emulators?
• jonhohle 3y ago
  Doesn’t it make more sense to have CLICOLOR set by default in most environments and distros and respect that? That’s already been supported by most standard tools for decades.
• slicktux 3y ago
  Highly devoted standard that makes sense…and this is coming from someone who does not mind color…
• olvy0 3y ago
  From time to time I have to use Powershell and its console colors are driving me nuts. I find some of the output in the default setting to be near unreadable, personally. This on top of its weird syntax make it even more annoying. There isn't any built-in option to reset that, unless you take the time to write a script to reset everything. This kind of one-off setting like in the OP would make it a tad more usable.
• linsomniac 3y ago
  While we're at it, can we get a "TITE_INHIBIT" or "NO_SECOND_SCREEN"? I must be the only one, but I hate having stuff up on my screen, like from a man page or editing a file, then going back to the command-line and having it disappear. Loved "tite_inhibit" in xterm, but I've moved on to wezterm and I'm tired of dealing with custom termcaps.
  • aib 3y ago
    Try LESS='-X'
  • geocar 3y ago
    I don’t know wezterm but in xterm you can make a button toggle the second screen, and this can be nice for switching between the manual page you were just looking at and the line you are typing into. I also prefer this to having a fucked up scrollback.
  • usr1106 3y ago
    I think that varies case by case. Sometimes "intermediate" output should disappear because it's less interesting than what I had before. Sometimes it should not disappear as you write. To implement that the shell prompt would need to contain a special esacape sequence as a marker and then the user can manually hide the output of the last command. Or to make it even more fancy: Hide and unhide output of any previous command.
• zaptheimpaler 3y ago
  Don't we already have a standard for programs to behave differently depending on whether the output is meant for human consumption or not? e.g ls will not output colors when piped into something. Looks like its the isatty() function? Beyond that this is a feature that some people want i guess.. I could ask every website to give me a NO_COLOR mode as well, but they don't. Instead you can greyscale at the OS level or the terminal emulator level if you need it.
  • geocar 3y ago
    > I could ask every website to give me a NO_COLOR mode as well, but they don't. Perhaps more websites than you realise: I use the reader view whenever I can, which is a little bit like $NO_COLOR for websites. Browsers also tend to widely have support for disabling style sheets and support for overrides, and wide support is more important than theoretical solutions. I do think it would be great if terminals had broad support for this kind of accessibility feature, but they don’t, and I think adding it is much harder than you think. > Instead you can greyscale at the OS level or the terminal emulator level if you need it. This doesn’t work very well in practice unfortunately because the intensity differs so widely and my terminal settings don’t help when I have to look at someone else’s screen. So while we wait for operating systems and terminal emulators to add more support for the disabled, maybe if you don’t mind, the next time you think about calling puts() with some color-codes in it you could just pretty-please check if $NO_COLOR is set?
    • account42 3y ago
      Reader view is a giant hack by the browser that more or less ignores what styles the webpage has set. A better match would be print (view) where the website does get to specify the style (although some browsers add their own heuristics because most websites don't).
• EdwardDiego 3y ago
  My favourite dumb about colour application is Terraform. So many logs from GH Actions have useless ANSI escape sequences in them.
  • erik_seaberg 3y ago
    They seem to be using https://github.com/mitchellh/colorstring/blob/master/colorstring.go#L85 https://github.com/mitchellh/colorstring/blob/master/colorst... instead of isatty and curses and terminfo.
    • EdwardDiego 3y ago
      Ah, thank you! A place for me to start digging, namely, how do I make c.Disable true. I suspect there's an easy flag for it, but still :/
• ruuda 3y ago
  Color is fine with me, but I'd love to have a standard way to disable emoji.
  • endorphine 3y ago
    Yes please. Excessive use of colors, emojis and text in the terminal is one of the main reasons that I hate working with JS CLIs these days.
• Eduard 3y ago
  > If your software outputs color by default, please consider not doing so. Quite opinionated for not giving additional 𝘃𝗮𝗹𝗶𝗱 arguments. Also the arguments regarding colorblind crowd being unable to distinguish colors are weak, as accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means, so that everybody has their chance to understand it (e.g. setting links in a distinguished color and underlined). Using colors (e.g. rkhunter malware report with its hundreds of checks uses green for success and red for warnings/errors) is not only enjoyed by many, but a relieve for ADDeez. Whoever doesn't want to have color, just pipe anything through ansi2txt; https://askubuntu.com/questions/984357/how-do-i-pipe-each-command-given-to-the-shell https://askubuntu.com/questions/984357/how-do-i-pipe-each-co...
  • p-e-w 3y ago
    > Also the arguments regarding colorblind crowd being unable to distinguish colors are weak Especially since accessibility in terminal environments simply isn't a thing. The terminal is a grid of cells that contain individual characters. Screen readers and other accessibility tools cannot know whether those characters constitute runs of text or separators, they cannot know which texts belong together, what their semantic relation is, etc. etc. If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. Proper accessibility requires semantic labeling of visual output, and the terminal display protocol doesn't provide that capability. Hand-wringing about a specific aspect like color blindness only serves to avoid discussing the elephant in the room, which is that TUI programs are fundamentally not accessible.
    • Conscat 3y ago
      Emacs is fine at screen reading in a terminal environment.
      • funklute 3y ago
        Do you mean for simple command line output, or also for actual TUIs, like htop and vim? If the latter, how does that even work? Presumably you'd have to configure it on a per-TUI basis, which is exactly the point of the parent -- it's not accessible out of the box, no matter what you do...right? Or can it be more clever than that?
• usrbinbash 3y ago
  > If your software outputs color by default, please consider not doing so. Why? What specific benefit does that convey to my users? When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so. There is exactly one use case for this, and that's programmatically processing output in a pipline. And that one is a solved problem, as good libraries for colored output usually check isatty() And before anyone says "colorblindness": I think if someone is colorblind, they are likely to have set up their terminal in a way that deals with colored output already.
  • andreareina 3y ago
    I don't remember what was the last instance of a command barfing ansi escape sequences into a non-tty output stream, but it was just a couple days ago. I encounter badly-behaved software more frequently than your seem to, and I have more confidence in "don't provide colour (or other fancy text) unless the user asks for it" than "it's fine except for this set of exceptions that who knows if it's complete or not".
    • FeepingCreature 3y ago
      Sure, but that has a simple solution not even mentioned in this post: isatty(1)
      • account42 3y ago
        Just remember that stdout and stderr can be both a tty, neither a tty or one is a tty while the other is not.
  • ori_b 3y ago
    > Why? What specific benefit does that convey to my users? Readability, reduced visual noise, and compatibility with any terminal color scheme. > When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so. Was your reason something other than preference? If not, did you consider that others may have different preferences?
• norir 3y ago
  I'm not anti-color in general, but I think its use should be reserved to where it is truly helpful. Often it feels like it's value is mostly just superficial pizazz. Grep highlighting matches is one of the examples where color is very helpful, but even there I think bold would work just as well without potentially running into any colorscheme issues.
• awestroke 3y ago
  Why not just change all colors to the same color (b/w) in your terminal emulator settings??
  • hnlmorg 3y ago
    That only works if applications stick to the default 16 colours. What grinds my gears is when applications use the 8 bit or 24 bit ansi escape codes for anything other than TUI graphics.
• PhilipRoman 3y ago
  I have a love-hate relationship with colors in technical environments. When used properly, they are awesome. For example, I have custom syntax rules for assembly that highlight each register in different colors as well as highlighting instructions based on type. This allows me to visually see dependency chains in disassembler output without having to type a single key. On the other hand, every single editor from Vim to full blown IDEs has an absolutely braindead idea of what syntax highlighting should be. Some keywords are useless noise (public, final, const, struct) while other keywords are more important - but usually they are all behind a single syntax rule called "keyword". I want to configure each one individually so I can visually scan code faster. IntelliJ has the right idea with semantic highlighting and I think every editor these days has a rainbow parentheses plugin that helps deciphering long expressions. Personally, I've fixed this with a few Vim keybinds allowing me to dynamically highlight things that are important at the moment. For non-interactive use I either use Vim as a pager or pipe to a small script which highlights what I want to see.
  • arp242 3y ago
    In Vim it's often relatively easy to fix these kind of issues and tweak things to your liking; e.g. "syn clear cStructure" to clear just the highlight for struct, union, and enum keywords in C (and not anything else), "syn clear javaScopeDecl" to disable the scope declarations in Java, etc. Details differ per language; but most syntax files declare fine-grained syntax rule which are then linked to "Keyword" highlight or whatnot later, but there's nothing preventing you from clearing the fine-grained syntax rules (or just defining your own).
• olgeni 3y ago
  Also, please don't barf random emojis on the terminal.
• londons_explore 3y ago
  Are environment variables the right place for such an option? This is effectively config. Should we export all of /etc/* into environment variables too? One variable per configurable thing?
• tpoacher 3y ago
  A lot of people here are attributing semantics to the article that I don't believe it has claimed. To me this simply reads, "If your application deals with colour, consider your user, and please also consider this standard". In particular the line "If your software outputs colour by default, please consider not doing so", on one hand comes across as opinionated, on the other hand I mostly interpret this as a call to not have coloured output as a default without having first considered an easy way to disable it, which is sensible. I like colours in my terminal, and have included them in most of my non-trivial work; I have also added NO_COLOR because I think it's a nice informal standard, but more importantly I support the --color=<auto|never|always> GNU standard. The part where I lack a bit is the customisability; I'm not too sure how to use terminal themes, so I have been using absolute colour sequences instead. I need to look that up...
• junon 3y ago
  Chalk[0][1] maintainer here. We've gone over this, uh... call to arms? a number of times before. AMA. [0] https://github.com/chalk https://github.com/chalk [1] https://npmjs.org/package/chalk https://npmjs.org/package/chalk
  • kps 3y ago
    The examples seem to encourage hard-coding specific colours, and includes examples that are unreadable on a light background. chalk.bgHex('#DEADED').underline('Hello, world!')
    • junon 3y ago
      We don't encourage it, we just supply the functionality. There's no fix here - terminal colors are inherently environment-unaware aside from the basic 16 (8 dark, 8 light).
  • tgv 3y ago
    Why not add env("NO_COLOR") to it as an equivalent of FORCE_COLOR=0?
    • junon 3y ago
      Because we've had 5nor 6 of these standards and it becomes unclear which one should take precedence. If FORCE_COLOR=1 and NO_COLOR is defined, which one wins? FORCE_COLOR was the first we had found that was also present in other Unix utilities and thus the one that won.
      • tgv 3y ago
        I'm a bit late, but perhaps you could write the no-color website maintainer, and ask to link to similar projects? Then we could see all options to disable or forcibly enable color in one glance.
• dmos62 3y ago
  It is surprising that, while it's obvious that the website was built carefully, it didn't occur to the author to articulate the rationale for this whole campaign. I suppose in the author's mind, this site's audience are people for whom this is self-evident. Still bad form for a public request to not provide reasoning.
• rollcat 3y ago
  If you care about this, use a desaturated (or even monochrome) color scheme for your terminal. If you encounter software that tries to use 256/true color, use a terminal that doesn't support it (or that can disable it). I use a desaturated theme for coding: bg #f6f6f3, fg #303030, keyword #303060, etc (and a dark variant for the late sessions). I have a little bit more saturation in the terminal (eg #3465a4 for blue) but it's definitely on the toned down side, compared e.g. to the xterm or Terminal.app defaults. Remember when MS Windows allowed you to change the color of every single UI element? Some of these color schemes were really beautiful. We should go back to user-themeable UIs.
  • nottorp 3y ago
    I wonder if people who like desaturated color schemes for code haven't set their monitors too bright. Or at least too bright for my tastes. I keep my monitors on as low brightness as i can without losing color and I end up using high saturation themes to make things more clear.
    • rollcat 3y ago
      Desaturated colors are a good middle ground between monochrome and fruit salad, especially for text. My other screen is a Thinkpad X230 and there's no definition of "too bright" that fits it, even at max brightness.
• deleted 3y ago
  [deleted]
• shadowgovt 3y ago
  Why should this be the writer's responsibility instead of the shell? Unless one is bandwidth-constrained, shouldn't the protocol be for programs to emit data as rich as possible and it be the interpreter's responsibility to format it in a way the user can understand?
• aigoochamna 3y ago
  The primary usecase for no color, in my opinion, is for running software on CI/CD and other automated systems. Sometimes you want to track logs or alert on certain output and you don't want a bunch of garbage characters that can't be displayed on those systems.
• syngrog66 3y ago
  my bias/defaults: screen? white on black. give users easy option of overriding the text colors, styles and fonts paper? black on white wise rule of thumb. any exceptions should be a clear net win in the context/domain
• deleted 3y ago
  [deleted]
• naet 3y ago
  Colors are useful. There's a reason many code editors have color syntax highlighting - it conveys information and is easy to work with. Most terminal colors in my experience aren't just for "looks", they're for displaying information in a clear and compact way. If you prefer no colors in your environment that's fine and you can probably configure it that way, but I don't think no color as a global default makes sense.
  • tgv 3y ago
    Why doesn't it make sense? I also don't agree with the assumption that color carries information. Or rather, that you use it as such. The visual system uses different areas as markers. Color/high-lighting makes it easier to e.g. jump to the beginning of a function. But it would confuse you when used to convey semantics, e.g. when using color to distinguish between "if" as the start of a conditional statement and as an identifier. At least, that's what the Stroop task suggests might happen.