5 ms·

I dont like their approach in the issue of "Kitty Only uses Dark colors"[1] 1. https://github.com/kovidgoyal/kitty/issues/197 https://github.com/kovidgoyal/kit

by garou 6y ago

I dont like their approach in the issue of "Kitty Only uses Dark colors"[1] 1. https://github.com/kovidgoyal/kitty/issues/197 https://github.com/kovidgoyal/kitty/issues/197

kemayo 6y ago
Kovid Goyal is a person with forcefully presented opinions. I've submitted bugs to Calibre before, so I can vouch that his style remains the same.
- garou 6y ago
  Yeah. I've tried the Kitty last year and when my colors showed different I found this Issue already closed and with some strong words/opinions from him. Hard to like it.
  - cosmojg 6y ago
    He's not wrong, though. He's following the spec, and users are asking him to violate it to be compatible with programs which also violate it. If everyone just followed the spec, however, colors would work beautifully for everyone all the time without anyone having to worry about weird edge cases in specific programs. If a program you run in Kitty displays incorrect colors because it's hijacked bolding instead of implementing proper color support, you should absolutely go and make the issue known to the authors of said program as they are the ones who fucked up by violating the spec in the first place. The whole point of standards is to make the relevant technologies more accessible. Developers too often break spec without regard for accessibility, all in the name of cool new features. This is bad, and it makes sense to discourage it by simply enforcing the spec.
    - tangus 6y ago
      The standard says "bold or increased intensity". I see brighter colors on dark background (what everybody does) more in line with it than darker colors on dark background (what Kitty does).
    - dragonwriter 6y ago
      > He's following the spec, and users are asking him to violate it to be compatible with programs which also violate it. Users are asking for a configuration option to behave the way every other terminal works, and the way everyone writing software that runs in terminals that relies on any behavior relies on terminals behaving.
      - JdeBP 6y ago
        It is not the way that every other terminal, or indeed terminal emulator, works; nor is it relied upon by "everyone". For starters: Softwares that use terminfo, and anything built on top of it such as ncurses, only use this for one specific terminal type, linux-16color. No other terminal type in terminfo changes colour this way. The idea that boldface and blink change colours has been on its way out since the 1990s. XTerm has had the ability since 1997; and while its XTerm personality does not, its UXTerm personality defaults to boldface meaning boldface. Of course AIXterm, at the start of the 1990s, had SGRs 90 to 97 and 100 to 107, and did 16 colours that way, not with boldface. The Windows Terminal issue shows some of how far this notion has extended in the more than a quarter of a century since. It isn't a VGA world any more, and people aren't assuming VGA semantics any more. Ironically, before VGA, in the world of MDA et al., as seen from the SCO Console, people didn't assume these semantics back then, either. There has been a sea change. boldface means boldface. And blink actually means blink (or nothing, depending from what one's views on blinking as a GUI mechanism are). * https://github.com/microsoft/terminal/issues/5682 https://github.com/microsoft/terminal/issues/5682 * https://github.com/microsoft/terminal/issues/7388 https://github.com/microsoft/terminal/issues/7388
      - nix23 6y ago
        >behave the way every other terminal works Then use every other terminal, or make your own.
  - wetpaws 6y ago
    I find his replies polite, firm and to the point. Just because his position does not match other folks, it does not mean he is wrong.
    - nix23 6y ago
      Yes absolutely. People sometimes assume that you have to implement feature XY, just to lament 1 year later that another software is not that bloated. I like people with a strong opinion and if i don't like it i use something else.
shirakawasuna 6y ago
Treating accessibility like an aesthetic choice...
- cosmojg 6y ago
  Not really. Did you read the issue thread? He's enforcing the spec. If anything, that improves accessibility since that's what specs are for, maximizing accessibility.
  - trynewideas 6y ago
    Aside from all of the debates, it's just the hardest of hardcore terminal opinions to be militantly hardline on not only going the opposite of the suckless/st default,[1] but to double down on not even implementing the means to toggle it. I don't think I respect it, and it's one of many reasons why I bounced off kitty (and certainly helps explain why I bounce off so many design decisions in Calibre), but there's still a spark of awe in seeing it happen in public. [1] https://st.suckless.org/patches/bold-is-not-bright/ https://st.suckless.org/patches/bold-is-not-bright/
