Re: two further apparent regressions in 1.23 in s.tmac

[G. Branden Robinson]

[CCing groff@gnu and directing Reply-To there]

Hi Joerg,

At 2024-10-16T13:30:23+0200, joerg van den hoff wrote:
> I ran into this problem several months ago but did never suspect it
> would be related to a preceding update to 1.23 (which happened as part
> of general package update run so I did not even take note until
> recently that groff on my machine is actually now at 1.23) so this
> report comes a bit late.

Did you review the NEWS file or the release announcement to see if this
issue was covered there?

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0
https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00001.html

(Only one need be consulted; the same list of changes features in both.)

> I tried to reduce the problem to next-to-minimal but I do not know
> what the root issue is, so.... please try this code:
> 
> .\"snip
> .LP
> .DS I
> foo
> bar
> baz
> foo
> bar
> baz
> foo
> bar
> baz
> .rt

What is this `rt` doing without a preceding `mk`?

> .sp |2.5i
>       after .sp |2.5i (TAB indented(!)
> .DE
> .sp 2i
> after end of DS/DE and additional .sp 2i
> .\"snip

Would you please follow-up with a complete document as a reproducer?  It
can still be "minimal" insofar as it reproduces the problem(s).

> there are two problems.
> 
> 1. major one:
> attached 2 pdfs (A4 page size) formatted with groff1.22.4 and groff
> 1.23.0, respectively. obviously the latter one is broken (the
> interaction between absolute and relative .sp positioning seems to be
> the issue, it seems the additional '.sp 2i' is simply ignored or
> replace by .sp 1v in groff1.23).

The release notes/NEWS file may be helpful here.

> 2. maybe a bug, maybe a feature -- no idea:
> if you remove the first line (.LP) in the above snippet, it still
> formats just fine with 1.22 but fails in 1.23 with
> 
> s.tmac:stdin:15: error: must be in top-level environment, not 'nf', when 
> first page is started

It appears to me that this was a bug I introduced.[1]  I bisected it
down to commit 1887bbe68c in November 2021.

The fix is simple, and causes no automated test failures (but I'll be
writing a new one); here's what I have in my working copy.

$ git diff
diff --git a/tmac/s.tmac b/tmac/s.tmac
index dd682e5b1..adf18e0c7 100644
--- a/tmac/s.tmac
+++ b/tmac/s.tmac
@@ -1071,6 +1071,7 @@ .de ds*end!2
 .el .@error-recover mismatched .DE
 ..
 .de DS
+.br
 .if '\\n(.z'ds*div' .@error-recover cannot begin display within display
 .nr ds*badarg 0
 .di ds*div

So you might try that.

> a wild guess: it has to do with virtual page break/transition onto
> page 1.  but if so, I thought, that .DS is among the macros triggering
> that transition? why is the document invalid without the .LP??

Some macro packages initialize fully when they're loaded--when their
macro files are read.  Others defer some initialization tasks, taking
effect only when one of their macros is called, implicitly completing
initialization.  me(7) takes the former approach, and ms(7) the latter.
mm(7) is something of a hybrid, much initialization is deferred, but
register setting that affect the page layout (like `L`, `W`, and `O`)
have to be specified on the command line, or prior to the package being
"sourced" (if it wasn't loaded via the "-mm" option).

ms.ms says:

---snip---
1.1.  Basic information

ms documents are plain text files; prepare them with your preferred text
editor.   If  you’re  in a hurry to start, know that ms needs one of its
macros called at the beginning of a document so that it can  initialize.
A  macro  is a formatting instruction to ms.  Put a macro call on a line
by itself.  Use .PP if you want your paragraph’s first line indented, or
.LP if you don’t.
---end snip---

The set of macros that can perform this function is nowhere specified;
there have been difficulties getting this to work when starting an ms
document with an eqn equation straight out of the gate, for example.
(Though reviewing the code now, I have an idea of how we might overcome
that.)

It might be an interesting exercise to prepare a set of tests for each
of the ms macros document by Lesk 1976, and another set for those added
by Tuthill 1983.

Such an exercise might force the resolution of some open questions in
what passes for ms's specification.  For instance, is a document
consisting only of `TC` valid?  Is a table of contents meaningful when
there is no "content"?

> for the time being I have decided to revert my installation to 1.22.4.
> currently there are -- for my taste, at least -- too many regressions
> in 1.23 (see recent threads regarding .XA and .IX, e.g.).

Okay.  Should you encounter a defect in groff 1.22.4, be aware that an
update, by any vendor/distributor, to address it is unlikely.

> but I of course do sincerely hope that things will stabilize/improve
> soon so that 1.23 (or its s.tmac, specifically) is better suited for
> use in "production".

No point release to groff 1.23 is anticipated.  The next release is
expected to be 1.24.  To get a preview of what user-visible changes to
ms are anticipated in the next release, you can consult the NEWS file in
our Git repository.

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=ddbbe95e27fd3f2aa633d719c95e921a178fd25a#n475

(That points to HEAD as of right now, for the sake of a stable link.)

> I do which the maintainer(s) much success, naturally.

Thanks.

Regards,
Branden

[1] The lack of `br` meant that a document that started with a `DS`
    macro call did not "sweep" the drawing position past vertical
    position 0, which springs a trap that calls a macro called
    `cov*first-page-init`,[2] which does much essential initialization,
    including (indirectly) setup of the `PS` register storing the type
    size.  Consequently, the text of the display would render at 1
    point(!) instead of the formatter's default of 10.  The diagnostic
    about the `nf` environment might warn the user that the formatting
    is likely to go awry, but we can do better than that by simply
    restoring the break.

[2] 
https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/s.tmac?id=198346d187de9e340bbf9d4f80c2dc4d42f5f74e#n203

signature.asc
Description: PGP signature