Re: [groff] hyphenation issues

[Ralph Corderoy]

Hi Branden,

> Getting back on topic...

Square!

> My debugging instincts tell me to always report the value of an
> argument being rejected.  For one thing, the user could have passed
> .hy a register value (possibly with arithmetic manipulation), and if
> we screw up the validity checks it's easier to see which cases are
> incorrect.

Definitely.  Another thing to look out for is the same error message
being generated at multiple points as different criteria fail.  I'm left
with an error and the source and don't know which one printed.

> +  // The _usable_ maximum is 52; see hyphenate_request() below.
> +  HYPHEN_MAX = 63,

Not based on the `hy.trf.out' you provide.

    $ mhstore -part 1.4 -outfile - |
    > egrep -o "'-?[0-9]+'" | tr -d \' |
    > toseq | tr ' ' - | fmt
    -1 3 5 7 9 11 13 15 17 19-23 25 27-31 33 35 37 39-47 49 51-64

I'd just say `Not all values are legal; see hyphenate_request()' as
otherwise it's repeating information: the function's logic, and its
relative position.

> -      warning(WARN_SYNTAX, "contradicting hyphenation flags, ignored");
> +      warning(WARN_SYNTAX, "contradictory flags in hyphenation request "
> +     "value '%1'; ignored", n);

It seems to have grown wordy.  Unix convention, I don't know about
groff's, would be more like

    clashing hyphenation flags ignored: %1

I don't think quotes are needed for what's known to be an integer.  It
pushes the variable to the end, and allows that whole message to be
preceded by another that in turn treats it as the variable, e.g. `groff
build failed: %s'.

> +      warning(WARN_RANGE, "hyphenation request value '%1' out of range "
> +     "(must be in %2..%3); ignored", n, HYPHEN_NONE, HYPHEN_MAX);

This is easier to phrase with two tests.

    negative hyphenation flags ignored: %1
    unknown hyphenation flags, maximum %2, ignored: %1

But it's just a suggestion.  You're the one doing the work!

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy