> 1. While explicit braces for blocks indeed reduce the risk to
> introduce future errors by adding requests, adding redundant
> braces makes the code longer, more deeply indented, and sometimes
> harder to read, [...]
And, perhaps most important: It makes execution slower! Contrary to
TeX, groff doesn't have an internal representation form of macros.
This means that a macro gets interpreted exactly as written. For
example, if a macro that contains a line to call a request has 100
spaces after the leading dot, the 100 spaces are interpreted again and
again if you execute the macro. Consequently, `make install' strips
(almost) all spaces from the mdoc macro files before they get
installed. Similarly, the `doc-' prefix gets removed to make the
commands shorter.
The same is true for \{ ... \}, of course. If they can be safely
omitted, it makes the code faster – maybe such micro-optimizations are
no longer important today, but comparing a call of mdoc with and
without spaces removed makes a difference of more than 50% in speed on
my old laptop, IIRC. [Note that you have to slightly massage the mdoc
macros if you want to call them without stripped spaces.]
Bjarni, have you ever looked at `compressed' JavaScript code? For
example, the very frequently used `jquery-1.11.0.min.js' file looks
like this:
/*! jQuery v1.11.0 | (c) 2005, 2014 jQuery Foundation, Inc. |
jquery.org/license */
!function(a,b){ ... [32327 characters follow on this line] ...
}}function S(a,b,c){ ... [31990 characters follow on this line] ...
},a,b,arguments.length>1)}, ...[31915 characters follow on this line] ...
This is *completely* incomprehensible, but it speeds up loading the
file since it is only a third of the original size (which you can also
download from `jquery.com', BTW). So it is not only groff that uses
similar techniques to save some processing or loading time.
> To be constructive, here is a patch to fix the warning in question.
Applied to git, thanks.
Werner
