bugGNU nano - Bugs: bug #58503, [Wish] separate bold from bright ...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58503: [Wish] separate bold from bright (for syntax colors)

Submitter:  Benno Schulenberg <bens>
Submitted:  Fri 05 Jun 2020 05:21:30 PM UTC
   
 
Severity:  1 - Wish Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Thu 30 Jul 2020 07:15:20 AM UTC, comment #4: 

Released in nano-5.0.

Benno Schulenberg <bens>
Group administrator
Sun 14 Jun 2020 11:58:43 AM UTC, comment #3: 

Fixed in git.  A prefix "light" is added in commit 4d10f583, and an attribute "bold" in commit c275c515.

Benno Schulenberg <bens>
Group administrator
Sun 14 Jun 2020 07:55:18 AM UTC, comment #2: 

Oww...  I had tried the 'xterm +pc' that Egmont mentioned in bug #56525, but I didn't see any difference with 'xterm -pc'.  But my comparison was a bit quick, looking only at some lines with magenta, red, and green, and looking only at the xterms sequentially, not side by side.  If I had put them side by side, I might have noticed that the +pc red is slightly darker.  And had I looked at cyan and yellow, I would have noticed the difference.  (Magenta and green still look the same to me for +pc and -pc.)

Anyway, I thought that +pc and -pc weren't doing anything.  But yesterday I noticed that Xfce Terminal now has an option in its Colors tab of the Preferences: "Show bold text in bright colors".  It seems to on by default.  When switched off, the standard colors (0 to 7) can be bold without changing hue or intensity.  :/  Probably few people will switch it off, because then suddenly the display of colors becomes faint and drab.  It will take some getting used to.  And I have had to tone down the color of the foreground white, to be more in balance with the colored text.

So, the workaround for getting bold standard colors is superfluous.  If people want those colors in bold, we'll have to tell them to use +pc or switch off the brightening option.

But... why was this brightening of a bold typeface chosen in the first place?  Even in the original ECMA-48 specification from 1979 it says for SGR 1: "bold or increased intensity".  That is: OR.  Not both.  The Linux console does this fine: it brightens the color when A_BOLD is used.  But terminal emulators... they use a bold font AND they brighten the color.  :/  Hmm...  Maybe they did that because in the beginning few fonts had a bold variant?  And the brightness change was needed to make sure there was a difference?

Anyway, it now means that when the "brighter bold" option is switched off in the emulator, that the "bright" prefix in nano is a complete misnomer: it doesn't brighten the color, it boldens the typeface.  :|

Benno Schulenberg <bens>
Group administrator
Sat 13 Jun 2020 08:52:43 AM UTC, comment #1: 

Changing the meaning of 'bright' is not a good idea: it changes the look of the existing syntaxes too much -- I am too used to seeing the brightly colored keywords in bold.  And introducing an option to change the meaning of 'bright' (possibly per syntax)... it would be confusing, the meaning of 'bright' wouldn't be fixed, it would depend on an option being set or not; also, it would add another option.

It will be better to introduce a new prefix that only means brighter, lighter, intenser, and never means bold.  It should be a prefix and not a modifier because it changes the color, the hue, so it should be part of the color name.  Modifiers will change something other than the color: the typeface.

What to call the prefix?  I started out with 'live', moved to 'high', have considered 'hot' and 'hard' and 'rich' and 'full' and 'max', and landed on 'lit'.  But none of those really work well.  "Full" would be good if it didn't have the ring of "bold".

Benno Schulenberg <bens>
Group administrator
Fri 05 Jun 2020 05:21:30 PM UTC, original submission:  

As suggested two years ago by myself (https://lists.gnu.org/archive/html/nano-devel/2018-01/msg00033.html) and last year by Egmont Koblinger (in comment 9 of bug #56525): it would be nice if the 'bright' prefix of color names did not make the characters also bold.  There ought to be a separate attribute, 'bold', that makes the affected characters bold, and 'bright' should just mean brighter/intenser.

Benno Schulenberg <bens>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-30 bens Open/ClosedOpen Closed
    2020-06-14 bens StatusIn Progress Fixed
    2020-06-09 bens StatusNone In Progress
        Assigned toNone bens

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code