5 ms·

> By all means, they can have an option to enable themes in their tool if they wish, but that should be opt-in, not the default. This touches on the problem of

by bhaak 2y ago

> By all means, they can have an option to enable themes in their tool if they wish, but that should be opt-in, not the default. This touches on the problem of good defaults. If the user has to configure it then the user must know that it is configurable and then do it. This is a serious hurdle and only a tiny fraction of users will do it. Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used. 8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors.

hnlmorg 2y ago
> Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used. Agreed to an extent. I wouldn't call ignoring the systems colour preferences as "good defaults". But I do agree with your more general point. > 8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors. Unfortunately it's not that simple. Both the "256color" suffix to $TERM and $COLORTERM env vars report terminal compatibility -- not user preference. Neither are standards either. It's a push to even call them a de facto standard because they're often not used by either terminal emulators nor application developer alike. There is another env var that does report user preferences: $COLORFGBG, but that receives even less support than the former two vars. There's also $NO_COLOR (or is $NOCOLOR?), which seems to be honored a little better. However the problem with this is it turns colour off completely. ie you cannot specify "use 4bit but not 8bit nor 24bit colour". Like all things terminal detection wise, it's all a big fat steaming mess of inconsistencies. Which is why I think the best default is 3/4bit or no colour at all if $NO_COLOR / not a TTY. And have all the cool 24bit themes as an optional extra.
- bhaak 2y ago
  > Unfortunately it's not that simple. Both the "256color" suffix to $TERM and $COLORTERM env vars report terminal compatibility -- not user preference. Terminal compatibility that is expected to be used. If you only want the 16 base colors then this is the way to go. This is the most reliable and best supported way to get that in the terminal. If you want some tools to still output 256 colors, you can change the TERM variable on the fly: "TERM=$TERM-256color infocmp -L". You also should unset COLORTERM. It's for specifying that this terminal supports 24bit colors.
  - hnlmorg 2y ago
    You’re basically just demonstrating my point that this gets very complicated very quickly and thus the polite way to handle this is tool authors to default to 4bit.
    - bhaak 2y ago
      A lot of the complexity comes not only from technology that has been dragged along for almost 50 years now but also that the maintainer of ncurses/terminfo has been stubbornly refusing to add new capabilities to the terminfo library. Using terminfo will give you at least a standard approach to what defaults to use. If you don't want to configure your terminal then you are asking others to do something you are not willing to do. If we are supposed to go with the lowest common denominator without terminfo capabilities, we would even lose 4bit colors. Then only the basic 8 colors are safe because there a lot of terminals now that don't support the workaround of "bold plus basic color gives bright color" anymore.
      - hnlmorg 2y ago
        That is a massive over simplification and you're pointing the fingers at the wrong culprits. I've talked a lot recently about the problems with env vars for terminal detection and the problems with developers not understanding how to correctly query terminal capabilities. Heck, some don't even correctly support non-TTY outputs (ie pipes). And then there's the issue that terminfo is a C library so a lot of languages with average to no-C FFI support cannot use it without fork()ing -- which is slow. Plus terminfo is POSIX only which eliminates platforms like Windows -- which is increasingly a target now that Windows Terminal supports ANSI escape sequences. It's a mess and blaming that on history and terminfo really misunderstands that the real problem is modern tools not respecting or having compatibility with that history, rather than the history breaking things. > If we are supposed to go with the lowest common denominator without terminfo capabilities, we would even lose 4bit colors. Then only the basic 8 colors are safe because there a lot of terminals now that don't support the workaround of "bold plus basic color gives bright color" anymore. You're missing the point. It's not about supporting the lowest common denominator -- though I'd love you to give some example of terminal emulators in common use that don't support 4-bit colours ;) It's about supporting user defaults. Themes based on 8-bit and 24-bit colour pallets are defined by the developer. Whereas themes based on 3 and 4-bit colour pallets are defined by the terminal user. Hence why I say applications should default to the terminal defaults (defined by the user) There's times when applications should support 24-bit regardless of the user preferences. Such as image rendering in the terminal. But those are exceptions rather than the norm. And precisely why things like `256-color` and $COlORTERM need to be defining terminal support not user preference.
- NoGravitas 2y ago
  It's also the case that a lot of modern CLI tools will absolutely ignore your termcap and your $TERM env var and barf out whatever extension to ANSI is used by the currently most popular terminal emulators. Unless it's a TUI app that I'm going to spend a lot of time in (e.g., Emacs), I do not want it theming itself. I want it to look at my termcap to see if it has ANSI color support, and if it does, then emit ANSI color codes. I use base16-shell to set my terminal colors and I want CLI and TUI apps to respect them.