reaperducer 6y ago
You should ask for your money back.
zem 6y ago
he seemed extremely reasonable to me. he explained that * the spec said bold text and bright colours were two different attributes * the fact that some terminals rendered the bold attribute as bright colours prevented applications from actually using bold text * he did not want kitty to be part of the problem furthermore, he explained that in a way that respected the person opening the bug - he didn't patronise them or say that it was his decision not to do that because he didn't care to and they could take a hike; he actually detailed his reasoning and why he was philosophically opposed to it. i might have read through that and decided that okay, kitty was not for me, but i would not have felt the author was being unreasonable about it.
- JdeBP 6y ago
  For what it's worth: The issue about bold and blink performing colour changes is widespread across terminal emulators. It has come up for Windows Terminal, for example, and the libVTE people have already addressed this. In reality, the only terminfo entry that even does this any more is the linux-16color one for the built-in Linux terminal emulator. There's a sea change happening here. It's a post-VGA world. Boldface means boldface. * https://github.com/microsoft/terminal/issues/5682 https://github.com/microsoft/terminal/issues/5682
  - sime2009 6y ago
    Using bright colours for bold made sense years ago when we had much lower resolution displays. The fonts used back then were pixel based and tiny. (Think 8x8 or 8x7) It often wasn't possible to be make a bold version of a pixel font that size. You just can't do fat bold lines and not end up with a blob.
    - JdeBP 6y ago
      That argument flounders on the fact that in the pre-VGA (more strictly pre-CGA) world boldface and blink did not change colours, either. There was a whole world of monochrome video terminals. And, furthermore, the fonts during the heyday of the home computer revolution were boldface in several cases, including the BBC Micro's graphics mode character set, even though they were smaller than 8 by 8. * https://damieng.com/blog/2011/02/20/typography-in-8-bits-system-fonts https://damieng.com/blog/2011/02/20/typography-in-8-bits-sys...

by garou 6y ago

I dont like their approach in the issue of "Kitty Only uses Dark colors"[1] 1. https://github.com/kovidgoyal/kitty/issues/197 https://github.com/kovidgoyal/kitty/issues/197

kemayo 6y ago

Kovid Goyal is a person with forcefully presented opinions. I've submitted bugs to Calibre before, so I can vouch that his style remains the same.

garou 6y ago
Yeah. I've tried the Kitty last year and when my colors showed different I found this Issue already closed and with some strong words/opinions from him. Hard to like it.
- cosmojg 6y ago
  He's not wrong, though. He's following the spec, and users are asking him to violate it to be compatible with programs which also violate it. If everyone just followed the spec, however, colors would work beautifully for everyone all the time without anyone having to worry about weird edge cases in specific programs. If a program you run in Kitty displays incorrect colors because it's hijacked bolding instead of implementing proper color support, you should absolutely go and make the issue known to the authors of said program as they are the ones who fucked up by violating the spec in the first place. The whole point of standards is to make the relevant technologies more accessible. Developers too often break spec without regard for accessibility, all in the name of cool new features. This is bad, and it makes sense to discourage it by simply enforcing the spec.
  - tangus 6y ago
    The standard says "bold or increased intensity". I see brighter colors on dark background (what everybody does) more in line with it than darker colors on dark background (what Kitty does).
  - dragonwriter 6y ago
    > He's following the spec, and users are asking him to violate it to be compatible with programs which also violate it. Users are asking for a configuration option to behave the way every other terminal works, and the way everyone writing software that runs in terminals that relies on any behavior relies on terminals behaving.
    - JdeBP 6y ago
      It is not the way that every other terminal, or indeed terminal emulator, works; nor is it relied upon by "everyone". For starters: Softwares that use terminfo, and anything built on top of it such as ncurses, only use this for one specific terminal type, linux-16color. No other terminal type in terminfo changes colour this way. The idea that boldface and blink change colours has been on its way out since the 1990s. XTerm has had the ability since 1997; and while its XTerm personality does not, its UXTerm personality defaults to boldface meaning boldface. Of course AIXterm, at the start of the 1990s, had SGRs 90 to 97 and 100 to 107, and did 16 colours that way, not with boldface. The Windows Terminal issue shows some of how far this notion has extended in the more than a quarter of a century since. It isn't a VGA world any more, and people aren't assuming VGA semantics any more. Ironically, before VGA, in the world of MDA et al., as seen from the SCO Console, people didn't assume these semantics back then, either. There has been a sea change. boldface means boldface. And blink actually means blink (or nothing, depending from what one's views on blinking as a GUI mechanism are). * https://github.com/microsoft/terminal/issues/5682 https://github.com/microsoft/terminal/issues/5682 * https://github.com/microsoft/terminal/issues/7388 https://github.com/microsoft/terminal/issues/7388
    - nix23 6y ago
      >behave the way every other terminal works Then use every other terminal, or make your own.
