[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notice: intent to diganose use of 'Df'
From: |
G. Branden Robinson |
Subject: |
Re: notice: intent to diganose use of 'Df' |
Date: |
Thu, 29 Jun 2023 06:39:48 -0500 |
Hi John,
At 2023-06-29T19:45:18+1000, John Gardner wrote:
> Support for 'f' may disappear in the next release, producing an error
> > diagnostic regarding an unrecognized command.
> >
>
> This doesn't sit right with me. Removing an obsolete feature to
> encourage adoption of a newer one runs counter to Groff's normative
> handling of legacy features—a manual that's formatted correctly and
> consistently for the past 20 years will logically be expected to
> continue doing so. I'm aware that \D'f…' isn't supported by AT&T Troff
> (although it *is* supported by SQTroff), but that strikes me as a weak
> argument to justify the feature's removal.
>
> Assuming there's no practical benefit to removing \D'f…' outright, I
> instead suggest documenting it as an explicitly obsolete feature,
> similar to how the *"Legacy command(s)"* section in groff_out(5)
> documents the old "jump right *dd*u and print char *c**"* method for
> outputting text. The section makes it crystal clear to readers that
> this syntax is supported for backwards compatibility only, and
> suggests modern alternatives they should be using instead. \D'f…'
> should do likewise, IMO.
I should have titled the thread "further deprecate" or "diagnose on use
of". So I am doing so now.
If you review the attached diff, it does in fact retain support for the
feature, it's simply noisy about it.
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index e86644da5..2067f0a19 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -3140,6 +3140,7 @@ sub do_D
}
elsif ($Dcmd eq 'f')
{
+ Warn("'f' drawing command is obsolete; use 'Fg' instead");
my $mcmd=substr($par,0,1);
$par=substr($par,1);
diff --git a/src/libs/libdriver/input.cpp b/src/libs/libdriver/input.cpp
index 821b526bd..78f73379a 100644
--- a/src/libs/libdriver/input.cpp
+++ b/src/libs/libdriver/input.cpp
@@ -1361,6 +1361,7 @@ parse_D_command()
}
case 'f': // Df: set fill gray; obsoleted by DFg
{
+ warning("'f' drawing command is obsolete; use 'Fg' instead");
IntArg arg = get_integer_arg();
if ((arg >= 0) && (arg <= 1000)) {
// convert arg and treat it like DFg
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index e797e2200..cc0b59f38 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -8754,6 +8754,9 @@ static node *read_draw_node()
error("even number of arguments needed for spline");
break;
case 'f':
+ error("'f' drawing command is obsolete;"
+ " use 'Fg' drawing command, 'M' escape sequence,"
+ " or 'fcolor' request instead");
if (npoints != 1 || !no_last_v) {
error("one argument needed for gray shade");
npoints = 1;
Do you also object to the emission of these diagnostic messages?
The actual feature removal is something I don't contemplate for groff
1.24, may never happen (though I think we should not pretend to
foreclose the option from future groff developers, which means warning
users strongly now/soon), and would prefer to discuss your philosophy of
feature retention in a separate thread.
Regards,
Branden
signature.asc
Description: PGP signature