Hacker News new | ask | show | jobs
by zem 2094 days 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.

2 comments

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

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.

* https://damieng.com/blog/2011/02/20/typography-in-8-bits-sys...

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?