- wetpaws 6y ago
  I find his replies polite, firm and to the point. Just because his position does not match other folks, it does not mean he is wrong.
  - nix23 6y ago
    Yes absolutely. People sometimes assume that you have to implement feature XY, just to lament 1 year later that another software is not that bloated. I like people with a strong opinion and if i don't like it i use something else.

shirakawasuna 6y ago

Treating accessibility like an aesthetic choice...

cosmojg 6y ago
Not really. Did you read the issue thread? He's enforcing the spec. If anything, that improves accessibility since that's what specs are for, maximizing accessibility.
- trynewideas 6y ago
  Aside from all of the debates, it's just the hardest of hardcore terminal opinions to be militantly hardline on not only going the opposite of the suckless/st default,[1] but to double down on not even implementing the means to toggle it. I don't think I respect it, and it's one of many reasons why I bounced off kitty (and certainly helps explain why I bounce off so many design decisions in Calibre), but there's still a spark of awe in seeing it happen in public. [1] https://st.suckless.org/patches/bold-is-not-bright/ https://st.suckless.org/patches/bold-is-not-bright/

reaperducer 6y ago

You should ask for your money back.

zem 6y ago

he seemed extremely reasonable to me. he explained that * the spec said bold text and bright colours were two different attributes * the fact that some terminals rendered the bold attribute as bright colours prevented applications from actually using bold text * he did not want kitty to be part of the problem furthermore, he explained that in a way that respected the person opening the bug - he didn't patronise them or say that it was his decision not to do that because he didn't care to and they could take a hike; he actually detailed his reasoning and why he was philosophically opposed to it. i might have read through that and decided that okay, kitty was not for me, but i would not have felt the author was being unreasonable about it.

JdeBP 6y ago
For what it's worth: The issue about bold and blink performing colour changes is widespread across terminal emulators. It has come up for Windows Terminal, for example, and the libVTE people have already addressed this. In reality, the only terminfo entry that even does this any more is the linux-16color one for the built-in Linux terminal emulator. There's a sea change happening here. It's a post-VGA world. Boldface means boldface. * https://github.com/microsoft/terminal/issues/5682 https://github.com/microsoft/terminal/issues/5682
- sime2009 6y ago
  Using bright colours for bold made sense years ago when we had much lower resolution displays. The fonts used back then were pixel based and tiny. (Think 8x8 or 8x7) It often wasn't possible to be make a bold version of a pixel font that size. You just can't do fat bold lines and not end up with a blob.
  - JdeBP 6y ago
    That argument flounders on the fact that in the pre-VGA (more strictly pre-CGA) world boldface and blink did not change colours, either. There was a whole world of monochrome video terminals. And, furthermore, the fonts during the heyday of the home computer revolution were boldface in several cases, including the BBC Micro's graphics mode character set, even though they were smaller than 8 by 8. * https://damieng.com/blog/2011/02/20/typography-in-8-bits-system-fonts https://damieng.com/blog/2011/02/20/typography-in-8-bits-sys...