Re: [Groff] colorized man pages

[Tadziu Hoffmann]

> Yes, but who is still working with a text terminal?

For one thing, many people in my surroundings are.
(Not a hardware terminal like the VT100, of course,
but a terminal emulator.)

Do we do this because we're dinosaurs, too set in our ways
to adapt to a new workflow?  I prefer to think it's because
the shell has proven itself to be a tool of unparalleled
power when dealing with unexpected situations.  (GUIs are
fine if input and output are within well-defined parameters.)
There simply exists no GUI yet for this type of job that has
the same versatility as the shell.

[Bachelor students usually arrive with only a rudimentary
knowledge of the GUI and the ability to start programs and
browse directories with the file manager, and they have
to be brought up to speed on using the command line. --
"Here's a tarball of the program you will be using.  Adapt
the configuration to your machine and compile it (and also
fix all the stuff the compiler might complain about).
And if there's no libfftw for your system, download and
compile it yourself.  You'll probably need the BLAS as
well."  -- There are many things that can go wrong in
such a situation.  How do others go about in dealing
with such problems?]


> In 1980, it wouldn't have been unusual, as you know, for a
> VT-100 to be the user's single interface to the computer.
> Any UI feature -- font style & variations, menus, multiple
> applications, etc. -- had to be rendered on that one
> screen.  It's no wonder it became terrifically complex. They
> developed programmable fonts, 132-column displays, alternate
> screens. It's a testament to human ingenuity.

> Today most of those features have been subsumed by the GUI.
> Different applications have different windows, different
> fonts, graphics, all resizable. We have a potpourri of UI
> gadgetry barely imagined in those days.  Yet the emulator
> remains as muscular and complex as ever,

Exactly.  Things that are better handled by a GUI have been
taken over by GUI programs, but practically all terminals
nowadays essentially stick to the same established feature
set.  Sure, terminal emulator programs have added additional
functionality, but those are usually GUI features (multiple
tabs, screen splitting, searching in the output, etc.),
not terminal capabilities.

> just in case someone happens across an RS-232 cable and a
> line driver.

It's more than accessing old devices connected by a serial
line.  Think of the sysadmin out in the field alerted by the
datacenter to a problem with a server.  I imagine many of
them will appreciate the ability to log on via ssh from their
mobile phone to kill an errant process or restart a service.
What are the alternatives?

I often see people tending to equate "old" with "outmoded",
something to be rid of at the next possible opportunity.
But that's not how things work.  If something is old but
still in use, then it usually means it's at least as good
as the alternatives (if any exist at all).  It is still
being used because it gets the job done.

[And regarding the actual topic of this mailing list:
it's also why I still prefer using an "old" text formatter
such as groff over a "modern" office writing application.
A programmable text-based system like groff or TeX allows
for easy scriptability, it makes it much easier to achieve
consistency and repeatability, and allows version comparison
not only of the document text but also of the formatting
settings.]

Of course there's a certain momentum involved.  No manufacturer
is likely to single-handedly push (against user expectations)
for a radically different interface, unless that interface
is very obviously better for at least some of the customers
(or the manufacturer has a quasi-monopoly).

But cars still have steering wheels after a hundred years of
automobile history, and keyboards still have a Qwerty layout
(even soft-keyboards on mobile devices, where there is
practically zero hardware cost of changing the layout).

Why is this so?  It seems that the steering wheel has
established itself as a successful interface.  It's not only
used in mass-produced consumer cars but also in specialized
vehicles (such as Formula-1 racing cars) where compatibility
would be of minor importance.  The keyboard layout, on
the other hand, is probably driven mostly by momentum.
The benefits of a layout different from Qwerty are apparently
not significant enough to offset the costs of retraining
(meaning that the layout is "good enough"), and without a
sufficient user base there's little financial incentive for
manufacturing different keyboards.  (But much experimentation
is going on these days with new text-entry methods for mobile
phones and other miniature touchscreens.)  Professional writers
claim that the Dvorak layout reduces fatigue, but it's mostly
used by the comparatively small fraction of users that make
very extensive use of the keyboard.


> Sadly, for all the advances, documentation has hardly budged,
> if indeed it's advanced at all.  Even though a good deal of
> it is maintained in typeset form, the output predominately is
> confined to the application with the poorest text rendering
> capability: the VT-100 emulator.

That's not entirely true.  It's usually command-line tools
that are documented by manpages, and that may be seen as a
natural extension of their modus operandi (i.e., accessible
from the shell).  Many complex interactive GUI applications
have no manpage at all (or only a short one listing the
available command-line switches) -- but there may be a
builtin help system or even entire websites with hundreds
of html pages describing the program's operation.


> Because of poverty owing to neglect -- that is, necessity
> being the mother of invention -- the author of the article
> I linked to decided he'd like color in his man pages.
> Where did he turn?  A style sheet in the groff framework,
> perhaps?  Any kind of improvement to the semantic-display
> connection?  No, he reached about as far down as possible,
> and tweaked the control sequences emitted to the emulator.
> Because he could.  Because, in a way, he *had* to, insofar
> as that strange bit of arcana gave him the most leverage.

> So, yes, he's still working with a text terminal, after
> a fashion.  But the programmability of that text terminal
> is an accident of history, its feature set long since made
> obsolete -- not useless, but out-moded -- by graphical
> displays and GUIs.  That he reached for that particular
> tool is a measure of how far we have come, and how far
> we have not.

Well said!

(Although I have to disagree about the word "obsolete",
which implies that better alternatives exist *and are
available for use*.  In this case, they were not.
Should they have been?  Because there's an urgent need
for them, or just because it's technically possible?
Does such a need actually exist?  Do other issues
have a higher priority?)