Re: [Groff] colorized man pages

[Russell Hyer]

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
>