bolding without color spec does not work in 256-color mode

[ossi]

the modarin skins contain this piece:

[viewer]

...
viewbold = ;;bold

this doesn't appear to do anything at all in 256-color mode, so for example bolding in manual pages is not effective.

this works in 16-color mode.
underline works fine in either mode.
it does work when a color is specified.

i tested this with konsole and xterm, so i'm guessing it's not term-related.

[zaytsev]

Wasn't there some trick like in 16-color mode upper colors are shown in bold, and in 256+ mode one has to do some magic? But I think it used to work :-( Did you try to bisect it at least in a very rough way, or you are sure it never even worked?

[ossi]

i just started using themes, so i have no clue whether this is a regression.

from what i can tell, 256-color mode isn't in any way special - "bold" is just an attribute one sets on the char cell. of course, the semantics of that are somewhat questionable when the palette itself already contains all levels of brightness (unlike the "normal" 8-color palette), but whatever.

the _default_ color is color250, and when i include that in the viewbold def, it actually works, so this isn't some "attribute compatibility problem". it seems like the fallback path is somehow broken. but then, why would the other combinations just work?

btw, i'm using a slang-based build (ncurses has some input-related problems, so is no option for me).

[ossi]

argh, i messed up the theme names. setting color250 explicitly does not work, but 'white' does. so this actually is an attribute compatibility thing.

the terminal emulators have options like "draw intense colors in bold font" or the inverse "show bold text in bright colors", and with the right settings it actually works (unlike with my usual vga rasterfont). it's only the "remapping" of boldness to higher brightness which does not work for colors outside the "base" range, which seems logical enough.

for maximal compatibility, it would still make sense to adjust the skins, to either use white for the default color, or use a separate color for bold instead of (or in addition to) the attribute.

[zaytsev]

Yeah, this is actually what I meant. I'm not sure how to adjust the skins to make this less obtuse. Maybe you can suggest a patch.

[ossi]

the minimal patch is to just s/ ;;bold/ white;;bold/ in *256*.ini (and maybe the 16M ones as well), but this has the tiny catch that these specs also appear outside viewbold lines. some of these are clearly affected by the problem as well but might need another color, while some others actually have a usable default color. i didn't investigate further. i would recommend inviting all the original authors to have them ponder the "artistic implications" of changing things, and how the fonts being actually rendered in bold or not affects the picture in their view.

[egmont]

Somehow I did not get notified about being cc'd in this ticket, I've just randomly spotted it now. Anyway.

I'm attaching a screenshot. It was taken in gnome-terminal, but konsole and xterm look basically the same, too. My TERM is set to xterm-256color which is the default of all three of these terminals.

I started up mc-4.8.31, compiled against Slang, as shipped by my Ubuntu 24.10. I started it up as mc -S modarin256, navigated to /usr/share/man/man1 and to the bash.1.gz file and pressed F3.

As per the screenshot, words intended to be bold (the all-caps headers, as well as the words bash, sh, ksh, csh) indeed show up in bold (i.e. thicker) typeface.

---

Reading the followup comments, it seems to be that @ossi you'd rather these had a different (brighter) color as well. The solution is to ask for a different (brighter) color in the skin file, then.

I'm, however, not sure why this would have to be this way. I'd argue that whoever designed the modarin skins designed it this way, and we shouldn't alter it, at least not without approval from that person. Assuming that you indeed see the same as I do in the screenshot, it's not a bad behavior at all, just maybe not what you'd prefer.

---

To give a wider context:

ECMA-48 and ITU-T Rec T.416, written with hardware of ~50 years ago in mind, define SGR 1 as "bold or increased intensity". The ambiguous wording probabaly arises from CRT hardware back then just emitting a stronger electron beam, making the pixels appear both bigger and brighter. It's also not entirely clear (or probably: an issue no one thought of when writing these words) whether "increased intensity" with black text over white background should mean brighter color (more photons) or a more intense (darker) black.

Black and white displays were followed by ones capable of displaying 8 colors (using SGR 30..37 / 40..47 commands). Presumably combined with this flag an overall of 16 colors, 8 pairs of darker and lighter variants of the 8 basic colors.

The aixterm extension, as I've seen it often called, presumably originating from the aixterm terminal emulator, adds SGR 90..97 / 100..107 escape sequences to give access to the brighter color variants without making them bold typeface – but no access to the darker variants in normal font weight (or maybe it's subject to a config file). Some call it 16 color mode, some still call it 8 color mode (e.g. terminfo reports 8 as the number of colors). SGR 1 makes the first 8 colors brighter by replacing them with the corresponding entry from the next 8 (i.e. adding 8 to its index), but the next 8 colors are not brightened any further.

