Re: [Groff] colorized man pages

[John Gardner]

Speaking as a terminal addict, I can confirm that I feel infinitely more
productive where single-key shortcuts are burned into my brain.

It's true: it takes practice to get used to, but once you've grokked with a
shell, you'll understand what true flexibility really is.

> 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)?

Nope, same here! I even augmented <https://github.com/Alhadis/Menloco> my
preferred typeface so its box-drawing characters joined together
seamlessly. :-)

It looks ace: http://imgur.com/a/DFOQz

On 26 August 2016 at 03:15, Russell Hyer <address@hidden> wrote:

> That's lucky, still being able to define your environment, I've been
> fighting my translation agency to help me actually submit a
> translation for a customer (they have a new-fangled GUI that doesn't
> work) that a 2-second upload button would solve in under 2-seconds :)
>
> But, yeah, for most real things, I'm a paper/terminal person. When
> things get really messy, that's when you need abstractions like
> functions, or objects, or other kinds of abstractions, but being
> forced to use someone else's abstraction (ie: one without access to a
> programming interface/language) is like not having an interface but
> whatever the word is for an interface with swear words attached :)
>
> Happy hacking,
>
> Russell
>
> On 25 August 2016 at 17:39, Peter Schaffter <address@hidden> wrote:
> > 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
> >
>
>