All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Cordes <peter@cordes.ca>
To: "Pádraig Brady" <P@draigBrady.com>
Cc: Karel Zak <kzak@redhat.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	kerolasa@gmail.com, "Dale R. Worley" <worley@alum.mit.edu>,
	mrmazda@earthlink.net, util-linux <util-linux@vger.kernel.org>
Subject: Re: tty[1-6]: colors a negative accessibility/usability trend
Date: Sun, 01 Mar 2015 11:14:40 -0400	[thread overview]
Message-ID: <20150301151440.GV3933@cordes.ca> (raw)
In-Reply-To: <54F314D1.2080003@draigBrady.com>

On Sun, Mar 01, 2015 at 01:32:01PM +0000, Pádraig Brady wrote:
> On 27/02/15 13:48, Karel Zak wrote:
> >  This is not implemented yet, I (or any volunteer?) will try to add to code 
> >  an extra layer to avoid the hardcoded sequences and read the colors from terminfo.
> 
> I'd be careful to not over engineer that.
> coreutils currently hardcodes ansi sequences,
> and I've not heard specific complaints about it.
> What terminals are not catered for here?

 At this point, it's hard to imagine anyone writing a new terminal
emulator with incompatible color escape sequences.

 Anyone on really rare hardware terminals or crufty software that is
different for some reason can always disable colors for software that
hard-codes sequences.  They're nice but non-essential.

 The only scenario I'm coming up with where it would be really good to
use a library to find what escape sequences to use would be
future-proofing against the day when somebody extends the ANSI color
escape sequences to support more colors, or 3D for stereoscopic-vision
terminals.  And even then, only if for some reason they choose to
extend the escape sequences in a non-backwards-compat way.

 I'd hold off on spending time on this until some new idea
for color escape codes comes along.  I think there's enough inertia
behind the current ANSI escape sequences that terminal emulators will
need to support current-style escape sequences for decades after the
appearance of a new way of doing things.  I think decades is long
enough for util-linux to make this proposed change and have it
percolate into long-term-support releases before any terminal
emulators think they can get away with dropping support for
current-style color escape sequences.

 Anyway, that's my 2 cents.  I'd maybe change my mind if anyone has a
real-life case where the hardcoded ANSI codes don't work for them, on
a terminal they actually want to use, but terminfo would.  (I'm not
talking about ancient cruft you can find that's incompat, but rather
stuff people actually do use regularly.)

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

  reply	other threads:[~2015-03-01 15:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12  9:45 tty[1-6]: colors a negative accessibility/usability trend Felix Miata
2015-02-12 11:04 ` Pádraig Brady
2015-02-13  3:21   ` Dale R. Worley
2015-02-13  9:21     ` Karel Zak
2015-02-13 10:33       ` Sami Kerola
2015-02-13 11:25         ` Karel Zak
2015-02-15 11:12           ` Mike Frysinger
2015-02-16  9:10             ` Karel Zak
2015-02-16  9:35               ` Mike Frysinger
2015-02-16  9:47                 ` Karel Zak
2015-02-16 10:32                   ` Samuel Thibault
2015-02-16 13:49                     ` Karel Zak
2015-02-27 13:48                     ` Karel Zak
2015-03-01 13:32                       ` Pádraig Brady
2015-03-01 15:14                         ` Peter Cordes [this message]
2015-03-02  8:59                         ` Karel Zak
2015-03-02  9:31                           ` Samuel Thibault
2015-03-02 11:03                             ` Karel Zak
2015-02-15 17:38         ` Dale R. Worley
2015-02-16  9:18           ` Karel Zak
2015-02-13 17:55       ` Bruce Dubbs
2015-02-12 13:21 ` Karel Zak
2015-02-12 13:56   ` Samuel Thibault
2015-02-12 14:38     ` Karel Zak
2015-02-12 15:25     ` Edward d'Auvergne

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=20150301151440.GV3933@cordes.ca \
    --to=peter@cordes.ca \
    --cc=P@draigBrady.com \
    --cc=kerolasa@gmail.com \
    --cc=kzak@redhat.com \
    --cc=mrmazda@earthlink.net \
    --cc=samuel.thibault@ens-lyon.org \
    --cc=util-linux@vger.kernel.org \
    --cc=worley@alum.mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.