Well I clearly failed said exercise, because my brain has no idea what the
hell it just read.
On Thu, 4 Apr 2024 at 08:48, Bjarni Ingi Gislason <bjarn...@simnet.is>
wrote:
> Give more people a chance to see, think and learn.
>
> The following is from the groff bug report #65474
>
> spurious "warning: unbalanced 'el' request" when formatting zic(8)
> from TZBD project
>
> What I forgot to write in the contribution was:
>
> Another language has polluted the code, as written.
>
> -.-.
> From comment # 3:
>
> This is neither a spurious nor a "false positive" but a
> legitimate remark about the code.
>
> I don't see a balance (like a two arm weight balance) with
> separate left and right loads.
>
> The warning is falsely interpreted (translated) by humans.
>
> The translator is not happy about how the instructions are
> written, they are not informative enough for an unambiguous
> processing.
>
> The writer's duty is to supply the translator with all
> necessary information to make its work efficient, correct and
> without any doubt.
>
> When humans look at the code, they add (get, have) information
> that the translator does not have.
>
> .ie \n(.g groff
> .el .ie t troff
> .el neither groff nor troff
>
> So simply adding the needed information for a unique
> interpretation is
>
> .ie \n(.g groff
> .el \{ .ie t troff
> .el neither groff nor troff \}
>
> which is not visible enough and not an enough structured style,
> changing to
>
> .ie \n(.g groff
> .el \{\
> . ie t troff
> . el neither groff nor troff
> .\}
>
> makes the "balance" visible at first glance.
>
> In this case one can look at "groff" as being a (minimal) "code
> and style checker".
>
> The false interpretation (translation) of warnings by humans is
> thus more common than one might suspect.
>
> Changing the code in "groff" to eliminate such a warning is
> simply censorship and sabotage.
>
> N.B.
>
> The showed warning "el" (code = 16) should be elevated to
> a default status.
>
> -.-.
>
> N.B.
>
> Another exercise is bug #42675 (2014-07-03)
>
>
>
