bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61450] Add warning for extraneous arguments to requests


From: Dave
Subject: [bug #61450] Add warning for extraneous arguments to requests
Date: Fri, 3 Jun 2022 21:12:53 -0400 (EDT)

Follow-up Comment #3, bug #61450 (project groff):

[comment #0 original submission:]
> Conversation causing this bug report occurred on the groff
> mailing list in 2021-11 under the subject ‘Two trivial questions’.

For easy clicking, the relevant thread starts at
http://lists.gnu.org/r/groff/2021-11/msg00043.html

Another aspect has occurred to me since that thread: I wonder if the present
behavior is by design, much like how unrecognized macros are silently (by
default) ignored.

The advantage of such leniency is that a document designed for a more-featured
roff can be processed by a less-featured one, with perhaps some loss of
fidelity but otherwise intact.  For example, a document prepared for groff
might use the .tkf request to adjust letterspacing, but could still be
processed with a historical roff that lacks this request; the desired
letterspacing would of course not be reflected, but the document would largely
render fine otherwise.

Similarly, groff's .ss request takes two parameters, but this is an extension
to CSTR#54 troff, where it took only one.  But thanks to the lack of
parameter-count checking, a two-parameter .ss will be handled without
complaint by a CSTR#54-only troff, with only slight changes in sentence
spacing to show for it.

So if, down the road, some future groff 1.28 expands the .po request to take
two additional optional parameters, documents that use this expanded
functionality can still run without error on groff 1.23, just missing whatever
bells and whistles 1.28 added.

This isn't an argument against such warnings being activable with the proper
switch (as undefined-macro warnings currently are), but it's possibly an
argument against their being on by default, and probably an argument against
one day upgrading the condition to an error.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]