Xterm also implements this behavior, with a "+pc" switch to optionally not make any color brighter with SGR 1, i.e. an optional (non-default) behavior where the color and font weight are separated. Many other terminals also do something along these lines.

The Linux console, presumably due to the limitation of the VGA text mode (no access to bold typeface), implements SGR 1 as bright.

256 color support emereges and becomes widespread. The first 16 indices are meant to be the already available 16 colors (in the same order) and have two ways to access: either the old escape sequences (SGR 30..37 and 90..97 for fg, 40..47 and 100..107 for background), or the new ones (SGR 38;5 for fg, 48;5 for bg, followed by the index of the color).

SGR 1 making the color brighter still only applies to the first 8 colors. To my best knowledge, no terminal out there attempts to make any of the colors indexed 8..255 any brighter when combined with SGR 1.

There's a bit of back and forth though regarding the question: Should the first 8 colors, if referred to by the "new way", be subjected to brightening? I definitely recall xterm changing its answer to this question one day, I have vague (possibly faulty) memories about it later reverting that decision. In VTE (GNOME Terminal), which I'm co-developing, we also might have changed it one day, I can't recall. And honestly, I can't recally off the top of my head what's the current behavior here in either of these two terminals.

Also, if I recall correctly, one day terminfo also changed to map indices 0..15 to the "old" (aixterm) escape sequences rather than the "new" (256-color) one in its TERM=xterm-256color definition, making the previous dilemma irrelevant for terminfo-based apps; also making TERM=xterm-256color more backwards compatible with TERM=xterm but perhaps a bit harder to leave this legacy of mixing the two concepts behind.

Truecolor support also emerges and becomes quite popular in graphical terminal emulators. Needless to say, direct RGB truecolors don't change their color with SGR 1.

The Solarized palette becomes quite popular. It's an unusual palette where indices 8..15 are not brighter counterparts of indices 0..7, but completely different colors. In order to be able to use Solarized, GNOME Terminal / VTE adds a config option not to brighten any of the colors on SGR 1.

Some new, modern terminal emulators arise that default to not brightening the color on SGR 1, or outright refusing to implement the feature of brigtening them. With access to 16M different colors, yet no unambigous way of requesting bold typeface, these terminals argue that the only way to move forward is to leave this legacy behind, make the two concepts orthogonal (as they are in every other type of software out there), make the long-standing SGR 1 mean bold typeface only and never to tamper with the color. We at GNOME Terminal / VTE fully agree and flip our default not to tamper with the color, although the legacy behavior (SGR 1 meaning "both bright and bold") is still available as an option. We are surprised that only very few people have some minor complaints, we were afraid to cause a bigger stir.

I'm not familiar with Konsole, but I vaguely recall it has things turned inside out; rather than asking whether bold should also be bright it somehow asks whether bright should also be bold. Makes no sense to me. My knowledge may be incorrect or outdated.

So, that's roughly what we have; the history of how things happened, how we arrived at where we are right now, and the direction quite a few terminal developers see as the future (and I couldn't agree more): to leave behind the legacy caused by hardware of decades ago, and have these two concepts fully separated as any sane person would expect.

To my best knowledge, SGR 1 making the color brighter only ever happened (and still happens in many terminals) to the first 8 palette colors as well as the default foreground color (which I haven't mentioned so far for the sake of simplicity), never to any other color.

Hope this makes sense, and hope it also makes sense that mc's skin files also try to follow this philosophy. Want bold typeface? Ask for bold typeface. Want brighter color? Ask for brighter color. Want both? Ask for both. Now, it might happen that you ask for bold typeface and you also get brighter color (again: with the first 8 colors only); if that's how your terminal behaves then mc won't (and can't) stop that from happening, but that's the unfortunate legacy exception and not the rule that mc's skin files should be built around.

[egmont]

How manpages in modarin256 look to me in gnome-terminal

[egmont]

If you want to modify the skin definition files to pick a brigther color (which, again, I'm not sure is a good idea – this particular skin chose to use bold typeface only and there's nothing wrong with that) then "white" is not really a good choice as it refers to a slot of the user-definable palette which is often off-white in ways we don't know and can't control. A brigther color along the grayscale ramp, or the white corner of the 6x6x6 cube are much more reliable to be a brighter white.

[zaytsev]

Thank you for this invaluable background information (no kidding)... sadly, I think it will take a lot of time to sink in for me, and I'm not sure what the consequences should be. I believe that what ossi had a problem with, or, at least what I was talking about, can be illustrated with the following screenshots:

