[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #18, bug #67992 (group groff):

I may get back to the philosophical stuff in comment #17 later, but for now I
wanted to note that:

Prefixing the device extension escape sequences with `\c` restores _groff_
1.23.0-ish behavior for all three macro packages.


$ printf '\\X"pdf: xrev"\n' | ~/groff-1.23.0/bin/groff -me -a


$ printf '\\X"pdf: xrev"\n' | ~/groff-1.23.0/bin/groff -mm -a

 - 1 - 
  

  
  
  
$ printf '\\X"pdf: xrev"\n' | ~/groff-1.23.0/bin/groff -ms -a


  
$ printf '\\c\\X"pdf: xrev"\n' | ./build/test-groff -me -a


$ printf '\\c\\X"pdf: xrev"\n' | ./build/test-groff -mm -a

 - 1 - 
  

  
  
  
$ printf '\\c\\X"pdf: xrev"\n' | ./build/test-groff -ms -a





Playing around with the input stream pointer did not make anything better, and
always much worse.

So I think I'm on the right track with my other hypothesis of device extension
commands needing to "start the document" if they occur before the document has
started.

If so, bug #65977 would be implicated.  Maybe I didn't completely fix it.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[Dave]

Follow-up Comment #17, bug #67992 (group groff):

[comment #11 comment #11:]
> neither of you articulate a limiting principle to what you
> characterize as "regression"

I don't think these various debates come down to a difference in the
definition of regression, but a difference of opinion in what is expected
behavior.  The roff field is a fertile one for such debates because the
language is so inexactly specified.

All Eric Allman had to do was write "A -me macro must be invoked before any
text appears" in his -me manual, and most of this debate goes away.  But he
didn't, so we're left to wonder: is it because it never occurred to him that
one might put output in a document _without_ first calling a macro?  Or is it
because that's simply not a requirement?  And we're left to trawl historical
texts and try to infer intent.  (This situation is nothing like reading
ancient religious texts.  Never in the history of ever have two people read
the same passage of a sacred text and come to vastly different conclusions
about what it means.)

So even if we all agree on a definition of regression like "When code that
used to work correctly now fails," there's still a world of grey in that word
"correctly."  We have an origin document (CSTR #54) that left a lot of
language aspects under- and unspecified, and an origin implementation that
cannot be said to be bug-free because no nontrivial software is bug-free.
Then we have a re-implementation with its own bugs, and its documentation with
its own ambiguities, that has now enjoyed a longer history than its
progenitor.  That confluence of inertia and slop prevents drawing neat lines
around "correct behavior," especially the more we wander into weird corner
cases.  I think each of these cases has to be considered on its individual
merits, which is horribly unsatisfying to your precision-seeking mind but is
clearly what God intended, as any plain reading of 1 Corinthians 11:19 will
tell you.

> hence my Plan 9 troff SIGFPE example,

I don't remember this, and couldn't find it in the list archives or in
Savannah--and that signal name is a pretty unique search term.

> Where documentation doesn't support his rigidity,
> he points to the implementation as a specification from which
> no deviation should be permitted; see bug #63544.

I probably lean more toward your side in that particular debate, but I also
sympathize with the view that when dealing with an absent or ambiguous
specification, an implementation that's remained consistent for decades might
be as close as you can get to a specification.

> Slapping the label "regression" on anything is not an argument.

Certainly not.  Obviously I can speak for neither Ingo nor Deri, but I don't
use the label as an argument, but as a factor to consider when assigning
priority to a(n alleged) bug.  It can also perhaps bolster the argument that
something _is_ a bug: "The program does this, and it should do that" is a
question that can be argued; "The program does this, and it should--and used
to--do that" gives more weight to the "should" part, though I agree it doesn't
make it automatic, else nothing about the program could ever change, and we
could all put down our keyboards and take up macramé.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Update of bug #67992 (group groff):

  Status:   Postponed => Confirmed
 Assigned to:None => gbranden
 Planned Release:None => 1.24.0

___

Follow-up Comment #16:

Un-postponing.  I need to fix the jank for _me_(7)'s benefit (see comment
#10), and I'd bet a crisp Jefferson-faced two dollar bill that whatever fix
the formatter needs to achieve that will fix the jank for _ms_ and _mm_ as
well.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #15, bug #67992 (group groff):

At 2026-02-01T10:48:49-0500, Deri James wrote:
> Follow-up Comment #14, bug #67992 (group groff):
> On Sunday, 1 February 2026 04:51:11 GMT G. Branden Robinson wrote:
>> Follow-up Comment #11, bug #67992 (group groff):
>>
> [...]
>>
>> Deri, for example, is rigid in his expectations of GNU _troff_'s
>> output format ("grout", as I term it.)  Where documentation doesn't
>> support his rigidity, he points to the implementation as a
>> specification from which no deviation should be permitted; see bug
>> #63544.
>>
> I provided a one line perler which achieved your desire for more
> readable grout (the "wish" of that bug):-
>
> perl -pe 's/(.)(.*)/$1\n$2/ if m/^w/; s/^(.)(\S.*)/$1 $2/mg' zfile
>
> I hope you are still using it.

I am not.  I do not see the value in filtering GNU troff's output to
pre-digest it into a form gropdf requires but which no other groff
output drivers do.

See:
https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/devices/grotty/tests/h-option-works.sh?h=1.24.0.rc2

(Whoops--stale comment in there.  I'll fix that.)

> I am expecting changes to grout and groff fonts (v2) when you complete
> full utf8 throughput.

I don't plan "full UTF-8 throughput".

I don't plan to use UTF-8 for GNU troff's internal storage of
formattable character objects (rather, I plan to use `char32_t`) and
moreover, even I did use UTF-8 internally, the input would still have to
undergo some form of Unicode normalization; probably Normalization Form
D given the program's orientation toward typesetting and support for
glyph composition by overstriking.  groff_char(7) has cautioned the
reader to prepare for normalization of input for several years.

Expecting an identity mapping between UTF-8 code points on input and the
glyph encoding on output is unrealistic.

> [derij@pip build (master)]$ printf ".ft JPM\nハローワールド" | groff
> -Z
> -k
> x T ps
> x res 72000 1 1
> x init
> p1
> x font 41 JPM
> f41
> s1
> md
> DFd
> V12000
> H72000
> tハローワールド
> n12000 0

Not planned.

> Much nicer. And groff fonts (v2) could become:-
>
> ハ 1000654 uni30CF -- 30CF
>
> instead of:-
>
> u30CF 1000654 uni30CF -- 30CF

Not planned.

Both of these file formats, fortunately, admit comments, and GNU troff
could emit UTF-8 in them.

So I could see this instead:

x T ps
x res 72000 1 1
x init
p 1
x font 41 JPM
f 41
s 1
m d
D F d
V 12000
H 72000
C u30CF # ハ
h 1
C u30ED # ロ
h 1
C u30FC # ー
h 1
C u30EF # ワ
h 1
C u30FC # ー
h 1
C u30EB # ル
h 1
C u30C8_3099 # ド (or maybe ト ゙゛, but maybe not)
n 12000 0

And similarly, in a font description file...

u30CF   1000654 uni30CF -- ハ

> But of course that requires both of us agreeing we are working towards
> the same ends, instead of just changing grout and expecting me to
> accomodate the change after the event.

I've spoken elsewhere recently about how best to sequence changes.

See comment #8 to bug #67939, or
.

I'd expect to commit a patch (personally, most likely) to gropdf before
altering GNU troff's output, adding `\s+` to regexes where necessary to
achieve compatibility with the interpreter in groff's "libdriver".



___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[Deri James]

Follow-up Comment #14, bug #67992 (group groff):

On Sunday, 1 February 2026 04:51:11 GMT G. Branden Robinson wrote:
> Follow-up Comment #11, bug #67992 (group groff):
> 
[...]
> 
> Deri, for example, is rigid in his expectations of GNU _troff_'s output
> format ("grout", as I term it.)  Where documentation doesn't support his
> rigidity, he points to the implementation as a specification from which
> no deviation should be permitted; see bug #63544.
> 
I provided a one line perler which achieved your desire for more readable
grout (the "wish" of that bug):-

perl -pe 's/(.)(.*)/$1\n$2/ if m/^w/; s/^(.)(\S.*)/$1 $2/mg' zfile

I hope you are still using it.

I am expecting changes to grout and groff fonts (v2) when you complete full
utf8 throughput. For example:-

[derij@pip build (master)]$ printf ".ft JPM\nハローワールド" | groff -Z
-k
x T ps
x res 72000 1 1
x init
p1
x font 41 JPM
f41
s1
md
DFd
V12000
H72000
Cu30CF
h1
Cu30ED
h1
Cu30FC
h1
Cu30EF
h1
Cu30FC
h1
Cu30EB
h1
Cu30C8_3099
h1
n12000 0

Could become:-

[derij@pip build (master)]$ printf ".ft JPM\nハローワールド" | groff -Z
-k
x T ps
x res 72000 1 1
x init
p1
x font 41 JPM
f41
s1
md
DFd
V12000
H72000
tハローワールド
n12000 0

Much nicer. And groff fonts (v2) could become:-

ハ   1000654 uni30CF -- 30CF

instead of:-

u30CF   1000654 uni30CF -- 30CF

But of course that requires both of us agreeing we are working towards the
same ends, instead of just changing grout and expecting me to accomodate the
change after the event.

Cheers

Deri



___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #13, bug #67992 (group groff):

*Turing


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #12, bug #67992 (group groff):

[comment #11 comment #11:]
> Every[1] Turing-complete language with a specification has
> "implementation-dependent behavior".

Likely an overstatement on my part.

Some extremely small ("toy") programming languages are capable of arbitrary
computation but might be able to claim absence of implementation-dependent
behavior.  Perhaps this is true of Brainfuck, or a one-instruction computer
(such as one where the only instruction is DJNZ), or a zero-instruction
computer (a "move machine" or "transport-triggered" machine).

For elucidation and one's (dubious) edification, see S. Dolan's paper about
the x86 architecture, "[https://drwho.virtadpt.net/files/mov.pdf mov is
Turning-complete]".

My point was more that languages that are intended to be "practical", and with
which I am familiar, always seem to have escape hatches for
implementation-defined behavior.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #11, bug #67992 (group groff):

At 2026-01-31T18:04:04-0500, Dave wrote:
> Follow-up Comment #7, bug #67992 (group groff):
>
> [comment #2 comment #2:]
>> It's not a regression to issue a diagnostic when encountering an
>> ill-formed input document when no diagnostic was issued before.
>
> Mostly agreed.  However, if the new diagnostic points to something
> with no apparent relation to the ill-formedness, it's also not a
> _pro_gression.

Yes, but that doesn't say much.  Every[1] Turing-complete language with
a specification has "implementation-dependent behavior".

>> I need you and Ingo Schwarze to understand that "behavior
>> change"  is not synonymous with "regression".
>
> This sounds like a straw-man reduction of both our positions.

I wish it were.  I _want_ it to be!  Meaning: I want the straw man to be
a distortion I don't have to deal with.  The problem I face is that
neither of you articulate a limiting principle to what you characterize
as "regression"--hence my Plan 9 troff SIGFPE example, which I'm willing
to bet is on the other side of this unarticulated boundary--and you guys
wouldn't necessarily champion the same one.  If you did articulate such
a limiting principle, then I think I'd have an easier time convincing
the community of groff developers that there's room within *roff's
_loose_ specification to admit variant behaviors.

Deri, for example, is rigid in his expectations of GNU _troff_'s output
format ("grout", as I term it.)  Where documentation doesn't support his
rigidity, he points to the implementation as a specification from which
no deviation should be permitted; see bug #63544.

If a system designer does not write down the Law, he finds the users
putting up golden calves right and left...

> The obvious conclusion of a "behavior change = regression" postulate
> is that software should never change, and neither of us has espoused
> that view.

I think Ingo comes close.

See .

"This repository contains work in progress on the textproc/groff

The reason why such a repository is needed is twofold:

Recent GNU roff development suffers from massive amounts of
regressions and gratuitious changes that make providing a stable
groff port very hard.

The gnulib, automake, and autoconf build system used by groff
degrades portability of the software to the point that getting it to
build at all is quite hard and tracking down issues becomes outright
hellish."

..._and yet_...here are some examples of "gratuitous changes" that Ingo
was content to adopt, the existence of which the foregoing screed would
leave one stridently doubting.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.201&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.198&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.197&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.194&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.189&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mdoc_term.c?rev=1.284&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mdoc_validate.c?rev=1.309&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/tbl_term.c?rev=1.68&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/tbl_term.c?rev=1.66&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/st.c?rev=1.14&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/chars.c?rev=1.51&

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #10, bug #67992 (group groff):

At 2026-01-31T18:51:26-0500, Dave wrote:
> Follow-up Comment #8, bug #67992 (group groff):
>
> Ha, the question of whether the -me package requires a macro before
> output turns out to be academic.  For a fun surprise, try this in
> groffs old and new:
>
> printf '.sz 14\n\\X"pdf: xrev"' | groff -me -a

It does seem to work fine.  And even with Allman's own macros (modified
only to use `tm` to report their provenance and `cp 1` to turn on
compatibility mode).


$ groff --version | head -n 1
GNU groff version 1.23.0
$ printf '.sz 14\n\\X"pdf: xrev"' | groff -M HISTORY/ME/4.4BSD -me -a
This is Allman "me", 8.1 (Berkeley) 06/05/93



...and if I use my working copy, which _fixes_ bug #67990, another
assertion trips.


$ printf '.sz 14\n\\X"pdf: xrev"' | ./build/test-groff -M HISTORY/ME/4.4BSD
-me -a
This is Allman "me", 8.1 (Berkeley) 06/05/93
troff: ../src/roff/troff/input.cpp:2887: bool
token::is_usable_as_delimiter(bool, delimiter_context): Assertion `context !=
DELIMITER_GROFF_EXPRESSION' failed.
/home/branden/src/GIT/groff/build/groff: error: troff: Aborted (core dumped)


Sigh.  I guess I have more freeze-busting work to do after all.



___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #9, bug #67992 (group groff):

At 2026-01-31T17:25:28-0500, Dave wrote:
> Follow-up Comment #6, bug #67992 (group groff):
>
> [comment #0 original submission:]
>> ...but _me_ doesn't seem to.
>>
>> However there is *copious* evidence that this was always the
>> package's intention.
>
> Sorry if I'm failing to understand your evidence.  Those look to me
> like evidence that that is how the package is often _used_.  What in
> those do you see showing _intent_ (of the package author, presumably)?

All of them; none of these are examples of throwaway documents, of the
sort a user might produce when "playing", or exploring the formatter.
Those written by Allman were necessarily composed by a domain expert,
but any shipping with a BSD release, we can reasonably presume, were
intended a meet a professional standard of quality on par with _ms_
documents from the Bell Labs CSRC (and others from the Berkeley CSRG
itself) adumbrating the Unix system.

> This is not to say that the undocumented requirement you've postulated
> is either incorrect or unreasonable.  Certainly, in my own use I've
> never found need to jump right into text without setting up headers
> and/or calling a content macro (paragraphing, keep, etc.).

Or setting up a cover page, I reckon, which seems to be the common case
among documents for BSD "SMM" (System Manager's Manual) and "USD"
(User-Supplied Documentation).

I further presume the latter category is where we'd see the most "flex"
in approaches to me(7) document composition, but I'm not finding an
example that overturns my inference about an (unstated) requirement.

> But my understanding of -ms and -mm (gleaned from osmosis rather than
> any study on my part) is that certain requests initialize aspects of
> the package, whereas -me is as initialized as it ever gets merely by
> being included.

You may be right.

> This suggests that, while it's very common to call some -me macro
> before outputting text, it's not required.

And on this point, too.



___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[Dave]

Follow-up Comment #8, bug #67992 (group groff):

Ha, the question of whether the -me package requires a macro before output
turns out to be academic.  For a fun surprise, try this in groffs old and
new:

printf '.sz 14\n\\X"pdf: xrev"' | groff -me -a




___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[Dave]

Follow-up Comment #7, bug #67992 (group groff):

[comment #2 comment #2:]
> It's not a regression to issue a diagnostic when encountering an
> ill-formed input document when no diagnostic was issued before.

Mostly agreed.  However, if the new diagnostic points to something with no
apparent relation to the ill-formedness, it's also not a _pro_gression.

> I need you and Ingo Schwarze to understand that "behavior
> change"  is not synonymous with "regression".

This sounds like a straw-man reduction of both our positions.  The obvious
conclusion of a "behavior change = regression" postulate is that software
should never change, and neither of us has espoused that view.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[Dave]

Follow-up Comment #6, bug #67992 (group groff):

[comment #0 original submission:]
> ...but _me_ doesn't seem to.
> 
> However there is *copious* evidence that this was always the
> package's intention.

Sorry if I'm failing to understand your evidence.  Those look to me like
evidence that that is how the package is often _used_.  What in those do you
see showing _intent_ (of the package author, presumably)?

This is not to say that the undocumented requirement you've postulated is
either incorrect or unreasonable.  Certainly, in my own use I've never found
need to jump right into text without setting up headers and/or calling a
content macro (paragraphing, keep, etc.).

But my understanding of -ms and -mm (gleaned from osmosis rather than any
study on my part) is that certain requests initialize aspects of the package,
whereas -me is as initialized as it ever gets merely by being included.  This
suggests that, while it's very common to call some -me macro before outputting
text, it's not required.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #5, bug #67992 (group groff):

Here's an example of a "regression" under the Schwarze-Kemper (-Hyrum?)
definition.

https://github.com/9fans/plan9port/pull/738

Not the bug--the fix!

A user could have had a (reasonable?!) expectation that they could rely on the
formatter to abort if they attempted a modulus-by-zero operation in a numeric
expression.

Now, wretchedly, Plan 9 from User Space troff merely issues a warning, just as
its feeble relative, division by zero, long has. 

Regression, regression--oh, depression!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #4, bug #67992 (group groff):

Here's a link to the Seventh Edition Unix _ms_(7) man page.

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man7/ms.7


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #3, bug #67992 (group groff):


[comment #2 comment #2:]

> * The `\X` escape sequence didn't, either, and Lesk didn't mention escape
> sequences as universally unstimulating of punishment, though he probably
> should have.

...if that's what he meant to imply, I should qualify.



___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

Follow-up Comment #2, bug #67992 (group groff):


[comment #1 comment #1:]
> [comment #0 original submission:]
>> $ printf '\\X"pdf: xrev"' | ./build/test-groff -me -a
> 
> This one, at least, is a regression: 

No.

> this pipeline produces no diagnostics on any groff from 1.19.2 to 1.23.0.
> They all produce the desired "simple, pleasant empty document."

It's not a regression to issue a diagnostic when encountering an ill-formed
input document when no diagnostic was issued before.

Failure to diagnose invalid input does not render that input valid.

I need you and Ingo Schwarze to understand that "behavior change"  is not
synonymous with "regression".

Wikipedia:

"Regression testing (rarely, non-regression testing[1]) is re-running
functional and non-functional tests to ensure that previously developed and
tested software still performs as expected after a change."

You had no valid expectation that:

> $ printf '\\X"pdf: xrev"' | ./build/test-groff -me -a

would produce a "simple, pleasant empty document."

Quoting (presumably) Lesk in _ms_(7):


Many
.I nroff
and
.I troff
requests are unsafe in conjunction with
this package, however these requests may be used with
impunity after the first .PP:


I'll grant that the foregoing language is more casual than it could have
been.

* groff's `device` request didn't exist yet (and wouldn't for about another
decade).
* The `\X` escape sequence didn't, either, and Lesk didn't mention escape
sequences as universally unstimulating of punishment, though he probably
should have.
* An `LP` macro call would work just as well as `PP` to obtain the "impunity"
one might seek.

While the _me_ package isn't the same as _ms_, it covers many of the same
bases and appears to be similarly designed.  For evidence, see the "copious"
examples in comment #0.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[Dave]

Follow-up Comment #1, bug #67992 (group groff):

[comment #0 original submission:]
> $ printf '\\X"pdf: xrev"' | ./build/test-groff -me -a

This one, at least, is a regression: this pipeline produces no diagnostics on
any groff from 1.19.2 to 1.23.0.  They all produce the desired "simple,
pleasant empty document."


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #67992] [me, mm, ms] janky output seen when user breaks initialization rules with device extension command

[G. Branden Robinson]

URL:
  

 Summary: [me,mm,ms] janky output seen when user breaks
initialization rules with device extension command
   Group: GNU roff
   Submitter: gbranden
   Submitted: Sat 31 Jan 2026 03:49:21 AM UTC
Category: Macro package - others/general
Severity: 3 - Normal
  Item Group: Rendering/Cosmetics
  Status: Postponed
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Unlocked
 Planned Release: None


___

Follow-up Comments:


---
Date: Sat 31 Jan 2026 03:49:21 AM UTC By: G. Branden Robinson 
Spawned off of bug #67990.

The _ms_, _me_, and _mm_ macro packages all expect the user to call one of
their macros before attempting to format any text.

This fact is documented prominently for _ms_...


groff_ms(7):
Document structure
 The ms macro package expects a certain amount of structure: a well‐
 formed document contains at least one paragraphing or heading macro
 call.  To compose a simple document from scratch, begin it by
 calling LP or PP.  ...

$ eqn -Tutf8 ./build/doc/ms.ms | nroff -rLL=80n -pt -ms | sed -n '43,46p'
1.1.  Basic information

Prepare  an ms document with your preferred text editor.  Call an ms macro
early
in the document to initialize the package.  A macro is a formatting
instruction
...

"Typing Documents on the Unix System: Using the -ms macros with Troff
and Nroff", M.E. Lesk, 13 November 1978:

Warning: You can't just begin a document with a line of text.  Some
-ms command must precede any text input.


...and _mm_...


groff_mm(7):
 Call an mm macro at the beginning of a document to initialize the
 package.  A simple mm document might use only P for paragraphing.


...but _me_ doesn't seem to.

However there is *copious* evidence that this was always the package's
intention.  See:

https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/doc/as/asdocs0.me
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/doc/courier/courier.tbl.me
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/doc/sccs.me
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/src/usr.lib/sendmail/doc/intro.me
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/share/doc/ps1/07.ipctut/tutor.me
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/share/doc/usd/22.memacros/intro.me

...and others.

Here's how to produce some jank:


$ printf '\\X"pdf: xrev"' | ./build/test-groff -ms -a
$ printf '\\X"pdf: xrev"' | ./build/test-groff -me -a
$ printf '\\X"pdf: xrev"' | ./build/test-groff -mm -a
$ echo '.device pdf: xrev' | ./build/test-groff -ms -a
$ echo '.device pdf: xrev' | ./build/test-groff -me -a
$ echo '.device pdf: xrev' | ./build/test-groff -mm -a


In every case we get a worrisome diagnostic:


troff::1: error: spurious end trap token detected!


...sometimes others, and a never simple, pleasant empty document as we might
expect from this input.

Not a gate for _groff_ 1.24.0.  Born postponed.








___

Reply to this item at:

  

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


signature.asc
Description: PGP signature