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.
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.
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.
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.
I wouldn't call it very reasonable. I mean, I understand him, and he is correct in the essence. But...
> whatever you are using to generate that particualr text output is incorrectly using bold formatting for bright colors
The problem is that this is pretty much every app out there. All small utils we have up to date, all colorschemes, they all are made with this in mind. And most (all?) other terminals do behave this way. This is de-facto standard. If he doesn't want this behaviour himself, that's fine, he wrote this app for himself after all. But refusing to make it configurable is just stupid and arrogant. This is not really a proposal for a new feature, this is broken compatibility with everything written in the last 30 years that uses this feature. And his response wasn't "respectful" is the slightest. If anything, the guy himself seems to be enough reason to avoid using this thing.
> that's fine, he wrote this app for himself after all. But refusing to make it configurable is just stupid and arrogant
Ad hominem much?
He wrote the app. If you want features, fork the code and add them yourself. Name-calling and demanding that the auther implement your pet feature is ... self-obsessed.
Do you also call your neighbor stupid and arrogant for not mowing your lawn?
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.
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.
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).
> 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.
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).
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.
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.
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://github.com/kovidgoyal/kitty/issues/197