Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
4 "the right side is correct whereas the right one is not" -> "the [left] side is correct ..."
source | link

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the rightleft side is correct whereas the right one is not.

Question 2

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Answer 2

And here we have the solution! :)

In order to have tmux behave correctly we have to call it telling him that we are in a 256 colours enabled environment.

TERM=xterm-256color /usr/bin/tmux

For convenience we could alias this (i.e. you add alias tmux="<the line above>" to your ~/.bashrc).

tmux interprets correctly the non-bold "bold-alternative" colours

Calling tmux as tmux -2, for forcing tmux to run with 256 colours support (instead of redefining the TERM environmental variable) will not allow for correct interpretation of the "bold-alternative" 8 colours (i.e. the brighter variant will also result having a bold typesetting). Therefore, I highly recommend to use the solution here above for having both correct 256 colours interpretation and non-bold "bold-alternative" colours.

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the right side is correct whereas the right one is not.

Question 2

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Answer 2

And here we have the solution! :)

In order to have tmux behave correctly we have to call it telling him that we are in a 256 colours enabled environment.

TERM=xterm-256color /usr/bin/tmux

For convenience we could alias this (i.e. you add alias tmux="<the line above>" to your ~/.bashrc).

tmux interprets correctly the non-bold "bold-alternative" colours

Calling tmux as tmux -2, for forcing tmux to run with 256 colours support (instead of redefining the TERM environmental variable) will not allow for correct interpretation of the "bold-alternative" 8 colours (i.e. the brighter variant will also result having a bold typesetting). Therefore, I highly recommend to use the solution here above for having both correct 256 colours interpretation and non-bold "bold-alternative" colours.

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the left side is correct whereas the right one is not.

Question 2

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Answer 2

And here we have the solution! :)

In order to have tmux behave correctly we have to call it telling him that we are in a 256 colours enabled environment.

TERM=xterm-256color /usr/bin/tmux

For convenience we could alias this (i.e. you add alias tmux="<the line above>" to your ~/.bashrc).

tmux interprets correctly the non-bold "bold-alternative" colours

Calling tmux as tmux -2, for forcing tmux to run with 256 colours support (instead of redefining the TERM environmental variable) will not allow for correct interpretation of the "bold-alternative" 8 colours (i.e. the brighter variant will also result having a bold typesetting). Therefore, I highly recommend to use the solution here above for having both correct 256 colours interpretation and non-bold "bold-alternative" colours.

3 Added further information about `-2` flag for *tmux*
source | link

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the right side is correct whereas the right one is not.

Question 2

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Answer 2

And here we have the solution! :)

In order to have tmux behave correctly we have to call it telling him that we are in a 256 colours enabled environment.

TERM=xterm-256color /usr/bin/tmux

For convenience we could alias this (i.e. you add alias tmux="<the line above>" to your ~/.bashrc).

enter image description heretmux interprets correctly the non-bold "bold-alternative" colours

Calling tmux as tmux -2, for forcing tmux to run with 256 colours support (instead of redefining the TERM environmental variable) will not allow for correct interpretation of the "bold-alternative" 8 colours (i.e. the brighter variant will also result having a bold typesetting). Therefore, I highly recommend to use the solution here above for having both correct 256 colours interpretation and non-bold "bold-alternative" colours.

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the right side is correct whereas the right one is not.

Question 2

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Answer 2

And here we have the solution! :)

In order to have tmux behave correctly we have to call it telling him that we are in a 256 colours enabled environment.

TERM=xterm-256color /usr/bin/tmux

For convenience we could alias this (i.e. you add alias tmux="<the line above>" to your ~/.bashrc).

enter image description here

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the right side is correct whereas the right one is not.

Question 2

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Answer 2

And here we have the solution! :)

In order to have tmux behave correctly we have to call it telling him that we are in a 256 colours enabled environment.

TERM=xterm-256color /usr/bin/tmux

For convenience we could alias this (i.e. you add alias tmux="<the line above>" to your ~/.bashrc).

tmux interprets correctly the non-bold "bold-alternative" colours

Calling tmux as tmux -2, for forcing tmux to run with 256 colours support (instead of redefining the TERM environmental variable) will not allow for correct interpretation of the "bold-alternative" 8 colours (i.e. the brighter variant will also result having a bold typesetting). Therefore, I highly recommend to use the solution here above for having both correct 256 colours interpretation and non-bold "bold-alternative" colours.

2 added 403 characters in body
source | link

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the right side is correct whereas the right one is not.

Further questionQuestion 2

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Answer 2

And here we have the solution! :)

In order to have tmux behave correctly we have to call it telling him that we are in a 256 colours enabled environment.

TERM=xterm-256color /usr/bin/tmux

For convenience we could alias this (i.e. you add alias tmux="<the line above>" to your ~/.bashrc).

enter image description here

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the right side is correct whereas the right one is not.

Further question

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Short answer

It's a bug.

Full answer

It looks like the "correct" visualisation is the one on the left, where the bold font are not rendered. For what I could understand (here is the reference) the bold attribute was used, originally, to set the highlighted version of the 8 base colours.

Historically, there has been a one-to-one correspondence between the bolded versions of the 8 default ANSI colors and the bright versions of the 8 default colors. Back in the day, when a color program demanded the display of bold text, it was probably just easier for terminal emulators to display a brighter version of whatever color the text was (and expect the user to interpret that as bold) than to display a typeface with a bold weight.

Basically, what is happening here is that, in order to use the full Solarized palette, with the orange, purple and all the levels of grey, the colours are called with the bold attribute, which in turn refers to the alternative 8 colours of the ANSI palette.

Terminal understands this correctly, and shows the orange and the comment grey in normal typesetting, whereas tmux adds an unnecessary bold font to them. In conclusion, the right side is correct whereas the right one is not.

Question 2

Is there a way to disable the bold rendering of tmux?
I still have to do some research about it, and I will update this answer as soon as I find something.

Answer 2

And here we have the solution! :)

In order to have tmux behave correctly we have to call it telling him that we are in a 256 colours enabled environment.

TERM=xterm-256color /usr/bin/tmux

For convenience we could alias this (i.e. you add alias tmux="<the line above>" to your ~/.bashrc).

enter image description here

1
source | link