Colors: OKHSV and more ergonomic entry

[eugenesvk]

Instead of this inconvenient entry of colors:

[style.command_name]
foreground      = { rgb = { r = 255, g = 0, b = 0 } }

I'd suggest specifying the color space globally

[style]
color_space = "OKHSV"

(from this cool new color space or just any color space that a good Rust color library supports)

And then enjoying the simplest way: setting just 3 numbers without any labels

[style.command_name]
foreground = "29 100 100"

[dbrgn]

Hi. Thanks for the suggestion! That color space thing looks cool, but as for Tealdeer, I prefer to keep complexity down where possible. The entry format isn't terribly convenient, but editing your colors isn't something you'll do every day, so I think it's OK.

[eugenesvk]

entry format isn't terribly convenient, but editing your colors isn't something you'll do every day, so I think it's OK.

Don't get it, how does it justify making the first day experience with the tool has to be so inconvenient? Instead of a couple of copy&pastes I'd have to manually translate all the colors and then fit them to this weird entry format

[niklasmohrin]

I suppose we could fix the awkward rgb = part, but I am against more color spaces too - this is nothing that our program should care about

[eugenesvk]

Why shouldn't your program care about user convenience in filling in colors in your color scheme? I mean, that's the whole point of fixing the rgb= part (as well as r=, g=, and b= parts), currently you're forcing users to type more labels than color codes for every single color!

[niklasmohrin]

First off, we are not forcing anyone to type anything, tealdeer is free software that anyone can download and we allow users to customize its behavior through a config file that they can edit.

The rgb = stems from the fact that we are serializing an enumeration of possible values that not only contains RGB values, but also a handful of colors by their name. Users can write these names to refer to their terminal color settings instead (https://docs.rs/yansi/latest/yansi/enum.Color.html).

I agree that the format is not very convenient to type, but it is very what comes out of the box for our parser and it's not like users have to change it a lot. Like I said, I suppose we could advance the parser to allow for, say, strings like #abcdef and I am happy to accept contributions for that.

Converting between color spaces is not for tealdeer. We have to ask ourselves again, where do we want to draw the line here? You may be comfortable using okhsv, but others (like myself) have never heard of that and would much rather have a RGB color wheel or whatnot. There are tons of tools out there for color selection that do it way better than what is achievable within the bounds of how much code for that we would want to have in our codebase.

I don't know about other programs that allow this kind of color space manipulation. For example, alacritty, a terminal emulator (something that, in my opinion, is more concerned with displaying colors than tealdeer), only supports rgb too.

[eugenesvk]

I agree that the format is not very convenient to type, but it is very what comes out of the box for our parser and it's not like users have to change it a lot. Like I said, I suppose we could advance the parser to allow for, say, strings like #abcdef and I am happy to accept contributions for that.

Converting between color spaces is not for tealdeer. We have to ask ourselves again, where do we want to draw the line here?

The line is drawn at the choice of a good library that supports various color spaces, I don't expect you to convert anything, that's indeed not the job of your app

This issue is about user input, where I suggested basically two things:

• (major) allow the user to copy&paste/enter color values in the easiest string format regardless of the color spaces that you support (so, if you stick to only support the simplistic parser that is only able to understand non-hex RGB, that would be 10 20 30)
• (minor) allow a config-global namespace instead of specifying the color namespace in every single color (so set rgb once instead of having rbg = for every single color)

You may be comfortable using okhsv, but others (like myself) have never heard of that and would much rather have a RGB color wheel or whatnot.

That's fine, but you must've heard of HSL/HSB, right? Where you can reason about colors using their "human" properties like color intensity and brightness (vs the obscure RGB triplets)?

There are tons of tools out there for color selection that do it way better than what is achievable within the bounds of how much code for that we would want to have in our codebase.

It's not mainly about selection, it's about data entry. I already had colors selected in my other theme, the thing that lead to this issue is that instead of copy&pasting and moving a few commas here and there I'd have to use a cumbersome converter to convert to RGB

I don't know about other programs that allow this kind of color space manipulation. For example, alacritty, a terminal emulator (something that, in my opinion, is more concerned with displaying colors than tealdeer)

That's a bad example, alacritty is famous for ignoring design improvements (check their response re. ligatures as the prime example). For a terminal that cares a little bit more about UI, you can check out wezterm color config. Although it also require a prefix :( (which can be fixed via a little lua script) Sublime Text also accepts hsl with a prefix in its color schemes

, only supports rgb too.

But yeah, poor color and data entry support is pervasive, especially in cli tools, you're right about that

[niklasmohrin]

I think I am very happy with the color library we are currently using, it does the job very well - output color codes or custom colors to stdout - which is exactly what terminal emulators support. Can't you just enter your colors in your terminal emulator config and use the standard codes ("orange", "red", ...) in your tealdeer config? Again, if the terminal emulator doesn't have the feature about color spaces, I don't see why we should.

It's not mainly about selection, it's about data entry.

Well, honestly, tealdeer itself isn't about data entry in any way. Its fine if cli apps have "poor" support for data entry for such common domains, because whereever the data you are entering is coming from should just export it in the way. Any decent color picker has a button to copy rgb values. When I use GNU head, I can't cut after 3 centimeters, only after some number of lines, although head could maybe figure it out by asking my Xorg session about window dimensions and display resolution and whatnot. But it's just out of scope.

That's a bad example, alacritty is famous for ignoring design improvements (check their response re. ligatures as the prime example).

:shrug: I can see that it is disappointing that a much-wished feature is not implemented / accepted for a long time, but the maintainers make good points (and some other people in the thread just have unjustified expectations of the maintainers, not really helping the situation). It is reasonable to make tradeoffs in this regard, just like we are doing here

[eugenesvk]

I think I am very happy with the color library we are currently using, it does the job very well output color codes or custom colors to stdout - which is exactly what terminal emulators support.

Except it doesn't accept much more convenient color codes, so there is that "job well done"

Can't you just enter your colors in your terminal emulator config and use the standard codes ("orange", "red", ...) in your tealdeer config?

No, why would I mess up globals for one app???

Again, if the terminal emulator doesn't have the feature about color spaces,

a) That's not true, better terminal emulators do support it, see wezterm above or try to pick a color in iTerm

