4 ms·

I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after th

I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after they have looked at, and liked, the screenshots. Moreover, I take great care to make sure they are still usable in 16c, within reason. Because all my work is based on 16-255, I can actually guarantee to my users that, given a properly configured terminal emulator, they will get the colors on the screenshots. If I can't rely on 16-255 to be fixed anymore, then I won't be able to make any promise anymore. In practice, it just means adding a caveat in the README.md, but I'd prefer not to. Here's hoping this breaking change gets hidden behind a checkbox/flag.

poly2it 8mo ago
Why not truecolor if you want true colours?
- johncoltrane 8mo ago
  I don't want true colours. I want what I already have, 16-255, to stay reliable in the future.
  - poly2it 8mo ago
    Is that really optimal? It is already true in that case that your colour schemes do not work for people with opinionated colour settings. Isn't this just relying on a quirk? The point of not using truecolor is to respect the colour preferences of the user. XKCD 1172? https://xkcd.com/1172/ https://xkcd.com/1172/
    - johncoltrane 8mo ago
      It has been working for decades and I would rather have it keep working for decades to come. What would be optimal is semantic _styles_ (not colors): - The developer marks the string "XXX" as an error message without even trying to style it. - The platform/user agent/terminal/whatever displays the string in the default style for "error". - The user can adjust the theme of their platform/user agent/terminal/whatever to fit their needs/wants.
      - xvilka 8mo ago
        Semantic styles limit the use - not all interfaces need e.g. "error" context. Take, for example, Task Warrior interface. There is no place for the "error" semantics in it. But there's a place for "critical task" semantics, which is usually also some shade of red.
gzread 8mo ago
That's okay. Because the user has to reach out and choose a colour scheme they like, you can assume if they installed your colour scheme, they like the colours. But defaults should be simple.

poly2it 8mo ago

Why not truecolor if you want true colours?

johncoltrane 8mo ago
I don't want true colours. I want what I already have, 16-255, to stay reliable in the future.
- poly2it 8mo ago
  Is that really optimal? It is already true in that case that your colour schemes do not work for people with opinionated colour settings. Isn't this just relying on a quirk? The point of not using truecolor is to respect the colour preferences of the user. XKCD 1172? https://xkcd.com/1172/ https://xkcd.com/1172/
  - johncoltrane 8mo ago
    It has been working for decades and I would rather have it keep working for decades to come. What would be optimal is semantic _styles_ (not colors): - The developer marks the string "XXX" as an error message without even trying to style it. - The platform/user agent/terminal/whatever displays the string in the default style for "error". - The user can adjust the theme of their platform/user agent/terminal/whatever to fit their needs/wants.
    - xvilka 8mo ago
      Semantic styles limit the use - not all interfaces need e.g. "error" context. Take, for example, Task Warrior interface. There is no place for the "error" semantics in it. But there's a place for "critical task" semantics, which is usually also some shade of red.

gzread 8mo ago

That's okay. Because the user has to reach out and choose a colour scheme they like, you can assume if they installed your colour scheme, they like the colours. But defaults should be simple.