[bug #57836] groff's adjustment algorithm is not environment-aware

[G. Branden Robinson]

Update of bug #57836 (project groff):

                  Status:                    None => Confirmed              
                 Summary: groff's adjustment algorithm is not diversion-aware
=> groff's adjustment algorithm is not environment-aware

    _______________________________________________________

Follow-up Comment #4:

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?



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57836>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/