I don't see why we should.

b) Because you're not a terminal emulator? How is the presence of poorly designed apps relevant? Remember, it's you who is asking the users for the most convenient { rgb = { r = 255, g = 0, b = 0 } }, no terminal emulator is forcing you to do any of that, you can just as easily accept anything else and feed the terminal emulator converted colors in whatever format they understand

Well, honestly, tealdeer itself isn't about data entry in any way

Of course it is, that's just a simple fact — you ask users to enter information to configure, so that's it

Its fine if cli apps have "poor" support for data entry for such common domains, because whereever the data you are entering is coming from should just export it in the way.

Why would my color scheme (a text file) do any export???

Any decent color picker has a button to copy rgb values.

Oh, so now you require users, who have already done all the color picking, to go through a data conversion pipeline to downgrade to a worse data format (and by the way, you don't accept the copied values as is, so there is one more manual conversion step). How is this burden "fine"?

When I use GNU head, I can't cut after 3 centimeters, only after some number of lines, although head could maybe figure it out by asking my Xorg session about window dimensions and display resolution and whatnot. But it's just out of scope.

How is this relevant? What is the benefit of using centimeters over lines in text manipulation??? Unlike this example, the nonRGB color spaces have a benefit. Also, it is in scope (and already implemented) in a color library, so someone has already "asked Xorg and whatnot"

🤷 I can see that it is disappointing that a much-wished feature is not implemented / accepted for a long time

It's not about disappointments etc, it's just an illustration that you can't use an app that doesn't really care much about design/aesthetics as an example in this discussion. I've given you an example of a better app, it's up to you whether you continue to use a worse one as an argument

[dbrgn]

a) That's not true, better terminal emulators do support it, see wezterm above or try to pick a color in iTerm

Other maintainers may do different design- and development-tradeoffs that result in different feature sets.

Oh, so now you require users, who have already done all the color picking, to go through a data conversion pipeline to downgrade to a worse data format (and by the way, you don't accept the copied values as is, so there is one more manual conversion step). How is this burden "fine"?

We don't force anyone to use Tealdeer. It is provided "as is", and if you don't agree with certain decisions, you are free to change the application however it pleases you. There are plenty of other tldr implementations (although I'm not aware of anyone that supports other color spaces than RGB, or maybe HSV).

The tone in this thread is quickly becoming quite negative (claiming that we are forcing our users to downgrade to a bad format, we don't care about usability, etc) and demanding (we must implement a niche feature because different decisions show a lack of care for users). We are trying to balance the development efforts that we do in our free time, for free with the feature requests, and do not owe anybody anything. If you think a feature you have in mind is important, then by all means, implement it and use it yourself or offer your fork to other users. Nobody is preventing you from that.

[eugenesvk]

a) That's not true, better terminal emulators do support it, see wezterm above or try to pick a color in iTerm Other maintainers may do different design- and development-tradeoffs that result in different feature sets.

So what? How does it negate my argument that "if the terminal emulator doesn't have the feature about color spaces" is false?

We don't force anyone to use Tealdeer.

Again, so what? How is this relevant to the discussion whether it's fine to impose some inconvenience on the users?

It is provided "as is", and if you don't agree with certain decisions, you are free to change the application however it pleases you.

I'm also free to point out flaws to the devs and point to better alternatives. Or does this somehow contradict the "as is" clause of your license?

There are plenty of other tldr implementations (although I'm not aware of anyone that supports other color spaces than RGB, or maybe HSV).

So actually there are no other tldr imlementations relevant to this issue

The tone in this thread is quickly becoming quite negative (claiming that we are forcing our users to downgrade to a bad format,

well, this is just a fact stemming from your design decision to expose the library's enum "as is", which you yourself insist is fine because it "isn't something you'll do every day", so this negativity is on you

we don't care about usability, etc) and demanding (we must implement a niche feature because different decisions show a lack of care for users).

while this is something you've just made up. Quote a single demand. So this negativity is also on you.

We are trying to balance the development efforts that we do in our free time, for free with the feature requests, and do not owe anybody anything. If you think a feature you have in mind is important, then by all means, implement it and use it yourself or offer your fork to other users. Nobody is preventing you from that.

As is this rant. What if I think this feature is important enough to raise awareness about, but not enough for a fork? Does anybody prevent you from considering this possibility?

[niklasmohrin]

Does anybody prevent you from considering this possibility?

We have considered your suggestion, but concluded that we think that it fits neither with our goals for the software nor with our capabilities regarding development time and maintenance workload.

I'm also free to point out flaws to the devs and point to better alternatives.

Yes, very much so. However, we are free to reject your suggestions (even without a particular explanation). The arguments provided do not convince us that the feature is worth implementing, so the answer is no.

If the rejection of your proposal makes tealdeer unusable for you, I can only remind you that you are free to just not use the software.

[eugenesvk]

Does anybody prevent you from considering this possibility?

We have considered your suggestion,

That's not what this sentence meant, it was about considering the simple fact that forking isn't the only available option

but concluded that we think that it fits neither with our goals for the software nor with our capabilities regarding development time and maintenance workload.

Curious, what 'goal' does your software have that does not fit with convenient user configuration?

so the answer is no.

The answer to which question? You haven't answered any of my actual questions, and the one you think you answered now is the one I didn't ask