On Wed, Feb 18, 2009 at 08:10:24AM +0100, Werner LEMBERG wrote: > Colin Watson wrote: > >Werner LEMBERG wrote: > >> [...] Convert the error message of .mso into a new warning category > >> which is enabled by default. Then you can easily disable it with > >> using a -W ... command line option. > > > > Hmm. I thought warning bits were in rather scarcer supply than > > request names; there are only three bits left at the moment, since > > it's a signed int, and I can't think of many other plausible places > > where you'd want the same category of warning as this. > > The last category, WARN_COLOR, has been added in 2001... This is > really no problem. Additionally, we currently have 19 warning > categories, and groff assumes that integers are 32 bit at least, so we > have actually 12 bits left.
Whoops, I confused octal with hexadecimal! Of course you're absolutely right. > > And, as you say, it is unfortunate from a backward compatibility > > point of view: man-db would probably end up having to detect the > > version of groff, since otherwise it would cause a warning on every > > single manual page unless the macro file is present (which will be > > the clear majority of pages). > > Then use the `.warn' request directly. If the `range' warning > (value 64) isn't set, `.warn' doesn't emit a warning if you supply a > value larger than WARN_TOTAL. I hadn't thought of .warn; thanks. In that case simply feeding in this preamble will work: .warn (\n[.warn] - (\n[.warn] / 64 % 2 * 64)) .warn (\n[.warn] + 1048576 - (\n[.warn] / 1048576 % 2 * 1048576)) > > Nevertheless, here's the necessary patch if you're sure: > > Thanks! I'll incorporate this in case there aren't strong objections. Given the above trick, this will work for me. Thanks, -- Colin Watson [[email protected]]
