Bug #62691 also seeks to make certain global state information environment-specific.

Thanks, Dave.

Solution-wise, here's a sketch of what I'm thinking.

1. Get rid of this static `reverse` flag in `env.cpp:distribute_space()`.

2. Instead, we want a new concept called something like "(current) adjustment parity", which is a property of the `environment` class.

3. The parity only needs to take two values, so it could remain an int, become a bool (which I'd prefer to an int), or become a two-valued enum.  One value would mean "distribute space starting from the left," and the other, "from the right".  In terms of the current code, from the left means you don't reverse the node list before and after distributing space, and from the right means you do.

4. An environment seems like the right data structure in which to house this datum because (A) it preserves continuity with the existing code and (B) it doesn't feel quite like the right fit for a diversion given our current documentation.  I'm further updating the summary of this bug to reflect that, though you may want to change it again if I'm not persuasive.  Consider: a diversion gobbles up the current partially collected line if there is one.  I'm thinking that it is therefore hard to judge whether the adjustment parity should be reset upon simply entering a diversion or not, since there might not be a partially collected line, if a break happened accidentally or otherwise just before the diversion was created.

5. A common idiom in AT&T troff, according to our Texinfo manual, was to switch environments immediately upon starting a diversion.  ("Switching to another (empty) environment (with the ev request) avoids the inclusion of the current partially collected line" node "Diversions".)

6. With all that bookkeeping in place, we can turn to the question of whether it makes sense to expose this property of an environment via the language in any way.  Adding it to the output of .pev seems hard to object to.

7. The more interesting question is whether to make the property user-modifiable.  I cannot imagine what would break if we did (maybe someone else can).  Rather than adding a request, I'd be inclined to expose a writable register for it.  Even though I regard the current practice (inherited from AT&T) of having troff-internal writable registers reside in the (global) name space without any sort of prefix with chagrin, changing that would be groff 2.0-level disruptive and is orthogonal to the current issue.  So I'd call the new register, say, "adjparity", and map assigned values the way we do *roff Booleans: Non-positive -> zero ("left"); positive -> one ("right").

8. As something of a frivolous bonus, since the adjustment parity has to be initialized as part of every environment, including the default one created automatically at startup, we could assign it a default value such that we initially adjust lines from the same direction Heirloom Doctools troff, and presumably all other AT&T-descended troffs.

Thoughts?

comment #1:

> But if that turns out to be wrong, I can open a new bug report
> for this manifestation.

I believe it has in fact turned out to be wrong, based on the code snippet Branden posted in bug #60665; accordingly, I've opened the new bug #60673 to track the quasi-related comment #1 problem.

$ groff -Tascii tty_example | head -14
For  TTY  output  with  full justification, grotty pads by adding
extra spaces alternating every line left-to-right  and  right-to-
left,  as  can be seen in this paragraph.  This helps to preserve
overall uniform grayness  throughout  the  text,  as  well  as  a
monospaced typeface allows.

But  diversions  requiring  adjustment apparently are included in
this  sequence  even  if they are not output right away (or ever,
for  that  matter).   This  means that a number of closely spaced
diversion  definitions  can  break  grotty's balancing algorithm,
putting  all  the  space  on  the same end of every line, as this
paragraph demonstrates.


$ cat tty_example
.nh
For TTY output with full justification, grotty pads by
adding extra spaces alternating every line left-to-right and
right-to-left, as can be seen in this paragraph.  This helps
to preserve overall uniform grayness throughout the text,
as well as a monospaced typeface allows.
.
.sp
.
But diversions requiring adjustment apparently are included in
this sequence even if they are not output right away (or ever,
.box dummy
This is some dummy text, enough to kick in the adjustment algorithm.
.box
for that matter).  This means that a number of closely spaced
.box dummy
This is some dummy text, enough to kick in the adjustment algorithm.
.box
diversion definitions can break grotty's balancing algorithm,
.box dummy
This is some dummy text, enough to kick in the adjustment algorithm.
.box
putting all the space on the same end of every line, as this
.box dummy
This is some dummy text, enough to kick in the adjustment algorithm.
.box
paragraph demonstrates.
$ groff -Tascii --version
GNU groff version 1.22.4.74-b400-dirty
Copyright (C) 2018 Free Software Foundation, Inc.
GNU groff comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of groff and its subprograms
under the terms of the GNU General Public License.
For more information about these matters, see the file
named COPYING.

called subprograms:

GNU grotty (groff) version 1.22.4.74-b400-dirty
GNU troff (groff) version 1.22.4.74-b400-dirty