[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] colorized man pages
From: |
John Gardner |
Subject: |
Re: [Groff] colorized man pages |
Date: |
Sun, 21 Aug 2016 00:07:42 +1000 |
Adding colours to manual-pages is a solution to a problem that doesn't
exist. It's purely aesthetic.
As both a graphic designer *and* a programmer, I can say with confidence
that both disciplines exist to solve problems. If colour is what helps a
reader navigate a manpage's content, then the content in question is
probably a victim of a more mundane issue of poor structuring, verbosity,
and/or misuse of formatting.
On 20 August 2016 at 23:57, Steffen Nurpmeso <address@hidden> wrote:
> Clarke Echols <address@hidden> wrote:
> |Just because you can doesn't mean you should.
>
> To me the problem is that i can't right now, even though i want.
>
> |With a world gone crazy over apps for this, apps for that,
> |and apps to manage apps (I'm guessing because I've never
> |owned a cell phone -- much less a smart phone) I see no
>
> I don't know about that. I have an «emergency» mobile phone. It
> is the second mobile phone i own – you know the story of the
> extreme cruelty and environmental terror surrounding Coltan, and
> that the Chinese even paid over world market price to calm down
> the situation some ten years ago, _if_ i recall correctly. So,
> no. I would still use my first, even older, Nokia, but the power
> plug is dead, and no one seems to be able to repair it. Though it
> would very well be worth it. Anyway i am now the owner of a used
> Samsung, which, i admit, has a camera and, once unfolded,
> a monitor. I couldn't wait for the renaissance of the plain old
> good stuff, unfortunately.
>
> Granted that we possibly have seen a step forward regarding user
> interfaces due to all this. Then again, i think it is just a step
> heading towards the vision that materialized in the Newton.
> And that in turn is most likely (not only!) a real-life
> translation of the brain transplant and do-by-thinking, which is
> much, much older, i think.
>
> |need for it.
>
> I can't agree. Though i am pretty conservative regarding this
> myself, most of the time – my vim, with which i stay practically
> all the time, uses DarkRed (brown) for comments and
> reverse,bold,red for warning messages.
>
> I see the need because this software, not only the macros, don't
> allow people to realize what they want. And they seem to do so,
> because whenever i start vim without my own config file, myself
> starts laughing. And it was like that already when i started
> using vim, around Y2K. And then colors offer the option to «break
> out» of a situation: say you work twelve hours in a two-colour
> editor session, it is, in my gut feeling, helpful to switch to
> a different environment with a completely different visualization.
> E.g., whereas i am completely fine with
>
> colour mono sum-dotmark ft=bold,ft=reverse dot
> colour mono sum-header ft=bold dot
> colour mono sum-thread ft=bold dot
> colour mono view-header ft=bold from,subject
> colour mono view-msginfo ft=reverse,ft=underline ''
> colour mono view-partinfo ft=bold,ft=underline ''
> colour mono mle-position ft=bold ''
> colour mono mle-prompt ft=bold ''
>
> on a monochrome display (the reverse is even too much), i also
> like switching to
>
> colour iso sum-dotmark ft=reverse,fg=blue dot
> colour iso sum-header fg=blue dot
> colour iso sum-thread fg=blue dot
> colour iso sum-thread fg=magenta ''
> colour iso view-from_ fg=brown ''
> colour iso view-header ft=bold,fg=red from,subject
> colour iso view-header fg=red ''
> colour iso view-msginfo fg=green ''
> colour iso view-partinfo fg=brown ''
> colour iso mle-position ft=bold ''
> colour iso mle-prompt fg=red ''
>
> on a normal eight-colour display and really like, for quite some
> weeks now, periodically switching over to
>
> colour 256 sum-dotmark ft=bold,fg=13 dot
> colour 256 sum-header fg=19 older
> colour 256 sum-header fg=16,bg=219 dot
> colour 256 sum-header fg=17 ''
> colour 256 sum-thread ft=bold,fg=164,bg=219 dot
> colour 256 sum-thread fg=172 ''
> colour 256 view-from_ fg=142 ''
> colour 256 view-header ft=bold,fg=red from,subject
> colour 256 view-header fg=124 to,cc
> colour 256 view-header fg=203 reply-to,mail-followup-to,user-agent
> colour 256 view-header fg=88 ''
> colour 256 view-msginfo fg=green ''
> colour 256 view-partinfo fg=brown ''
> colour 256 mle-position fg=202 ''
> colour 256 mle-prompt fg=red ''
>
> on a 256-colour display, even though that is, well, colourful.
>
> |But one factor nobody's mentioned is the fact that some
> |users are color blind, and the wrong combination of
> |colors can make a page very difficult to read, and that
> |is NOT what's needed.
>
> I wouldn't enable this by default, then. That is easy to do if
> the software is a good one and the mechanism as such is backed by
> good code.
>
> I.e., the software should be capable to automatically detect
> whether colours are applicable, choose the right terminal sequences
> to realize what is desired, etc. I don't really honour the latter
> because i always have presupposed ISO 6429, i.e., ANSI
> attribution, which originates in the 1970s.
>
> |I suggest leaving well enough alone. Black text on a
> |white background has always worked well. Strong
> |contrast (NEVER grey on white like so many "modern"
> |graphic designers seem to think is so pretty, even if
> |it makes text much harder to read) is still the best
> |way to put text on a screen or on paper either for
> |that matter.
> |
> |My engineering manager from decades ago said the best
> |designs are always the simplest, and have the least
> |need for adjustments.
>
> I do appreciate clean and reduced designs myself. But it depends,
> and other people may have other desires. If the software can
> scale to the needs of those people, too, and does so automatically
> and correctly, then it is a personal matter chosen freely, not
> something imposed by outer restrictions. And that is what
> i desire, even though i know that most people don't survive
> freedom mentally. But the software has to move.
>
> --steffen
>
>
Re: [Groff] colorized man pages, Ingo Schwarze, 2016/08/19