Follow-up Comment #4, bug#65322 (group groff):
I find it significant that "protecting" a leading ellipsis dot with a dummy
character does nothing to keep the new reproducer from coring on any version
of _groff_ that I'm testing (see earlier comments).
$ diff -u EXPERIMENTS/heading.mom{.crashy,}
--- EXPERIMENTS/heading.mom.crashy 2024-02-17 12:27:57.427826358 -0600
+++ EXPERIMENTS/heading.mom 2024-02-17 12:28:35.767637242 -0600
@@ -3,7 +3,7 @@
.START
.HEADING 1 NAMED one "Attack\|.\|.\|."
This is a heading.
-.HEADING 2 NAMED two ".\|.\|.\|Sustain\|.\|.\|."
+.HEADING 2 NAMED two "\&.\|.\|.\|Sustain\|.\|.\|."
Let's refer back to the first heading (the one titled
.PDF_LINK one SUFFIX ). +
.HEADING 2 NAMED three "\&.\|.\|.\|Decay\|.\|.\|."
Find out if something deeper within _mom_ is prepending a dummy character
anyway.
If so: it seems more likely that dummy character semantics are not being
handled correctly when diverted, or when a diversion is "reread" (tellingly,
all of these crashes only happen _after the document input has been read_, and
the formatter is cleaning up).
If not: the dummy character may be a red herring and something more
challenging/interesting may be going wrong.
The aspect of this that has the formatter panicking because the input level
isn't what it expected is, to me, strongly reminiscent of a bug elsewhere from
ages ago (though not all that old when James Clark wrote _groff_). Maybe this
is our own SCKMUD bug.
https://www.trs-80.com/wordpress/tips/easter-eggs/
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65322>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
