Follow-up Comment #1, bug #66700 (group groff): At 2025-01-23T02:31:18-0500, Dave wrote: > Date: Thu 23 Jan 2025 01:31:12 AM CST By: Dave <barx> > The -me .2c macro is throwing a warning that it never (i.e., back to at least > 1.19.2) did before. > > $ echo '.2c 3m' | groff -me -ww -z > $ echo '.2c 3m' | groff-latest -me -ww -z > troff:<standard input>:1: warning: expected end of line or an auto-increment > argument in register definition request; got character 'n' > > This warning is new since a mid-August groff build.
Yes. That's from this:
commit 2bd122bf56ecb688a2612fade02643c9db27feef
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
AuthorDate: Sat Aug 17 10:48:36 2024 -0500
Commit: G. Branden Robinson <g.branden.robin...@gmail.com>
CommitDate: Mon Aug 19 12:29:49 2024 -0500
[troff]: Fix Savannah #64240 (warn of nr garbage).
* src/roff/troff/reg.cpp (define_register): Warn when garbage
encountered in numeric expression argument to `nr` request.
Fixes <https://savannah.gnu.org/bugs/?64240>.
> The file tmac/e.tmac has only had two commits in that time, neither of
> them touching the 2c macro, which was last touched in 2022 by
> [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=4796dc773
> commit 4796dc773].
>
> So a change to core troff rather than to e.tmac may be the root cause.
A change to the formatter implemented the diagnostic message. So either
I wrote the syntax validation incorrectly, or a bug in me(7) has been
exposed.
> Nonetheless, since at the moment I know how to provoke this warning
> only through a -me macro, I'm filing it as a -me bug.
No worries.
Let's get a backtrace and have a look at the package.
$ echo '.2c 3m' | ~/groff-HEAD/bin/groff -b -me -ww -z
troff: backtrace:
'/home/branden/groff-HEAD/share/groff/1.23.0/tmac/e.tmac':992: macro '2c'
troff: backtrace: file '<standard input>':1
troff:<standard input>:1: warning: expected end of line or an auto-increment
argument in register definition request; got character 'n'
$ sed -n '992p' tmac/e.tmac
. nr $s \\$1n \" param 1: column separation
Well, yup, if argument 1 is `3m`, this becomes `3mn`, which is
invalid.
Interestingly, I _did_ touch that line in August 2022.
...but only to respond to a report from you of misleading indentation.
Before that...
It's me again in December 2021.
Before that...
It's Werner in February 2013.
Before that...
It's imported by James Clark in or before June 1991.
All have the trailing `n`.
Cocking a snook at 4.4BSD-Lite2...
Yup, it goes all the way back to Allman.
This may have been idiomatic, or nearly so, in AT&T troff. It would be
a way to wangle a "default" scaling unit when the user didn't specify
one, and harmless if they did.
But I assume GNU troff's `;` operator exists for a good reason, maybe
even beyond ignoring scaling units already in a numeric expression,
which Allman's technique can't do.
So the right thing to do is treat this as a bug in the macro package and
fix it.
Thanks, Dave!
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66700>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
