netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sirius <sirius@trudheim.com>
To: Gedalya <gedalya@gedalya.net>
Cc: Dragan Simic <dsimic@manjaro.org>, netdev@vger.kernel.org
Subject: Re: iproute2: color output should assume dark background
Date: Thu, 23 May 2024 16:11:36 +0200	[thread overview]
Message-ID: <Zk9OmHeaX1UC8Cxf@photonic.trudheim.com> (raw)
In-Reply-To: <7cfcca05-95d0-4be0-9b50-ec77bf3e766c@gedalya.net>

In days of yore (Thu, 23 May 2024), Gedalya thus quoth: 
> On 5/23/24 9:23 PM, Dragan Simic wrote:
> > > And what about linux virtual terminals (a.k.a non-graphical consoles)?
> > 
> > In my 25+ years of Linux experience, I've never seen one with a
> > background
> > color other than black.
> 
> You kind of missed my question: Do we make a new rule where a correctly
> set COLORFGBG is mandatory for linux vt?
> 
> That's what I meant. The fact that both vt and graphical terminal
> emulators tend to be dark is another point.
> 
> My point is you can't rely on COLORFGBG. You can only use it if/when set.
> 
> A reasonable default is needed.

For the colours like blue and magenta, using \e[34;1m and \e[35;1m would
make it more readable against dark background. And testing with a dark
background right now, that would suffice the other colours are not
problematic to read. (It uses the "bright" version of the two colours
rather than the usual.)

That would be a miniscule change to iproute2 and would resolve the
problem no matter what background is used. I need to test with schemas
like solarized light and dark as well, as they are finicky.

-- 
Kind regards,

/S

  parent reply	other threads:[~2024-05-23 14:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22 19:21 iproute2: color output should assume dark background Gedalya
2024-05-22 19:27 ` Dragan Simic
2024-05-23  6:39 ` Sirius
2024-05-23  7:08   ` Gedalya
2024-05-23  7:57     ` Sirius
2024-05-23  8:05       ` Sirius
2024-05-23 12:36       ` Dragan Simic
2024-05-23 13:02         ` Sirius
2024-05-23 13:04         ` Gedalya
2024-05-23 13:19           ` Sirius
2024-05-23 13:47             ` Dragan Simic
2024-05-28  9:07             ` David Laight
2024-05-28  9:40               ` Gedalya
2024-05-23 13:23           ` Dragan Simic
2024-05-23 13:39             ` Gedalya
2024-05-23 14:02               ` Dragan Simic
2024-05-23 14:11                 ` Gedalya
2024-05-23 14:24                   ` Dragan Simic
2024-05-23 14:33                     ` Gedalya
2024-05-23 14:59                       ` Stephen Hemminger
2024-05-23 15:17                         ` Gedalya
2024-05-23 13:50             ` Gedalya
2024-05-23 14:07               ` Dragan Simic
2024-05-23 14:13                 ` Gedalya
2024-05-23 14:26                   ` Dragan Simic
2024-05-23 14:11               ` Sirius [this message]
2024-05-23 14:19                 ` Gedalya
2024-05-23 14:28                   ` Dragan Simic
2024-05-23 14:29                     ` Dragan Simic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zk9OmHeaX1UC8Cxf@photonic.trudheim.com \
    --to=sirius@trudheim.com \
    --cc=dsimic@manjaro.org \
    --cc=gedalya@gedalya.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).