by bhaak 2y ago

hnlmorg 2y ago

> Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used. Agreed to an extent. I wouldn't call ignoring the systems colour preferences as "good defaults". But I do agree with your more general point. > 8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors. Unfortunately it's not that simple. Both the "256color" suffix to $TERM and $COLORTERM env vars report terminal compatibility -- not user preference. Neither are standards either. It's a push to even call them a de facto standard because they're often not used by either terminal emulators nor application developer alike. There is another env var that does report user preferences: $COLORFGBG, but that receives even less support than the former two vars. There's also $NO_COLOR (or is $NOCOLOR?), which seems to be honored a little better. However the problem with this is it turns colour off completely. ie you cannot specify "use 4bit but not 8bit nor 24bit colour". Like all things terminal detection wise, it's all a big fat steaming mess of inconsistencies. Which is why I think the best default is 3/4bit or no colour at all if $NO_COLOR / not a TTY. And have all the cool 24bit themes as an optional extra.

bhaak 2y ago
> Unfortunately it's not that simple. Both the "256color" suffix to $TERM and $COLORTERM env vars report terminal compatibility -- not user preference. Terminal compatibility that is expected to be used. If you only want the 16 base colors then this is the way to go. This is the most reliable and best supported way to get that in the terminal. If you want some tools to still output 256 colors, you can change the TERM variable on the fly: "TERM=$TERM-256color infocmp -L". You also should unset COLORTERM. It's for specifying that this terminal supports 24bit colors.
- hnlmorg 2y ago
  You’re basically just demonstrating my point that this gets very complicated very quickly and thus the polite way to handle this is tool authors to default to 4bit.
  - bhaak 2y ago
    A lot of the complexity comes not only from technology that has been dragged along for almost 50 years now but also that the maintainer of ncurses/terminfo has been stubbornly refusing to add new capabilities to the terminfo library. Using terminfo will give you at least a standard approach to what defaults to use. If you don't want to configure your terminal then you are asking others to do something you are not willing to do. If we are supposed to go with the lowest common denominator without terminfo capabilities, we would even lose 4bit colors. Then only the basic 8 colors are safe because there a lot of terminals now that don't support the workaround of "bold plus basic color gives bright color" anymore.
    - hnlmorg 2y ago
      That is a massive over simplification and you're pointing the fingers at the wrong culprits. I've talked a lot recently about the problems with env vars for terminal detection and the problems with developers not understanding how to correctly query terminal capabilities. Heck, some don't even correctly support non-TTY outputs (ie pipes). And then there's the issue that terminfo is a C library so a lot of languages with average to no-C FFI support cannot use it without fork()ing -- which is slow. Plus terminfo is POSIX only which eliminates platforms like Windows -- which is increasingly a target now that Windows Terminal supports ANSI escape sequences. It's a mess and blaming that on history and terminfo really misunderstands that the real problem is modern tools not respecting or having compatibility with that history, rather than the history breaking things. > If we are supposed to go with the lowest common denominator without terminfo capabilities, we would even lose 4bit colors. Then only the basic 8 colors are safe because there a lot of terminals now that don't support the workaround of "bold plus basic color gives bright color" anymore. You're missing the point. It's not about supporting the lowest common denominator -- though I'd love you to give some example of terminal emulators in common use that don't support 4-bit colours ;) It's about supporting user defaults. Themes based on 8-bit and 24-bit colour pallets are defined by the developer. Whereas themes based on 3 and 4-bit colour pallets are defined by the terminal user. Hence why I say applications should default to the terminal defaults (defined by the user) There's times when applications should support 24-bit regardless of the user preferences. Such as image rendering in the terminal. But those are exceptions rather than the norm. And precisely why things like `256-color` and $COlORTERM need to be defining terminal support not user preference.
NoGravitas 2y ago
It's also the case that a lot of modern CLI tools will absolutely ignore your termcap and your $TERM env var and barf out whatever extension to ANSI is used by the currently most popular terminal emulators. Unless it's a TUI app that I'm going to spend a lot of time in (e.g., Emacs), I do not want it theming itself. I want it to look at my termcap to see if it has ANSI color support, and if it does, then emit ANSI color codes. I use base16-shell to set my terminal colors and I want CLI and TUI apps to respect them.