Re: [groff] [patch] do not strip mdoc macros

[Bjarni Ingi Gislason]

On Sun, Mar 10, 2019 at 07:06:28PM +0100, Ingo Schwarze wrote:
> Hi,
> 
> Dave Kemper wrote on Fri, Mar 01, 2019 at 03:21:02AM -0600:
> > On 2/27/19, G. Branden Robinson <address@hidden> wrote:
> 
> >> Opinions on the utility of the stripper script among the groff
> >> development team are mixed.
> 
> > Historically true, but the last couple of times the topic came up on
> > this list, no one stepped forward to defend stripping. See threads
> > starting at:
> > 
> >  - http://lists.gnu.org/archive/html/groff/2017-11/msg00104.html
> >  - http://lists.gnu.org/archive/html/groff/2018-03/msg00048.html
> > (which later strays from stripping in general to the implementation
> > details of a -mom fix)
> >  - http://lists.gnu.org/archive/html/groff/2018-03/msg00054.html
> > 
> > Does anyone want to argue in favor of continuing to strip the macro
> > packages?
> 
> It doesn't seem so...
> 

  It is objectively correct to strip the macro files of bytes that are
meaningless for the program "groff" (processing the commands by the
processor).
  Processing optimization is the elimination of any extra
(unnecessary) activity.

  How was assembly-line work optimized, or any other handwork in
factories?

  It is objectively correct to _not_ strip the macro files of bytes
that have a meaning for humans.

  So provide both versions.

> To simplify the discussion and do one thing at a time, here is a
> patch to stop stripping the mdoc macros.  Here are a few reasons
> why stripping is a bad idea for mdoc in particular:
> 
>  1. The mdoc macros are already relatively complicated,
>     consisting of multiple files and having their own subdir,
>     so adding more complexity on top of that by stripping
>     causes worse confusion than for other macros.
> 

    Causes confusion for humans, not for the program "groff" (except if
the code it not clear enough, or can cause confusion how to interpret
it).

>  2. Development of mdoc is slightly more active than, say,
>     -ms, -me, or -mm, and easy access to the unstripped code
>     is most useful when changes are being considered.
> 

    Yes, the unstripped (original file) should (must) be provided for the
humans, to read the code and its documentation.

    All tmac-files should be provided in both versions (unstripped
(original) and stripped).  User should (must) have a choice, although
the stripped versions should be used in regular use.  The unstripped
versions are for debugging and reading the code by humans.

-- 
Bjarni I. Gislason