Re: device-dependent warnings

[G. Branden Robinson]

Hi Alex,

At 2023-05-07T22:42:05+0200, Alejandro Colomar wrote:
> $ make build-pre-tbl >/dev/null
> $ grep 'table wider' .tmp/man/man4/console_codes.4.eqn
> .  tm1 " table wider than line length minus indentation
> .  tm1 " table wider than line length minus indentation
> .  tm1 " table wider than line length minus indentation
> .  tm1 " table wider than line length minus indentation
> .  tm1 " table wider than line length minus indentation
> .  tm1 " table wider than line length minus indentation
> .  tm1 " table wider than line length minus indentation
> .  tm1 " table wider than line length minus indentation
> .  tm1 " table wider than line length minus indentation
> 
> BTW, tbl(1) doesn't accept any warnings flags.  Is this warning
> unconditional?

(Un)conditional on what?  Does it have a knob permitting it to be
disabled?  No.  Is it emitted if the line length (minus indentation) is
wide enough to house the table?  No.

> > It was only when the page was getting formatted that your document
> > discovered that there was a problem with the line length.
> 
> That's what I consider a device-dependent warning.  In HTML, there
> will probably be no limits to the right margin.

(No practical limit, no.)

...and therefore you should never get the warning.

> In PDF and PS, the margin will be at a point depending on the font
> size and paper size.  And in UTF8 and ASCII, it will depend on LL.

With the caveat that `LL` is a register specific to some macro packages,
yes.  But this is what you want.  You want these complaints if a table
is going to wrap ugly on your terminal or run off the edge of the paper.

> It's good to know that these warnings are independent of -ww, so that
> I can remove -ww from troff -Tps and still get these.

Yes, that's true.  Messages produced with `ab` and the `tm` family of
requests are never affected by the formatter's `-E` or `-w` options; the
formatter cannot know what the document or package package is using
those requests for.

> Is there any warning from troff(1) (or any of the programs; not the
> doc itself) that depend on the output like this one?
> 
> Probably the following one one?
> 
> troff:man2/s390_sthyi.2:124: warning [p 2, 1.8i]: cannot adjust line
> 
> Probably the ones you call "output warnings".  Then it might be
> interesting to have an "output" warning category?

Yes, this is totally a formatter warning.  It's so special and breaking
of the libgroff diagnostic scheme that GNU troff has its own bespoke
replacement diagnostic functions to accommodate this warning format.
(I've tried in the past to refactor out the duplicated parts--it didn't
go well.)

Our warnings aren't obviously structured in the way you desire.  (I'm
not sure our warnings are structured in a way _anybody_ desires.)

However, there are only a four instances of "output warnings".  They are
all in env.cpp.  Quoting them will tell you which category they belong
to.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?h=1.23.0.rc4

src/roff/troff/env.cpp:      output_warning(WARN_BREAK, "cannot break line");
src/roff/troff/env.cpp:      output_warning(WARN_BREAK, "spreading %1m per 
space", Ems);
src/roff/troff/env.cpp: output_warning(WARN_BREAK, "cannot adjust line");
src/roff/troff/env.cpp:      output_warning(WARN_BREAK, "line has non-positive 
width %1m",

And as it happens, the WARN_BREAK category at present has no other
users, so you can take "-Wbreak" as synonymous with your desired
"-Woutput" if you like.

...for groff 1.23.0.  I don't promise to keep this the same in the
future.  Since nobody loves the arrangement of our warning categories, I
can't pledge stability if someone swoops in with a brilliant redesign.

[INT_MAX]
> Heh, next thing I'll try is a document that long.  ;-)

Once upon a time we measured that sort of thing in units of Encyclopedia
Britannicas.

Regards,
Branden

signature.asc
Description: PGP signature