bug-groff
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: joerg van den hoff
Subject: Re: two further apparent regressions in 1.23 in s.tmac
Date: Wed, 16 Oct 2024 22:01:02 +0200
User-agent: Mozilla Thunderbird 


On 16.10.24 19:38, G. Branden Robinson wrote:

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

Hi Joerg,


hi branden,



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


no. I considered this an obvious bug. I had no incentive to read the NEWS in 
this context.



(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`?
my understanding is that w/o mk the default is for rt to return to page top. at least that is what it empirically has done for the last 25 years I believe.
I now double-checked: the manual seems to indicate that w/o preceding mk, rt needs an argument (distance from page top). if it _really_ does the line would have to read `.rt 0'. but doing this does not change behaviour neither for 1.22 nor for 1.23: AFAICS the resulting pdfs are unaltered.
so apparently `.rt' w/o argument and preceding `mk' indeed is valid and _does_ (and might prospectively be guaranteed to) return to page top. if so, the groff manual regarding .rt/.mk should then mention this circumstance. 




.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).
I do not understand. the snippet I sent can be considered "the document". to make it compliant with currently documented behaviour replace `.rt' by `.rt 0'. 




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.
I do not understand. if you think the reported behaviour (the spacing issue) and the difference to 1.22 is _not_ a bug, I would appreciate a short hint where exactly _that_ is resolved in the 17 pages NEWS...
if it _is_ a bug (I would definitely think it is since, again, it breaks 25+ years of consistent groff behaviour), I will not find it in the NEWS. I have reported it in the hope that it is of interest to you. if not so much because you think it is not a bug, too bad. 




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.
thanks for looking into the issue. as said, I have reverted to 1.22 since I currently need to get some writing/formatting done and don't have much time for further 1.23-related delays/distractions right now. but I trust you have tested your fix yourself... 




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.
your decision. in my opinion the recently surfaced regression (the .XA issue) alone would deserve that since otherwise it will take substantially more time until it is officially fixed with releasing 1.24. 



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.


"wish" not "which", of course ...



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.
IIUC ("restoring the break"), this is the same sort of regression as with the .XA macro? deleting a "superfluous" line of code as a "code tidyup"?
if so, I would rate this as an indication that you should consider to increase your personal "confidence threshold" which you require to be reached before you proceed with such an action.
as said previously, the working hypothesis "original author might be smarter (at least not less smart) than me and had a reason to put that line in" could help. that's my approach with other peoples code at least when I adjust it to my needs. 

br/joerg



[2] 
https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/s.tmac?id=198346d187de9e340bbf9d4f80c2dc4d42f5f74e#n203
reply via email to
[Prev in Thread] Current Thread [Next in Thread]