Left is old mc on old RHEL, right is latest mc on Mac. Both in Mac's default terminal application with the same profile / settings, both compiled with S-Lang, both with the default skin. On the left, directory names are bold. On the right, bold is lost. For the reference, latest mc on latest Fedora in Konsole is also boldless.

I'm used to the left version and at some point I've started noticing that right is happening on my machines. I couldn't grok this craziness though, and just accepted that I will see different things, even though I liked the old way...

[egmont]

Left is old mc on old RHEL, right is latest mc on Mac.

That's a lot of differences. mc 4.8.7 (left) already had 256-color support, but details could have changed since then (although I don't recall). The definition of the default skin did not change in relevant ways. Slang was upgraded, terminfo might be quite different.

TERM might be different as well, and this could easily be relevant. What's the value of TERM in both cases? What happens if you manually set it to "xterm", and what with "xterm-256colors"?

---

The default skin defines core/_default_ as "lightgray;blue", that's the standard (non-bright) white color on blue background; and filehighlight/directory as "white;", that's bright white and the same background. So this definition clearly asks for a brighter color and the same typeface.

If you'd want the same darker color and bold typeface, you should ask for that: ";;bold".

To be honest, I don't know why it shows up with bold typeface but not brighter color in the left screenshot. It could perhaps help to evaluate the "script" log of the two session and examine what escape sequence is sent out in each.

I am personally much more used to the brighter color (perhaps with bold typeface, too), because that's what you get on the Linux console, and that's what I recall getting in my graphical terminals (e.g. xterm, iterm2, gnome-terminal) back in the days when 16-color support (TERM=xterm) was the norm. Also, personally I prefer the bright variant, but maybe that's me.

The default skin is obviously something that should work on 16-color systems, and it's sort of impossible to control what happens in everybody's terminal, which one decides to override our request in what way. Differences in terminfo, differences in slang vs ncurses, their particular versions might also matter. Differences in the choice of the terminal and their configuration also matters, obviously. It's hard to foresee how a certain change in the config file will end up for thousands (hopefully millions) of users.

---

I don't have access to a mac, can't test with its terminal. Just noticed that with TERM=xterm, the behavior is different in gnome-terminal vs. xterm. In xterm directories are of bold typeface (but same color as normal files), in gnome-terminal they are not bold (and same color as normal files, i.e. very same style). No idea why, investigating...

[ossi]

the key point is that an actual physical implementation of "bold" is not necessarily there.

i'm using a vga-derivative font, because this is just so much easier to read on dark background than the usual thinner fonts. and no, boldening a thinner font doesn't work for me, because i find the vertical boldening counter-productive.

i tried a vga-like ttf font (flexi ibm vga), but it just isn't right; it wastes a lot of space.

anyway, the consequence is that i'm using a vertically condensed vga raster font to this day. and somewhat unsurprisingly, terminals are unable to render it in bold. i'm not sure one could even do that sensibly with a vga-like font at all, except on a hi-dpi display.

and obviously, in the linux console, actual bold won't be available, either, even when a user-space implementation that supports 256 colors is available.

so the upshot is that the themes need a fallback to render bold as higher brightness to be useful for me at all, regardless of the author's artistic vision. and honestly, it doesn't look bad at all. for the time being i'm using a hacked theme, but it would be probably a better idea to have an option in the engine to do the remapping automatically, like terminals historically do.

[egmont]

Okay, here's something...

For me, the different rendering in xterm vs. gnome-terminal, when TERM=xterm (8/16-color support claimed), boils down to a difference in COLORTERM (or lack thereof). xterm does not set COLORTERM, gnome-terminal sets COLORTERM=truecolor (which is a nonstandard way of denoting truecolor support).

It's unclear to me yet where exactly it boils down to that difference.

In lib/tty/color-ncurses.c, tty_color_try_alloc_lib_pair() there's a section titled "In legacy color mode, change bright colors into bold" where bright colors are manually modified to be non-bright but bold instead (which, in turn, might be overwritten by the terminal emulator to still become bright).
I guess the reason is that mc's syntax files allow for 16 colors, but ncurses only accepts 8 colors as well as possibly the bold flag, so that's the way we can map them to ncurses's API. This mapping is subjected to not using 256 colors, and to not using truecolors (truecolors is unsupported in ncurses, so that part always holds).

I can't see a similar logic for slang, though. Maybe I'm missing it, maybe something like that is built into slang, I don't know.

So... I don't have answers yet. All I can tell is: While I think I have a pretty good picture about what's happening in terminal emulators; when it comes to what happens in slang, ncurses and mc I'm also lost.

