Update of bug #67219 (group groff):
Status: None => Need Info
Assigned to: None => barx
Summary: New warning text sometimes less specific about
reason for unadjustability => [troff] new warning text sometimes less specific
about reason for unadjustability
_______________________________________________________
Follow-up Comment #1:
[comment #0 original submission:]
> Groff's warning text used to distinguish between being unable to adjust a
> line because it was unbreakable and being unable to adjust a line for some
> other reason.
> $ cat breakwarn
> .ll 1i
> aaaaaaaaaaaaaaaaa
> aaaaaaaa aaaaaaaa
> $ groff -z breakwarn
> troff:breakwarn:2: warning [p 1, 0.0i]: cannot break line
> troff:breakwarn:3: warning [p 1, 0.2i]: cannot adjust line
> $ groff-latest -z breakwarn
> troff:breakwarn:2: warning [page 1, 0.0i]: cannot adjust line; overset by
> 0.0483333i
> troff:breakwarn:3: warning [page 1, 0.2i]: cannot adjust line; underset by
> 0.506667i
> Quantifying the issue is certainly more informative. And it's possible the
> wording change is intentional: it's true that the line both cannot be broken
> and cannot be adjusted.
That was in fact my intention. As you've noted elsewhere, sometimes an
overset line is overset on purpose (when filling is disabled, for example).
And sometimes even when adjustment is enabled and a line is short, adjustment
is foregone (as at the end of a paragraph).
> If so, this bug can be rejected.
>
> However, there are various reasons a line might not be adjustable, and being
> unbreakable is only one of them. So the former wording, "cannot break," was
> more specific.
But is it more _helpful_?
> This is very likely a consequence of
> [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=82192662b commit
> 82192662b]. The new code appears to choose between the words "adjust" and
> "break" based on a condition that doesn't take the full situation into
> account.
I tried to think through all scenarios. GNU _troff_ now uses the phrase
"cannot break" only when adjustment is disabled (for confusing historical
reasons, this is expressed in the case as `adjust_mode` equaling
`ADJUST_BOTH`).
If the formatter was trying to perform adjustment on the line but was foiled
in the effort, it says "cannot adjust". This is not "less specific" in my
view, but it might be "differently specific" compared to past diagnostics.
Does this make sense? Is there a scenario I'm overlooking?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67219>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
