groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] colorized man pages


From: Peter Schaffter
Subject: Re: [Groff] colorized man pages
Date: Thu, 25 Aug 2016 12:39:44 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Aug 25, 2016, Tadziu Hoffmann wrote:
> > Yes, but who is still working with a text terminal?

I, for one.  Excluding composing music, 90% of everything I do at
the computer is done in 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.

Precisely.  When you combine the unparalleled power with the
knowledge to use it, the shell provides a better interface for many
tasks than a GUI.  "Better" meaning more efficient, more complete,
more flexible, more powerful.  And faster.  Way, way faster.

> > 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,

This is true.  Some activities are better handled by a GUI, others
are better handled at the command line.  For example, if I want to
delete selected files from a directory and the filenames can't be
globbed, it's easier to select and delete them by clicking in a
GUI.  OTOH, if the filenames can be globbed, it's more efficient to
do it from the command line.

The issue, ultimately, isn't whether CLI is superior to GUI, it's
that using the command line requires study and practice.  I'll go
out on a limb here and say that anyone who dismisses CLI as obsolete
is speaking from ignorance of the shell.

> > 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.

Am I the only one who finds that text at a terminal emulator with a
well-chosen monspaced font and good contrast is much, much easier
to read than a graphical representation of the same text (e.g. in a
browser or pdf viewer)?

> 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.

You're not refering to the mom documentation, are you? :)

Levity aside, I wrote the mom documentation in html because
groff_man(7) wasn't the right tool for the job.  I also paid
attention to how the html rendered in a terminal browser, for the
legibility reason I mentioned above.

Manpages are the ideal documentation format for programs controlled by
options at the command line, but are deeply ill-suited to longer,
more complex documentation.  The mom macros do have a manpage, but I
did not write it and I don't maintain it because, frankly, it isn't
helpful and no one seems to use it.  Helpful manpages do exist for
groff itself and for pdfmom(1), both of which are invoked at the
command line with options.  So, while not a "complex, interactive GUI
application", the macroset displays the ideal arrangement you've
outlined: manpages for CLI invocation, and separate documentation
for the "program" itself.

-- 
Peter Schaffter
http://www.schaffter.ca



reply via email to

[Prev in Thread] Current Thread [Next in Thread]