[egmont]

[ossi] so the upshot is that the themes need a fallback to render bold as higher brightness to be useful for me at all

I think "for me" is the key point here.

The vast majority of today's terminals offer at least 256 but pretty often 16M colors, offer bold typeface, italic typeface, underlined, some other decorations, and all combinations of these.

Several of these terminals also cleared up the legacy mess that occasionally (for the first 8 colors only) washed up two concepts (boldness vs. brightness) and made them totally independent, as it clearly would have been everywhere since day 1, had it not been due to hardware limitations half a century ago. All the terminals I'm aware of have these two concepts separated for the extended colors, i.e. for the colors used by your preferred modarin skin.

If you happen to cripple down on these features, if you prefer a font that does not have a bold counterpart, I'm sorry to say but I believe that's your problem, not mc's. Especially when it comes to your choice of a non-default skin. It's not the skin's job to accommodate to your limiting setup. (If it was, the same logic would imply that all the skins would have to offer a workaround for you, none of them could by design choose a bolder typeface as the only distinguishing feature because that wouldn't work for you.)

I firmly disagree that skins would need to be fully functional if support for a certain feature is artificially eliminated from the game.

I am fully supportive of making sure that the default skin uses brighter colors here. I am fully supportive of having some skins that use different colors there (and we do have some). I am fully supportive of adding a brand new skin to mc designed by you, if it looks comparable in quality to the skins we already have, and is not just a single color away from the ones we already have.

Also let me note that with terminals that fully separate the two concepts, outside of mc the "man" command also doesn't let you see bold text (because they only apply boldness which is lost for you). And in every other app that would use bold typeface as the sole distinguishing feature, it's again lost. So mc isn't even be the right place to work around the lack of bold typeface, a patch to your terminal emulator to alter the color (even in case of 256 or 16M colors) would be a better place. Of course a much quicker partial fix is to edit the skin definition file for yourself, but I see no reason to make it upstream; it would partially fix a problem that you created for yourself, and would fix that at the wrong place.

[ossi]

i started using modarin, because it has higher contrast than the default theme. i'm basically using it as an accessibility feature to compensate for aging eyes, without having mc look like shit (unlike with the alternative 16-color themes).
the choice of font boils down to the same reason (though i've always used it), constrained by technical limitations. kmscon isn't getting any traction, so i can't really argue for that use case, but technically it's the same situation.

i'm not sure why you're railing about the themes when i strongly suggested that the engine should implement this fallback. it should be rather easy to implement, and it won't insult the eyes of anyone who doesn't want to use it.

i'm also not sure what your point about man is. it's using the old sequences, and therefore every terminal is able to render bold as bright just fine.

[egmont]

i'm not sure why you're railing about the themes when i strongly suggested that the engine should implement this fallback.

Could you please be more specific? How would you imagine this feature to look like?

Would it be subjected to a new config option? Would it apply to a certain pre-defined contexts such as "viewbold"? Would it apply to those colors that have "bold" in their definition?

How would the engine make up a brighter color? Suppose that in 256 color mode you have a color with red=2, green=4, blue=5 (or any other values) on the 0..5 range of the 6x6x6 cube. Which color would be its brighter counterpart? Out of the available 6x6x6 colors, you can't make it brighter without severely affecting the hue.

i'm also not sure what your point about man is. it's using the old sequences, and therefore every terminal is able to render bold as bright just fine.

I'm aware of at least one popular terminal that firmly refuses to implement this legacy behavior and insists that bold means bold. But every terminal could, if it wanted to, easily implement a feature of brightening any color instead of making them bold, if they wanted to. Even the 256-color palette ones or direct RGB colors. That would fix your accessibility problems in many apps, not just mc.

That point that you are entirely missing here is that some of the terminal developers (including myself) have a shared vision here, a direction we are going towards. And that vision is to clearly separate these two concepts. We believe that if you want to have a brighter color, the proper way is to ask for a brighter color. If instead you wish to ask for bold, and somewhere (doesn't matter where, could be in mc's engine, or your terminal, or an intermediate layer, wherever) have some magic in place that converts that boldness to brightness instead, then you disagree with our vision, you look backwards to the constraints and by-products of the long-gone hardware limitations of the past, rather than forward to the clean and maintainable future. The clean and maintainable future is: if you want to have a brighter color, have a skin file that specifies that brighter color. Let everything be what it is, rather than something else and then someone along the way somehow magically trying to figure out what else you meant instead of what you said.

But if you want to override, why would you want to do it mc and no other app? Makes no sense to me. Instead of implementing the override feature in mc's engine, "fixing" only mc and no other app for you, you could go ahead and implement this override feature in your preferred terminal, fixing all the apps at once. Without being limited to the entries of the 6x6x6 cube and 24 long grayscale ramp.

[zaytsev]

What's the value of TERM in both cases?

Old (bold) RHEL - "screen", Mac is "xterm-256color".

What happens if you manually set it to "xterm", and what with "xterm-256colors"?

TERM=xterm makes it bold on both, TERM=xterm-256color makes it thin on both machines.

I don't have access to a mac, can't test with its terminal. Just noticed that with TERM=xterm, the behavior is different in gnome-terminal vs. xterm. In xterm directories are of bold typeface (but same color as normal files), in gnome-terminal they are not bold (and same color as normal files, i.e. very same style). No idea why, investigating...

Exactly! My point is, I think that historically they were always bold for xterm (majority of) users, but not because they were requested to be bold, but because this is how things used to work in practice. Now the bold got lost in 256-color mode for the default skin, but there was not enough traction to bring it back. Actually I found two tickets to that effect:

• #3048
• #3626

I think in #3048 you've got to the bottom of the problem. I wonder if I should just reopen #3048 and replace default.ini with your bold version ;-) The inconsistency for the default skin is not good in my opinion, and one can argue that it was designed with bold in mind. Maybe we would even do it for all 16-color skins not touching ones that have a 256-color version?

[ossi]

Replying to egmont:

Would it be subjected to a new config option?

yes, i already wrote that.

Would it apply to those colors that have "bold" in their definition?

such a low-level implementation seems simplest and adequate.

Out of the available 6x6x6 colors, you can't make it brighter without severely affecting the hue.

yes, brightening already light colors would inevitably reduce their saturation and possibly alter their hue.
i don't think that's much of a concern, because bold light colors are not really expected anyway (they would be rather annoying).

I'm aware of at least one popular terminal that firmly refuses to implement this legacy behavior and insists that bold means bold.

but why would i care? i'm obviously not going to use it, because it won't even show man pages the way i want.

That would fix your accessibility problems in many apps, not just mc.

i'm having that problem only in mc. it's the only console/tui program that i use that needs such a broad spectrum of char attributes.

Instead of implementing the override feature in mc's engine, "fixing" only mc and no other app for you, you could go ahead and implement this override feature in your preferred terminal, fixing all the apps at once.

if i (hypothetically) want to use that feature in kmscon in addition to my preferred gui terminal, then that's already two terminals. on top of that, implementing this in the terminal would be incomparably more risky, apart from the difficulty of getting this past the maintainers, given that vision of "some" of you.

also, from a conceptual pov, reinterpreting the skin is primarily an application feature. it wouldn't hurt to have support for that in the terminal, but this is neither necessary nor architecturally clean. it's legacy thinking rooted in the status quo you want to get rid of. ncurses/slang might be appropriate places for centralizing such functionality.

[egmont]

@zaytsev

Old (bold) RHEL - "screen", Mac is "xterm-256color".

"screen" is yet another completely different animal. I presume you have this TERM because you're also running the "screen" software layer, correct? That might also modify things in its weird ways that I'm not familiar with.

I wonder if I should just reopen #3048 and replace default.ini with your bold version ;-)

It's confusing that we're talking about two different things in this very issue here, ossi's problem is not with the default skin.

I agree that we should continue this discussion in the reopened #3048.

[egmont]

@ossi

This obsolete idea of washing up two supposedly independent concepts clearly exists purely because of legacy reasons, arising from limitations of long-gone hardware. In software terminals, for decades now, there was no good reason to keep them washed up, except for backwards compatibily, or tradition if you will.

Look at anywhere else in the computer world. You open a .doc file, where in MS Word or Libre Office can you specify to display bold text with brighter colors? Nowhere. You load a webpage in your browser, where do you configure it to display bold text in bright? Nowhere. Are you aware of any other piece of software infrastructure out there that offers an option for this? I'm not.

This legacy hack is specific to terminals, and even within them, specific to the default color as well as the basic 8 palette colors. None of the terminals I'm aware of have ever tampered with any of the extended colors beyond the basic 8 ones when it comes to bold.

Some of us have recently put effort into stopping this, into leaving behind this confusing and unnecessary legacy. You're not only looking backwards to this legacy, you even want to extend its scope to new areas that it has never reached before: to the extended colors as well. You absolutely clearly want to take a big step backwards. I'm not your partner in this.

---

You intentionally degrade your user experience by choosing a font that doesn't have a bolder counterpart, and you don't want to change that. You intentionally degrade your overall experience not in mc, but in your terminal, unbeknownst to mc. And you expect to remedy this situation not where you degraded it, i.e. in the terminal, where you'd have plenty of options (e.g. faking bold by overstriking the same glyph with an offset, or taking bold glyphs from a completely different font, or brigthening it); no, you expect to remedy this situation in a component that is absolutely not responsible for the degradation. You break your experience in the terminal and expect to fix it in mc.

It just so happens that there's only one appication, mc, that you regularly use where your degraded configuration of your terminal causes problems for you. It there were two, would you still expect those two apps to both work it around for you?? If you start using such a second app in the future, will you file a similar feature request against them?? If there were a hundred, would you expect a hundred apps to implement a brigthening feature??

The absolutely unreasonable feature of brigtening some colors when bolded resides in some terminal emulators. You want to extend the scope of this legacy misfeature, but you don't want the extension to also live where the current variant lives, you want the extension to live elsewhere, in applications like mc that have nothing to do with it and have never been responsible for such an unreasonable behavior.

You also ignore the fact that terminal emulators could implement this misfeature in a good quality (applying a consistent amount of brigtening, and keeping the hue), whereas applications like mc could only implement it in a bad quality (due to the coarseness of the 6x6x6 cube: necessarily by applying an inconsistent amount of brigtening, and often notably changing the hue).

You break the user experience for yourself. You aim to fix it not where you broke it but in a different, innocent component. You want to extend the scope of a legacy obsolete concept, and you want this extension to live somewhere else than where the current legacy lives, you want to infect a brand new component with this legacy that should have already died out. And you are okay with a bad quality (wrong hue) implementation, rather than insisting on a good one.

---

Currently mc gives you what you ask for. (Well, except for the bold property, but that's not mc's fault, mc asks for the right thing, it's just that you choose to configure your terminal to ignore this property.) If you ask for a darker color, you get a darker color. If you ask for a brighter color, you get a brighter color.

Your preferred skin currently asks for a darker color. You don't the like the result, you want to see a brighter color. Okay. But you refuse to change your skin definition to ask for a brighter color. Why?????

Instead, you claim that the skin should still ask for a darker color, and some magic built into mc's engine should know that you meant something else, it should apply some hardwired formula that magically results in the bright color that you actually want to have. You refuse to ask for what you want, you're not willing to say what you actually mean. Instead, you want a piece of logic to convert what you say into what you mean.

So, let's have an additional logic in the source code, a magic hardwired formula that happens to please one certain user's exact needs, let's implement and maintain this code; let's have a config option, a UI option, its translations to many languages, help/documentation, its translations again??

Your request revolves around what you want to have, there's not a single insight into whether others could potentially find this useful. Given your unusual choice of font that lacks bold typeface, and given the inevitably altered hue, I have serious doubts.

And what if one day someone else comes along and wants a different formula?? E.g. they find the amount of brigtening too much, or too little? Or they want the inevitable hue change to work somewhat differently? Or their font doesn't have italic and they want to have it replaced by underlined? Or they are color blind in some way and want mc to automatically adjust the colors to be more readable with their particular condition? How deep is this rabbit hole??

---

Putting aside for a second all the problems I have with your proposal:

In #2165 / #3169 I created the skin selector dialog and I wanted to add a couple of additional options to tweak some details of skins. In comment 10 of the first bug, andrew_b rejected my idea, basically claiming that he expects skins to be entire packages, rather than components of a DIY kit. I mean, you can still fine-tune all the parameters to your exact liking, but, by design, this involves editing the skin definition files, rather than mc providing such options.

I can't see why the current request wouldn't also fall under this umbrella.

---

I'm sorry but not a single bit of your thought process in this feature request makes any sense to me whatsoever.

You aren't entirely happy with the design of a skin? Feel free to edit it to your liking. Tell mc what you want. Not a riddle and a solver algorithm, but the result. Want a brighter color than what's defined there? Replace that definition with a brighter one. Done in a minute or two. End of story.

[zaytsev]

Added stuff to #3048.

[ossi]

I'm sorry but not a single bit of your thought process in this feature request makes any sense to me whatsoever.

yes, obviously. maybe you should actually pay attention to the reasons i've given, rather than presenting us with a wall of text that boils down to saying that i'm an idiot because i don't share your vision?

also, considering hypotheticals can be useful, but only if they bear any relation to actually plausible future situations.

[egmont]

You haven't answered my questions.

Are you aware of any piece of software – apart from terminal emulators – that offer to automatically brigten bold text? Can web browsers, document readers, text editors do it? Can terminal-based apps like Vim, Emacs, Ranger, Less etc. do it? Can you please come up with just one example?

Why would mc be probably the only one that needs this feature, apart from the fact that it just randomly so happens that it's the only application where you (that is: 1 person so far) run into this problem, due to you yourself artificially crippling the capabilities of another component in the stack?

Why do you think that there's anyone else out there who would find this brigtening feature desired? Why do you think that for them this need would also be restricted to mc and not relevant in other apps, i.e. mc would be the architecturally correct place for this feature; rather than terminals where such feature already exists, where it could brighten color of other apps as well, and where it can be done in a better quality?

Why do you think that a solution that results in brigthening colors in a bad quality, with altering the hue, would be satisfactory to other people who might be looking for this feature?

There are practically infinite ways one might automatically convert skins to other skins. What would make this 1 particular method that you're looking for be the one that mc includes?

Why should developers spend multiple magnitudes more work on implementing this feature – or even purely on having this discussion – for supposedly hardly more than 1 user, compared to the tiny cost of you just editing your skin file to your liking?

I find it absolutely ridiculous that you refuse to tell mc what you need, which you could in about a minute, and instead you expect mc's developers to come up with an engine that would automatically adjust things in the very particular ways that you happen to be looking for.

Anyway, I'm just expressing my opinion here, I'm not the one who's going to accept (and implement) or reject this feature request. Let's see what mc's active developers think about it. If anyone goes ahead and implements it, I won't try to stop that.

[egmont]

What really should be done, if changing the colors and attributes in some automated way is a desired feature, is:

Create a brand new tool, somewhere along the lines of "luit" or "script", which intercepts the terminal traffic and modifies its SGR escape sequences according to custom rules.

It would have a config file with a flexible, almost programming language-like syntax which allows you to set up relatively complex rules that transform the input colors and attributes into output ones. Simple mathematical operations on the r/g/b color values, branching etc. should be possible. Probably Lua is a great choice.

The tool catches the incoming traffic, tracks which colors and attributes are set by the hosted app. Every time something changes, it runs the user-defined function, passing it the all current colors and attributes that should be in effect according to the hosted app. The user-defiend function returns the colors and attributes to actually use instead. This tool then emits towards the host terminal the escape sequences that implement the modified look.

Such a tool would work on any terminal emulator, could mangle the look of any terminal-based application, and could work according to arbitrary rules that users can easily specify according to their own needs. Also, since it'd be a wrapper, users could easily switch the behavior on a per-application basis, by invoking this tool with a different config file.

I believe that this could be a tool generic enough to attract a fair amount of users.

[ossi]

Replying to egmont:

You haven't answered my questions.

i actually did, in a previous comment. you just didn't care to take it into account properly.

Are you aware of any piece of software – apart from terminal emulators – that offer to automatically brighten bold text?

just about every browser allows you to add a custom stylesheet in some way. the same can be done with qt and gtk.

more broadly, while many apps/environments have moved from options to themes, they often still have options to override or parameterize aspects of the themes.

Why would mc be probably the only one that needs this feature,

because mc is special. the central reason why i still use mc rather than a more powerful file manager like krusader is that it's a natural extension of the shell. readline of steroids, sort of.

the market for tui applications is virtually dry. this is evidenced by how neglected even critical tools like aptitude are.

if you have evidence to the contrary and can name other applications that would actually benefit from it, go ahead.

due to you yourself artificially crippling the capabilities of another component in the stack?

i'm not crippling it, i'm optimizing the trade-offs for the use case i actually care about. it's sad that you apparently don't care about this absolutely central aspect of all computing (or engineering in general).

Why do you think that there's anyone else out there who would find this brightening feature desired?

statistically, only about 1% of the users bother reporting their gripes.

Why do you think that for them this need would also be restricted to mc and not relevant in other apps,
i.e. mc would be the architecturally correct place for this feature; rather than terminals where such feature already exists,

i already told you.

I find it absolutely ridiculous that you refuse to tell mc what you need,

the only ridiculous thing here is your presumptuousness.

which you could in about a minute,

the time it took me to figure out the problem, analyze it, and come up with a workable (but half-assed) solution is actually better measured in hours.

Replying to egmont:

What really should be done [...]

this is so ridiculously over-engineered, fragile, and user-hostile, that without the context of the conversation so far, i would have assumed that you're trolling.

[egmont]

just about every browser allows you to add a custom stylesheet

Can a custom stylesheet change the color if boldness is requested? I don't know.

Terminal emulators hosting certain application (e.g. mc) is in many aspects analogous to web browsers displaying some websites. Terminal emulators play a comparable role to web browsers, just in a "parallel world". Apps such as mc play a comparable role to websites or webapps such as GMail. Therefore, the correct analogy of browser-based custom stylesheets would be to add the color mangling feature not to mc, but to whichever terminal emulator(s).

Also, these browsers offer a somewhat generic framework where you can specify tons of possibilities. In a quite "user-hostile" way, to quote you. Not just ONE (1) single hardcoded behavior, apart from the default, via a UI checkbox, as you wish to have in mc.

Yet, in mc, you are requesting a feature that allows to alter the skins on the fly in exactly ONE (1) hardcoded way; the way only you happen to need. There's absolutely no sign in your proposal to add a more generic approach that might be useful for anyone who has somewhat different needs than yours.

because mc is special.

Not sure what makes you think so. I use mc almost every day, I love this software, I have even contributed to it a thing or two, yet I don't find it special. I find it just one of a plethora of high-quality fullscreen terminal-based apps which I happen to use whenever this happens to be the one that lets me achieve my goals in the most effective or most convenient way, and don't use when I'm better off with other tools.

---

this is so ridiculously over-engineered

It's a generic idea for something roughly analogous to custom stylesheets. It's engineered exactly to the extent of making it generic: making it apply not just to mc but any app, and making it support not just ONE (1) particular way of altering the colors (your preferred way) but any comparably simple logic that someone could imagine.

fragile

I don't see any reason for this.

and user-hostile

Barely more user-hostile than coming up with a custom stylesheet that overrides the ones in homepages, brightening the bold colors (if it's possible at all). It could ship several example configurations, one of which could be what you happen to need.

Anyway, probably no one is going to implement this, so there's no point in further pondering about it.

---

We've heard each other, our opinions are about as far away from each other as possible, with apparently zero chance of getting even just a little bit closer to each other. Again, I'm not the one making any decision here, and if someone adds such an option to mc I couldn't care less, I wouldn't want to stop them.

I have already spent waaay too much time on this stalled conversation, much more than it deserved. I simply have no more time for this. You might reply to this comment, I don't care, but I have no intent to follow up and keep this going.

[ossi]

Replying to egmont:

Can a custom stylesheet change the color if boldness is requested?

yes. ​https://stackoverflow.com/a/51973019/3685191

[...] the correct analogy of browser-based custom stylesheets would be to add the color mangling feature not to mc, but to whichever terminal emulator(s).

Also, these browsers offer a somewhat generic framework where you can specify tons of possibilities. In a quite "user-hostile" way, to quote you. [...]

correct, and i wouldn't propose it as a solution. nonetheless, you asked about it specifically, so you got an accurate response.

more interesting would be the question whether text-based browsers support that ... and obviously they do, when run in a terminal that supports it. and of course they'd run into the same problem as mc with 256 colors, though that seems rather academical to me, as a site complex enough to need it would be most likely utterly broken in a text browser anyway.

There's absolutely no sign in your proposal to add a more generic approach that might be useful for anyone who has somewhat different needs than yours.

come up with examples that actually make sense, and we can debate them.

as far as i'm concerned, i'm just proposing a minor extension to #3169. so ... are you going to argue against yourself now?

because mc is special.

Not sure what makes you think so.

the fact that it's a TUI application that integrates seamlessly with the shell is a pretty unique value proposition. for just about everything else, you can use a "proper" GUI application to better effect, given that you're on a graphical desktop anyway (except when firefighting a severely broken system).

[egmont]

as far as i'm concerned, i'm just proposing a minor extension to #3169. so ... are you going to argue against yourself now?

A decision was made there ages ago and I accepted that decision. I have no intention to resurrect that discussion and try to persuade mc devs to change their minds and accept that bit of my work. We all have better things to do.

Also, let's note that if we already had several options there, if my work had been accepted, it still wouldn't imply an automatic green light for any new idea. It would be a necessary but not sufficient condition.

Technically, implementing your request would be a small addition to that feature. That's not my main concern. My problems with your request are conceptual ones. I went through them a couple of times already, I won't repeat them.

[egmont]

Can a custom stylesheet change the color if boldness is requested?

yes. ​https://stackoverflow.com/a/51973019/3685191

That's half of the story: to find bold text (putting aside that on the web the font weight is a 0..1000 linear scale so I'm not quite sure the selector shown there is robust). But can you programatically change whatever color it has to a somewhat brighter one? I'm not well-versed in this topic, a websearch of about a minute didn't yield useful results for me.

[ossi]

you can hack javascript into css.

but going into the specifics is really besides the point here.

[egmont]

but going into the specifics is really besides the point here.

Finally something we agree on :-)