Re: Disposition of groff 1.23.0.rc4 feedback issues

[G. Branden Robinson]

[self-follow-up]

I thought I should update the list below with more complete regression-
from-1.22.4 information.

At 2023-04-20T15:00:47-0500, G. Branden Robinson wrote:
> I've pushed a new personal staging branch, branden-2023-04-20 to
> groff's Git repository.  I've also pushed some documentation-only
> changes (meaning: changes to documentation files that affect only
> text, and don't require alteration of build scripts, Makefiles, etc.)
> to master since they are so low-risk.
> 
> I'm ready for the next tag; I don't know if you want to make another
> release candidate and/or adjust the risk threshold for it given the
> portability feedback from Bruno.
> 
> First the good news:
> 
> At 2023-04-15T23:05:18+0200, Bruno Haible wrote:
> > On the following systems the build completes fine and all the tests
> > pass:
> > 
> > * Linux
> >   Ubuntu 22.04
> >   Debian 9.1
> >   Debian 11.1
> >   CentOS 8-stream
> >   CentOS Stream 9
> >   OpenSUSE Leap 15.2
> >   Manjaro 17
> > * Hurd
> >   Debian GNU/Hurd
> 
> (I didn't see a report regarding macOS from Bruno, but it works for me
> on gcc104.fsffrance.org, which uses macOS 12.  Dave Kemper reports
> that Mac OS X 10.11.6 will exhibit the pdfpic.tmac problem discussed
> below.)
> 
> The bad news can be summarized as follows:
> 
> * Two distinct complaints about ms(7)
>   1. raw .bp requests sometimes not working (Savannah #64005)

This is a regression from groff 1.22.4.

>   2. raw .sp requests being nilpotent sometimes

This is arguably a regression from 1.22.4, and it, or at least a variety
of issues related to it at greater or lesser distances, has/have indeed
been argued at great length.  I would refer anyone who cares to discuss
it further to the test procedure I described at the end of my previous
mail on the subject.

https://lists.gnu.org/archive/html/groff/2023-04/msg00197.html

> * Portability issues
>   3. build failure when building out of tree and the prerequisites for
>  running mom(7)'s test script are unavailable

This was a latent groff 1.22.4 bug exposed by a commit of mine on 2
March.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=1ec02e805e2448bb17a27e3d9398cc83fd272743

I reckon this counts as a regression since a Makefile code path is being
followed now that wasn't in 1.22.4 when mom's test prerequisites were
not available.  On the other hand, if someone tried to produce a
distribution archive ("make dist") on such a system, I think that it
would have been erroneously missing mom's test script.[1]  I found this
alarming.

>   4. build failure in gxditview on AIX

I think it unlikely that this is a regression.  I predict that groff
1.22.4 would _also_ fail to build on an AIX system where Xaw linked with
Xpm and Xext.  (I suspect this has been the case for years.)  But I have
no access to an AIX system to be sure.

>   5. build failure with Sun C/C++ compiler due to use of GNU attribute
>  extension

I have no information about whether groff 1.22.4 ever built successfully
with the Sun C/C++ compiler, but the uses of the GCC __attribute__
extension were both post-1.22.4 additions to the groff source code, so
we can regard this as a regression since this usage would (it seems) be
a sufficient condition for causing that compiler to fail.

>   6. build failure on MinGW due to platform not supplying 

I'm not sure groff 1.22.4 built on MinGW without being patched, but the
requirement for the this header file is a post-1.22.4 change, so we can
call this a regression.

I covered the next two already in the quoted mail, but in short...

>   7. test failure: gdiffmk

Not a regression.

>   8. test failure: pdfpic.tmac

Not a regression; in fact, thanks to macOS 12 sed supporting a (GNU?)
extension to the POSIX specification for sed, this failure does not
occur where on older releases of Mac OS X, it would have.

Regards,
Branden

[1] Here's the relevant chunk of Automake script from 1.22.4.  It looks
quite different in 1.23.0.

if BUILD_EXAMPLES
momexampledir = $(exampledir)/mom
dist_momexample_DATA = $(MOMEXAMPLEFILES)
else
EXTRA_DIST += $(MOMEXAMPLEFILES)
endif

As I understand it, for the distribution archive's contents to be
stable, `EXTRA_DIST`'s value must not be dependent on build-time
parameters.


signature.asc
Description: PGP signature

user-defined characters, translation maps, and environment binding (was: Proposed: stop subjecting right-hand sides of `char` family requests)

[G. Branden Robinson]

Returning to this issue for a moment before I get back to 1.23 release
candidate concerns...

At 2023-04-01T19:45:19-0400, Douglas McIlroy wrote:
> The first use of .char that came to mind was
> .char \[ntilde] \o'n~'
> which would collide badly with the following ancient trick for
> unbreakable, unpaddable space. (Ignore the question of whether the
> tilde at hand is usable as a diacritical.)
> .tr ~
> a~b~c
> This, I guess, is typical of the motivation for the change.

It enables your "ntilde" use case quoted above, but the proposal was
prompted by another that I think I've mentioned but perhaps should pitch
more explicitly: to make `tr` translation maps part of the current
environment since that seems to comport better with their historical
applications.

Here's a concrete example, inspired by Kernighan & Cherry's "Typesetting
Mathematics -- User's Guide (Second Edition), where the problem you see
below swapped in minus signs for hyphens in the page headers.

[UTF-8 follows.]

$ cat ATTIC/tr-hyphen-to-minus.ms
.ds CH * % *\"
.LP
.\" I get tired of escaping special character escape sequences.
.tr *\(mu
length * width = area
.br
price * quantity = extended price
.br
workers * self-organization = union
.sp 60
skill * experience = craft

$ nroff -ms ATTIC/tr-hyphen-to-minus.ms| cat -s

length × width = area
price × quantity = extended price
workers × self‐organization = union

× 2 ×

skill × experience = craft

People seem to use `tr` either for global changes to a document, where
they invoke the request early and never revert it, or for local ones,
where they apply it temporarily and then back it out.

However, in the second case, they will in general have no idea if a trap
will spring before they're done.

In groff, you can turn vertical traps off, but you couldn't in AT&T
troff.  And doing so may have side effects you don't want, like
overrunning a column bottom or footnote area, or the page itself.

Applying `tr` only to the current environment would accommodate the
local use case better at the admitted expense of the global one.  This
would have to be NEWS-documented.  For the sake of historical documents,
we could restrict this behavior change to non-compatibility mode, since
those are the ones most likely to do what I think is the single most
common (albeit historical) global `tr` trick:

.tr ~\" nothing

...which turns the tilde into an unadjustable space.

In groff it is strictly better to use \~, which is not breakable but
_is_ adjustable, or \ if you truly do want an unadjustable space.
(And you can still perform these translations explicitly, as with

.tr ~\~

.)

> Suppose the change isn't made? What does .char do for you that .ds
> doesn't?

A user-defined character can:

1.  participate in kerning adjustments;
2.  be assigned "character flags" with `cflags`, as Dave noted--these
affect how the hyphenation process treats it;
3.  be designated as the hyphenation character, tab character, or leader
character
4.  be `chop`ped off the end of a string atomically;
5.  is counted as a single element of a string's contents by the
`length` request; and
6.  if I implement a `for` request as a string (and other object)
iterator as I plan to for groff-next, it will also be atomic in that
context.  

This list may not be exhaustive.

A user-defined character cannot be used as the control, no-break
control, or escape character.  (The last would have obvious circularity
problems.)

Today I learned that a control character in the ASCII sense, if
otherwise valid as groff input, _can_ be used as the *roff control,
no-break control, or escape character.

And now that I have learned it, I shall do my very best to forget it.  I
dare not even utter examples for fear of people like "alex ratchev" on
the GNU Bash mailing lists getting a hold of them, if he in fact has a
troff counterpart.  The horror...

To tie this back to `tr` and why these are related discussions, I
presently understand character definitions to be global--
supra-environmental.  I aim to sharpen the distinction between
translations and character definitions by retaining character
definitions' global application while subordinating translation maps to
the environment.

> Certainly nothing essential in the example above. However, it
> can avoid the ugliness of string invocations.

I think there's so much else going on with user-defined characters that
conceiving of them as a slightly slicker(?), shorter way of achieving
string definitions is a bad idea.

> I regard the potential benefit mentioned in the last sentence as
> unpersuasive, but the potential catastrophe of the initial example as
> tilting the scales toward the proposal.

Thanks!  Though I fear losing your support with the rest of this
context, and would appreciate your further perspectives.

At 2023-04-02T08:30:42+0100, Ralph Corderoy wrote:
> > tl;dr: For this input:
> >
> > .tr 

Re: Terminal problem? man formatting problem?

[Frederic Chartier]

On 2023-04-24 03:49 +0200, Oliver Corff wrote:

> I cannot use xterm, uxterm and Eterm on my system because of the high
> screen resolution; those terminal windows appear as tiny stamps which do
> not accept the Ctrl-+ resizing command.

With XTerm, the font can be set in three ways that I know of.
By setting the appropriate resource (perhaps "XTerm*vt100.font")
in your ~/.Xresources, through option "-fn" and interactively,
with [shift]-[-] and [shift]-[+]. If you know what font you
want, a wrapper script can be as simple as

#!/bin/sh
: ${font:="-b&h-lucidatypewriter-medium-r-normal-sans-26-190-100-100-m-159-*"}
exec xterm -fn "$font" "$@"

Re: user-defined characters, translation maps, and environment binding

[Ralph Corderoy]

Hi Branden,

> > .char £ pound sterling
> > .char $ United States dollar
> > .
> > The £ and $ are almost at par.
> > .
> > .tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ
> > £ crashes overnight!
> > .
> > .pl \n(nlu
> > ^D
> > The pound sterling and United States dollar are almost at par.
> > POUND STERLING CRASHES OVERNIGHT!
...
> > I'd want to see shouty caps.
>
> I think this an excellent example of user-defined character abuse.

It's a long-standing idiom.  Not abuse.

> There's no reason not to use strings here.
...
> .  de UP
> .tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ
> .ds \\$1 \\*[\\$1]
> .tr AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
> .  .
...
> .ds P pound sterling\"
> .ds D United States dollar\"
> .
> The \*P and \*D are almost at par.
> .
> .ds news \*P crashes overnight!
> .UP news
> \*[news]
> .pl \n(nlu

Reasons not to use strings here:

- It avoids having to re-work existing documents.
- The text should be typed with £ and $, not \*P and \*D.
- The text to shout now has to be put into a string, a macro called, and
  the string interpolated.  Before, the text was just written.

It sounds like transliteration local to an environment is a new feature,
not one worthy of breaking .tr.

-- 
Cheers, Ralph.

Re: Terminal problem? man formatting problem?

[Oliver Corff]

Thank you indeed!

Long bygone are the times when I still actively worked with the X Window
System and Athena Widgets.

The shift-+ had slipped by, I was so accustomed to use ctrl-+.

Branden had already told me to use -fn.

Thank you again,

Oliver.


On 24/04/2023 11:55, Frederic Chartier wrote:

On 2023-04-24 03:49 +0200, Oliver Corff wrote:


I cannot use xterm, uxterm and Eterm on my system because of the high
screen resolution; those terminal windows appear as tiny stamps which do
not accept the Ctrl-+ resizing command.

With XTerm, the font can be set in three ways that I know of.
By setting the appropriate resource (perhaps "XTerm*vt100.font")
in your ~/.Xresources, through option "-fn" and interactively,
with [shift]-[-] and [shift]-[+]. If you know what font you
want, a wrapper script can be as simple as

#!/bin/sh
: ${font:="-b&h-lucidatypewriter-medium-r-normal-sans-26-190-100-100-m-159-*"}
exec xterm -fn "$font" "$@"




--
Dr. Oliver Corff
mailto:oliver.co...@email.de

Re: Comprehension problem with macros

[Ralph Corderoy]

Hi Branden,

> > yes, I remember having heard of the two different modes
>
> "Copy mode" and (not copy mode), which didn't have a name in CSTR #54.
> (Terser is better.  :-| )

No name is needed.  It would be clutter to add it.  troff is either in
copy mode or is not in copy mode.  There is no need for a not-copy mode
term.

There are quite a few modes in troff, e.g. ligature.  There isn't a
special term for not being in ligature mode.  Creating a mode ‘bar’ to
indicate the mode isn't ‘foo’ increases what needs to be learnt and
remembered from one term to two terms and the relationship between them.

-- 
Cheers, Ralph.

Re: user-defined characters, translation maps, and environment binding

[G. Branden Robinson]

At 2023-04-24T11:31:10+0100, Ralph Corderoy wrote:
> > > .char £ pound sterling
> > > .char $ United States dollar
> > > .
> > > The £ and $ are almost at par.
> > > .
> > > .tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ
> > > £ crashes overnight!
> > > .
> > > .pl \n(nlu
> > > ^D
> > > The pound sterling and United States dollar are almost at par.
> > > POUND STERLING CRASHES OVERNIGHT!
> ...
> > > I'd want to see shouty caps.
> >
> > I think this an excellent example of user-defined character abuse.
> 
> It's a long-standing idiom.  Not abuse.

Can you show me an example from anyone's work but your own?  Can you
show me long-standing work of yours that you didn't produce solely for
discussion of *roff behavior?

I am furthermore skeptical of the level of precedential value you impute
to the `char` request, since it does not appear in the source you cite
in preference to all others: CSTR #54.

> > There's no reason not to use strings here.
> ...
> > .  de UP
> > .tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ
> > .ds \\$1 \\*[\\$1]
> > .tr AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
> > .  .
> ...
> > .ds P pound sterling\"
> > .ds D United States dollar\"
> > .
> > The \*P and \*D are almost at par.
> > .
> > .ds news \*P crashes overnight!
> > .UP news
> > \*[news]
> > .pl \n(nlu
> 
> Reasons not to use strings here:
> 
> - It avoids having to re-work existing documents.

There are limits to this principle.  In the extreme, you should be using
something with a TRIP test.  Or DWB 3.3 troff, which will never change.

> - The text should be typed with £ and $, not \*P and \*D.

This is the best potential point, but since your example is pretty
contrived in the first place, it's hard to weigh.

So let me get this straight:

You want to use ordinary input characters, read by the formatter in
isolation (i.e., not as arguments to requests or escape sequences), as
abbreviations for arbitrarily long interpolations.  This is not
something that can be done, as far as I know, under a CSTR #54 troff.
Despite the provision of _three_ text interpolation features in CSTR #54
(macros, strings, and diversions), this one you identify as uniquely
indispensable, despite the fact that _all three_ are subject to
translation.

.tr aAbBcC
.ds X a\"
.de Y
b
..
S: \*X
.br
M:
.Y
.br
.di Z
.br
c
.br
.di
D:
.Z
.pl \n(nlu

I invite you to inspect the letter cases of 'a', 'b', and 'c' in the
output.

But maybe your implicitly long-standing example was not such a good one
after all.

$ cat ATTIC/will-a-char-break.groff
.char $ United States dollars
I had some $,
spent some $,
earned some $,
then went to Vegas and lost my $.
.pl \n[nl]u
$ nroff ATTIC/will-a-char-break.groff
I  had some United States dollars, spent some
United States dollars, earned  some  United States dollars,  then
went to Vegas and lost my United States dollars.

If you use a string, we see that the spaces between the words in your
"character" break, producing a better result.

$ cat ATTIC/will-a-char-break2.groff
.ds $ United States dollars
I had some \*$,
spent some \*$,
earned some \*$,
then went to Vegas and lost my \*$.
.pl \n(nlu
$ nroff ATTIC/will-a-char-break2.groff
I  had  some United States dollars, spent some United States dol‐
lars, earned some United States dollars, then went to  Vegas  and
lost my United States dollars.

It begins to sound like what you want is a system for defining arbitrary
input rewriting rules.

Have you looked at m4?

> - The text to shout now has to be put into a string, a macro called,
>   and the string interpolated.  Before, the text was just written.

But not without cost: the foreclosure of other useful applications.

> It sounds like transliteration local to an environment is a new
> feature, not one worthy of breaking .tr.

`tr` is already breaking page headers and has been since the late 1970s.

I know that speaks _for_ it in some people's eyes, perhaps yours, but
I'm not afraid to fix 30 year old bugs in groff.  I am similarly
nonchalant about fixing 50 year old bugs in troff, if I have the skill
to do so.  (Which, I admit, remains to be seen.)

Regards,
Branden


signature.asc
Description: PGP signature

Re: Comprehension problem with macros

[G. Branden Robinson]

At 2023-04-24T12:11:02+0100, Ralph Corderoy wrote:
> > > yes, I remember having heard of the two different modes
> >
> > "Copy mode" and (not copy mode), which didn't have a name in CSTR
> > #54.  (Terser is better.  :-| )
> 
> No name is needed.  It would be clutter to add it.  troff is either in
> copy mode or is not in copy mode.  There is no need for a not-copy
> mode term.

I disagree--there can be a need when the reader doesn't know which modes
implicate others.  Does nroff mode imply no-space mode?  Does fill mode
imply adjustment mode?  Does no-fill mode?  Is there only one adjustment
mode, or several?  Does nroff mode imply constant character width mode?
What about underline mode?  Does adjustment mode imply hyphenation mode?
Are all of these questions meaningful?  Can a novice tell which, if any,
are nonsensical?

Please don't _answer_ these.  I pose them for the benefit of people
other than you.

> There are quite a few modes in troff, e.g. ligature.

With this, I do agree.  One of these days I mean to assemble a table of
them since their variety is so bewildering.

> There isn't a special term for not being in ligature mode.  Creating a
> mode ‘bar’ to indicate the mode isn't ‘foo’ increases what needs to be
> learnt and remembered from one term to two terms and the relationship
> between them.

When your labels are "foo" and "bar", that's true.

As with variable naming, when one chooses identifiers that communicate
meaning, they can pay their freight.

I concede that this is a point lost on those who still name the
variables corresponding to their command-line option parser "cflag",
"xflag", "zflag", and so on.  I'm sure this is brilliant for a person
who wrote the code and remembers what all of the flags mean for that
particular application.

It's not for anyone new to the code.

Sustainable documentation, like sustainable code, is written for the
benefit of people other than author at their moment of maximum
familiarity with the work.

Regards,
Branden


signature.asc
Description: PGP signature

Re: user-defined characters, translation maps, and environment binding

[G. Branden Robinson]

[self-follow-up]

It turns out groff has changed the way not merely `char`, but the
vaunted `tr` itself, has worked before.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=21260e1cd2f6fed6b7798fae6078c4e0270d9641

Once upon a time, you could do this:

.tr éÉ

...and on non-preconv'ed input, no less.

But not since June 2002.  Before that, actually, as the commit above is
merely a documentation update.

preconv was introduced into the groff tree in December 2005, so there
was a good 2½ years there where you HAD to rewrite the above input as:

.tr é\['E]

You could (and can) still get away with 8-bit input on the left-hand
sides of translations.  Given that support for EBCDIC CCIDS 1047 is no
longer required for groff to operate on z/OS (a.k.a. OS/390 Unix), and
Latin-1 is much less lively now than it was in 2002, it doesn't seem
worth preserving even that if it gets in the way of GNU troff reading
UTF-8 input directly.

> At 2023-04-24T11:31:10+0100, Ralph Corderoy wrote:
> > It's a long-standing idiom.  Not abuse.
[...]
> > - It avoids having to re-work existing documents.

So did the change above.

Regards,
Branden


signature.asc
Description: PGP signature

Re: groff injects blank page

[Carlos]

On Mon, Apr 24, 2023 at 12:44:38AM -0500, G. Branden Robinson wrote:
> Hi Carlos,
> 
> At 2023-04-23T11:38:39-0400, Carlos wrote:
> > On Sat, Apr 22, 2023 at 04:33:52PM -0500, G. Branden Robinson wrote:
> > > At 2023-04-22T16:46:00-0400, Carlos wrote:
> > > > Sure. But no one's sure of the cause of the blank page.
> > > >
> > > > If you had to guess, what would it be?
> > >
> > > At present my guess is a loose blank line in your
> > > /etc/groff/man.local.
> >
> > Tsk tsk tsk. Branden Branden.
> >
> > Did you say open sesame. In spanish ‹Ábrete sésamo›? It takes some
> > effort but it works ;)
> >
> > This is it:
> >
> > .\" We must use consecutive page numbers when using PostScript to
> > .\" generate HTML images, and we must not reset the page number at the
> > .\" beginning (the 'ps4html' register is automatically added to the
> > .\" command line by the pre-HTML preprocessor).
> > .if !r ps4html \
> > .  if r P .pn 0\n[P]
> > .if !r cR \{\
> > .  ie n .nr cR 1
> > .  el   .nr cR 1
> > .\}
> 
> I must caution you that setting the `cR` register (it's short for
> "continuous rendering") when the formatter is not in "nroff mode", which
> is what the above code does, is going to result in bad typesetting for
> PostScript, PDF, DVI, and some more obscure output devices.  But it
> won't hurt terminal output, which already uses continuous rendering
> (because terminal devices are always in "nroff mode").  The `cR`
> register is documented in groff_man(7).  The `ps4html` register is...not
> documented.  :-|

Thank you for advising me against this

And by the looks of it, neither is mso. And this is important. Very
important.

> 
> > Quite honestly,  I don't understand much of the macros initials,
> 
> The requests themselves, `if`, `ie`, `el`, `pn`, and `nr` are documented
> in the groff(7) man page and groff's Texinfo manual.

thank you Branden. But before continuing with what and whatnot is
documented, it would be advisable to clarify what man page are we
exactly referring to here.

What I'm trying to say is that we need (not need, my mistake on
using t hat term, but rather ought to be, I think) in the proverbial
'same page' to avoid inferring the wrong conclusions, maybe? .
Earlier on this thread you referred me to further read/consult a section
aptly named "Files". But unfortunately, that section "Files" does not exist in
any shape or form on the man pages I had been following/reading.

As a result, this leads to even more confusion than what was intended, or
what was planned. 

Let me ask you something, if you wouldn't mind. What happened to the other folks
who wrote the man pages I've been reading? Did they retire or burnt
out. Nothing wrong with burnt out, I'm burnt out already and haven't
even put a fraction of that documentation in place. But I can see that you 
mentioned
some of these individuals in the man pages you referenced, but most
important of all, is that the references to what you're alluding are
not the same references by which I or any other user out there, are relying
solely upon. The contents of these man pages differ in
scope and details from one another .

Hear me out for a second here please. Most distributions out there,  most,
and I'm not going to say only a handful of them, but most of them, prepackage 
the
man pages written by the other folks and not the updated version as
you've been referring to here. 

It's praiseworthy that you and others are updating all of this
documentation, but I wouldn't like to suddenly drop the old documentation
like a hot potato just because lots of changes/fixes have taken
place.. Perhaps I should do so to keep up with the latest … 
But I would rather keep the old documentation. Omissions on the current
version do not document the same.

Of course. I'm assuming that most folks who follow groff development
to various degrees, are aware of all this updating that goes on behind
the scenes with its documentation and programs, but I can't warrant
the same conclusion that the majority of users or end-users would
follow suit as the rest. Doing so would be fallacious.

But I'll keep both 1.22 and 1.23 


> 
> > So I thought: perhaps an-old.tmac would give me some clues, so I went
> > there, and cR looked like a candidate,  a nd I just modified the
> > values from 0 to 1 and it worked :) But it turns out: it's a
> > register!!!
> >
> > Ignorance is bliss. I tell you. A register with different values that
> > caught my attention. That's funny :)
> 
> I think what happened is that by making this change, you masked a bug in
> /etc/groff/man.local.
> 
> It's okay to claim victory and move on if things are working to your
> satisfaction, but the change you made is a hack with undesirable side
> effects that you might care about later.  I would add a comment to
> yourself in the file documenting the change you made and why.  Six
> months from now, if you're trying to format a man page in PDF and it
> looks crazy, you'll have an easier time locating the source of the

Re: groff 1.23.0.rc4 available for testing

[Dave Kemper]

I encountered only one tiny issue: PROBLEMS has an item titled "I get
warnings about special characters in the groff_char(7) man page" that
includes sample warnings that don't match the warnings troff currently
generates.

I noticed this because when the build threw those warnings, the first
thing I did was search PROBLEMS for the warning text to see if it was
a known problem (which I was 99% sure it was; this is not my first
groff-building rodeo), which of course didn't work with the text
having changed.

PROBLEMS shows example warnings worded this way:

troff:man/groff_char.7:1000: warning: can't find special character '.j'

My build generated warnings worded like this:

troff: backtrace: file 'man/groff_char.7':1033
troff:man/groff_char.7:1033: warning: special character '.j' not defined

The line numbers needn't match, but the warning text should,
especially the part that's a likely search string (I at first used
"warning: special character").  Luckily this requires only a very
small change to a documentation file.

Re: mdoc(7): CHECKSTYLE

[Alex Colomar]

Hi Branden,

On 4/24/23 07:31, G. Branden Robinson wrote:

Hi Alex,

At 2023-04-23T16:17:06+0200, Alejandro Colomar wrote:

I got some errors from mdoc(7), which were probably due to the
LANDMINE
.
Why is that file problematic with mdoc(7)?


I can't tell you; I get "Path not found" from that URL.


Yeah, I had some urgent need to remove the file right after sending
the email.  You could check go to the log of that file (the log
works even when the file no longer exists), then go the the commit
prior to removal, then go back to the tree, and see the file.

Alternatively, I can send you the link directly :)






Anyway, I thought that I could just remove it, since it's easier to
check with grep(1) if there's anything printed on stderr.  I should
have thought of that before.


And, done.



You may ask why am I using mdoc(7).


No.  It's a free country.  ;-)


I'm not so sure of that, but at least it's a free software.  ;-)




I was just making sure that the Linux man-pages' build system works
with mdoc(7) pages.


This is a good idea and I predict Ingo will not object.  :)


So now it's useful for testing arbitrary manual pages from other
projects by just wiping man*/ and copying the pages from other
projects into the repo.  Or even more interestingly, one can simply
copy the makefiles to /usr/share/man/ and go wild.  debbugs might see
a sudden burst of issues regarding man pages :-}.


I found that I had to ignore some files in the Makefile because 
otherwise make(1) would go crazy.  I'm talking about files

containing ':' in their file name.  There are a lot of them,
especially in Perl pages.  Other than that, it seems to work
(I had to decompress my pages, though, which for some reason was
more difficult than I expected).



Uh-oh; I fear I might get some of the blame.  I'll have to lobby
Congress for immunity from liability for misuse of the high-capacity
ammunition clips I sell to people who do mass bug filings against man
pages...


You might also want to get yourself a vest.  :-)


$ make check -k
TROFF   .tmp/man/man1/gpinyin.1.cat.set
troff: man1/gpinyin.1:316: warning: macro 'AD' not defined
make: *** [share/mk/build/catman.mk:47: .tmp/man/man1/gpinyin.1.cat.set] 
Error 1

make: *** Deleting file '.tmp/man/man1/gpinyin.1.cat.set'
TROFF   .tmp/man/man5/groff_font.5.cat.set
troff: man5/groff_font.5:813: warning: macro 'AD' not defined
make: *** [share/mk/build/catman.mk:47: 
.tmp/man/man5/groff_font.5.cat.set] Error 1

make: *** Deleting file '.tmp/man/man5/groff_font.5.cat.set'
TROFF   .tmp/man/man7/groff_char.7.cat.set
troff: man7/groff_char.7:1582: warning: can't find special character 'bs'
troff: man7/groff_char.7:1808: warning: can't find special character 
'radicalex'
troff: man7/groff_char.7:1810: warning: can't find special character 
'sqrtex'
make: *** [share/mk/build/catman.mk:47: 
.tmp/man/man7/groff_char.7.cat.set] Error 1

make: *** Deleting file '.tmp/man/man7/groff_char.7.cat.set'
TROFF   .tmp/man/man7/groff_mdoc.7.cat.set
mdoc warning: .St: Unknown standard abbreviation '-susv1' (#2540)
  Please refer to the groff_mdoc(7) manpage for a
  list of available standard abbreviations.
mdoc warning: .St: Unknown standard abbreviation '-susv4' (#2546)
  Please refer to the groff_mdoc(7) manpage for a
  list of available standard abbreviations.
make: *** [share/mk/build/catman.mk:53: 
.tmp/man/man7/groff_mdoc.7.cat.set] Error 1

make: *** Deleting file '.tmp/man/man7/groff_mdoc.7.cat.set'
make: Target 'check' not remade because of errors.


$ make lint-man-tbl -k
LINT (tbl comment)  .tmp/man/man1/chem.1.lint-man.tbl.touch
man1/chem.1:1: missing '\" t' comment:
.TH \%chem 1 "24 April 2023" "groff 1.23.0.rc4.19-96b92"
make: *** [share/mk/lint/man/man.mk:42: 
.tmp/man/man1/chem.1.lint-man.tbl.touch] Error 1

LINT (tbl comment)  .tmp/man/man1/groff.1.lint-man.tbl.touch
man1/groff.1:1: missing '\" t' comment:
.TH groff 1 "24 April 2023" "groff 1.23.0.rc4.19-96b92"
make: *** [share/mk/lint/man/man.mk:42: 
.tmp/man/man1/groff.1.lint-man.tbl.touch] Error 1

LINT (tbl comment)  .tmp/man/man7/groff_www.7.lint-man.tbl.touch
man7/groff_www.7:1: missing '\" t' comment:
.TH groff_www 7 "24 April 2023" "groff 1.23.0.rc4.19-96b92"
make: *** [share/mk/lint/man/man.mk:42: 
.tmp/man/man7/groff_www.7.lint-man.tbl.touch] Error 1

make: Target 'lint-man-tbl' not remade because of errors.


And here go the ones from mandoc(1), which is more picky:


$ make lint-man-mandoc -k |& grep -v -e 'WARNINGS: invalid escape 
sequence' -e 'UNSUPP: unsupported roff request' -e 'WARNING: invalid 
escape sequence'

LINT (mandoc)   .tmp/man/man1/addftinfo.1.lint-man.mandoc.touch
mandoc: man1/addftinfo.1:1:17: WARNING: cannot parse dat

Re: [mom] Extraneous empty line that starts a new page

[Peter Schaffter]

Sorry for top-quoting Branden's reply _in toto_ but it will make
replying easier.

On Sun, Apr 23, 2023, G. Branden Robinson wrote:
> Hi Frederic,
> 
> At 2023-04-24T01:37:00+0200, Frederic Chartier wrote:
> > I've stumbled on another problem with -mom. There is a table at
> > the bottom of a page. After the table, something inserts what
> > behaves like a line feed and Groff warns that
> > 
> > [mom]: '2023-04-24.mom', macro TE, line 61:
> > Insufficient room for label, caption, and/or source after
> > table on page 1.  Omitting, but continuing to process.
> > 2023-04-24.mom:61: environment stack underflow
> > 
> > Two things strike me as odd about these messages. First, the
> > table in question has no label, caption or source so why warn
> > about it ? Second, "environment stack underflow" sounds like
> > something went wrong in mom's internals.
> 
> I don't have a solution for you because I'm not qualified to do mom(7)
> support, but I can clarify a couple of things.
> 
> The first diagnostic messge comes from the macro package, from mom(7)
> itself.  The second one, the cryptic "environment stack underflow",
> comes from the formatter (GNU troff).
> 
> I tried to dig deeper into this, but when I format this document using
> groff Git HEAD, with the "-b" and "-ww" flags to sniff out as many
> problems as possible, I get a _lot_ of diagnostics.
> 
> troff: backtrace: file 
> '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':20283
> troff:/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac:20283: 
> warning: macro 'PDFBOOKMARK.NAME' not defined
> troff: backtrace: file 
> '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':23328
> troff:/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac:23328: 
> warning: macro 'pdfview' not defined
> troff: backtrace: 
> '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':4286: macro 
> 'PRINTSTYLE'
> troff: backtrace: file 'ATTIC/frederic.mom':3
> troff:ATTIC/frederic.mom:3: warning: register '#COLLATE' not defined
> 
> Something's gone badly wrong, and I'm not sure what.

Indeed.

> Possibly the document's state is invalid (mom(7) is not
> implemented sloppily).

The document is well-formed except for the erroneous use of 'cm' as
a scaling unit instead of just 'c'.

> I'm sure Peter's cluebox is much fuller than mine.

Actually, no.  First things first.  Just guessing, but the backtrace
warnings you give, Branden, suggest you didn't process with pdfmom,
which takes care of pdf forward references.  Not sure about this.

Regardless, when I process the document with groff 1.23.0.rc1.3711-25fb
and mom-2.5_c, passing pdfmom the -b flag (but not the -w flag), I
receive a string of errors of the form

  troff: backtrace: '2023-04-24.mom':83: macro '3init'
  troff: backtrace: file '2023-04-24.mom':92
  troff:2023-04-24.mom:92: error: numeric overflow

The first thing to notice is that the document is 71 lines long so
the reported line numbers aren't useful.  Secondly, the macro
'3init' is not used in om.tmac.  I've scoured the tmac directory but
am unable to locate where it's defined nor where it's being called.
  
I've never seen this behaviour before.  It's been a while since I
needed tbl(1) in a mom document so I'm thinking it crept in during
one of the past year's bazillion commits.  Most likely something to
do with tbl(1) or with gropdf(1).  At any rate, I need help tracking
this down.

Once we get the mysterious 3init problem solved, I can take a look
at the OP's original problem.  tbl(1) handling at or near a page
transition presents a number of edge cases and I may not have caught
them all.

I'm re-attaching the OP's original document with the erroneous 'cm'
corrected to 'c' for convenience.

--
Peter Schafter
https://www.schaffter.ca
.PAPER A4
.DOCHEADER OFF
.PRINTSTYLE TYPESET
.L_MARGIN 2.0c
.R_MARGIN 2.0c
.B_MARGIN 2.0c
.PT_SIZE 14
.LS 20
.FAMILY H
.HEADERS
.HEADER_MARGIN 2.0c
.HEADER_GAP 1.5c
.HEADER_LEFT "x"
.HEADER_RIGHT #
.PAGINATE OFF
.START
.HEADER
.HEADING 1 "First heading"
.HEADING 2 "x"
.TS H
;
l r.
.TH
x   x
x   x
.TE
.HEADING 2 "x"
.TS H
;
l r.
.TH
x   x
x   x
x   x
.TE
.HEADING 2 "x"
.TS H
;
l r.
.TH
x   x
x   x
.TE
.HEADING 2 "x"
.TS H
;
l r.
.TH
x   x
.TE
.HEADING 2 "x"
.TS H
;
l r.
.TH
x   x
x   x
x   x
x   x
x   x
.TE
.NEWPAGE
.HEADING 1 "Second heading"
.HEADING 2 "x"
.TS H
;
l r.
.TH
x   x
x   x
.TE

Re: [mom] Extraneous empty line that starts a new page

[Frederic Chartier]

On 2023-04-24 14:55 -0400, Peter Schaffter wrote:

> I've never seen this behaviour before.  It's been a while since I
> needed tbl(1) in a mom document so I'm thinking it crept in during
> one of the past year's bazillion commits.  Most likely something to
> do with tbl(1) or with gropdf(1).  At any rate, I need help tracking
> this down.
> 
> Once we get the mysterious 3init problem solved, I can take a look
> at the OP's original problem.  tbl(1) handling at or near a page
> transition presents a number of edge cases and I may not have caught
> them all.

Thanks for looking, Branden and Peter. Here's another
tbl-related problem I've encountered, in case the two are
connected. Groff acts as if every table were preceded by an
empty paragraph. This is why there is so much vertical space
between the headings and the tables that follow them. My
work-around was to put ".LS 0" in front of every ".TS".

I'm running groff 1.22.3, by the way. It's been patched but not
since 2016 so if it's bugs I'm seeing, they're not new.

groff-1.23.0.rc4 - no ./configure?

[Oliver Corff]

Dear all,

I went to https://git.savannah.gnu.org/cgit/groff.git today to download
the rc4 tarball groff-1.23.0.rc4.tar.gz and unpacked the archive.

How do I configure the makefile? I fail to see a ./configure script.

Thank you,

Best regards,

Oliver.

--
Dr. Oliver Corff
Mail: oliver.co...@email.de

Re: groff-1.23.0.rc4 - no ./configure?

[Carlos]

On Mon, Apr 24, 2023 at 10:40:23PM +0200, Oliver Corff wrote:
> Dear all,
> 
> I went to https://git.savannah.gnu.org/cgit/groff.git today to download
> the rc4 tarball groff-1.23.0.rc4.tar.gz and unpacked the archive.
> 
> How do I configure the makefile? I fail to see a ./configure script.
> 
> Thank you,
> 
> Best regards,
> 
> Oliver.
> 
> --
> Dr. Oliver Corff
> Mail: oliver.co...@email.de
> 
> 

Hello Oliver. The following is directly from INSTALL.REPO

Once dependencies are met of course. 


Bootstrapping from a Git checkout
-

Invoke the bootstrap script.

$ ./bootstrap


What bootstrapping does
---

The foregoing procedure will do two things:

  - clone the gnulib repository as a Git submodule in 'gnulib', add the
needed gnulib source files in 'lib' as well as required gnulib m4
macros in 'gnulib_m4'; and

  - invoke 'autoreconf', which will call the GNU Autotools ('aclocal',
'autoconf', 'automake') in the right order to create the following
files.

-- INSTALL (a symlink to gnulib's INSTALL file)
-- Makefile.in
-- aclocal.m4
-- autom4te.cache/
-- build-aux/ (which contains all the helper scripts)
-- configure
-- src/include/config.hin

'aclocal.m4' is a generated file; groff's m4 macros are included via the
'acinclude.m4' file.


Building


You can now invoke the 'configure' script.  It produces the
'config.status' script, which generates the Makefile.  Then call 'make'
to build the groff project.  You can do these from the source tree.

$ ./configure
$ make # run with -j option if desired

You can alternatively build groff outside of its source tree, which is
cleaner, leaving fewer files to confuse 'git status' if you aim to
undertake development.

$ mkdir build
$ cd build
$ ../configure
$ make # run with -j option if desired

A separate build tree need not be a subdirectory of the source.


Evaluation
--

Several dozen sanity checks can be performed within the build tree.

$ make check # run with -j option if desired


Installation


When the build is finished you can install the groff build artifacts.

$ make install install-doc # run with 'sudo' if necessary


-- 
This login session: $13.76, but for you $11.88.

Re: groff-1.23.0.rc4 - no ./configure?

[G. Branden Robinson]

Hi Oliver,

At 2023-04-24T22:40:23+0200, Oliver Corff wrote:
> I went to https://git.savannah.gnu.org/cgit/groff.git today to
> download the rc4 tarball groff-1.23.0.rc4.tar.gz and unpacked the
> archive.

I've made the same mistake myself!

The official distribution archives are not available via the cgit
interface.  cgit doesn't know about FSF deployment procedures and hasn't
been taught.

As noted in the RC announcement email[1], you need to get the
distribution archive from the alpha.gnu.org website.

  https://alpha.gnu.org/gnu/groff/

> How do I configure the makefile? I fail to see a ./configure script.

Carlos's response here was correct--you have to use the INSTALL.REPO
instructions if you want to build from the Git repository--but if you
want to provide feedback on the release candidate, then that's not the
procedure to follow.

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff/2023-04/msg00135.html


signature.asc
Description: PGP signature

Re: groff injects blank page

[G. Branden Robinson]

Hi Carlos,

At 2023-04-24T11:17:08-0400, Carlos wrote:
> On Mon, Apr 24, 2023 at 12:44:38AM -0500, G. Branden Robinson wrote:
> > The `cR` register is documented in groff_man(7).  The `ps4html`
> > register is...not documented.  :-|
> 
> Thank you for advising me against this
> 
> And by the looks of it, neither is mso. And this is important. Very
> important.

mso is a request, and it is documented in groff(7) like other requests.

I might have time to follow up on the rest later, but I will note
briefly that "Ignored because insecure." does not sound like language I
recognize from any groff release.  It sounds exactly like mandoc(1)
documentation--specifically the mandoc_roff(7) page.  mandoc is a
separate project and groff developers have no responsibility for it.

(We have one contributor, Ingo Schwarze, who is the mandoc project
lead.)

Please take this fact into account when developing your conclusions.

Regards,
Branden


signature.asc
Description: PGP signature

Re: groff-1.23.0.rc4 - no ./configure?

[Alejandro Colomar]

[CC += CGit]

Hi Branden!

On 4/25/23 00:14, G. Branden Robinson wrote:
> Hi Oliver,
> 
> At 2023-04-24T22:40:23+0200, Oliver Corff wrote:
>> I went to https://git.savannah.gnu.org/cgit/groff.git today to
>> download the rc4 tarball groff-1.23.0.rc4.tar.gz and unpacked the
>> archive.
> 
> I've made the same mistake myself!
> 
> The official distribution archives are not available via the cgit
> interface.  cgit doesn't know about FSF deployment procedures and hasn't
> been taught.

Curious way to put it.  I wondered something along those lines recently:
Is it possible to teach cgit how to create a tarball?  It would be nice
if I just made a tag and cgit would do the automated process necessary
for the tarball.

Moreover, I considered not releasing tarballs anymore as a possibility,
since one can produce them following some repeatable command.

Would I be able to teach cgit to run

$ make dist-gz

And then find the tarball in ./.tmp/$(git describe).tar.gz ?

Cheers,
Alex

> 
> As noted in the RC announcement email[1], you need to get the
> distribution archive from the alpha.gnu.org website.
> 
>   https://alpha.gnu.org/gnu/groff/
> 
>> How do I configure the makefile? I fail to see a ./configure script.
> 
> Carlos's response here was correct--you have to use the INSTALL.REPO
> instructions if you want to build from the Git repository--but if you
> want to provide feedback on the release candidate, then that's not the
> procedure to follow.
> 
> Regards,
> Branden
> 
> [1] https://lists.gnu.org/archive/html/groff/2023-04/msg00135.html

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: groff 1.23.0.rc4 available for testing

[G. Branden Robinson]

At 2023-04-24T11:18:32-0500, Dave Kemper wrote:
[...]
> PROBLEMS shows example warnings worded this way:
> 
> troff:man/groff_char.7:1000: warning: can't find special character '.j'
> 
> My build generated warnings worded like this:
> 
> troff: backtrace: file 'man/groff_char.7':1033
> troff:man/groff_char.7:1033: warning: special character '.j' not defined
> 
> The line numbers needn't match, but the warning text should,
> especially the part that's a likely search string (I at first used
> "warning: special character").  Luckily this requires only a very
> small change to a documentation file.

Indeed.  I'll fix this and you'll see it in my next push to master.

Thanks, Dave!

Regards,
Branden


signature.asc
Description: PGP signature

Re: [mom] Extraneous empty line that starts a new page

[G. Branden Robinson]

Hi Peter,

Thanks for riding to my support-department rescue.  :)

At 2023-04-24T14:55:00-0400, Peter Schaffter wrote:
> > Something's gone badly wrong, and I'm not sure what.
> 
> Indeed.
> 
> > Possibly the document's state is invalid (mom(7) is not
> > implemented sloppily).
> 
> The document is well-formed except for the erroneous use of 'cm' as
> a scaling unit instead of just 'c'.

...and even that appears to be harmless, at least in isolation.
Appending scaling units to an already-scaled value does not change its
value.

$ ./build/test-groff -Tutf8
.nr a 3c
.nr b 3cm
.tm a=\na, b=\nb
a=283, b=283

This suggests that one could get away with "3in" as well.  Yeesh.  Not
sure how I feel about that.  I think I'd prefer to have Yet Another
Warning Diagnostic for non-pristine input syntax.

But, back to the problem at hand...

> > I'm sure Peter's cluebox is much fuller than mine.
> 
> Actually, no.  First things first.  Just guessing, but the backtrace
> warnings you give, Branden, suggest you didn't process with pdfmom,
> which takes care of pdf forward references.  Not sure about this.

That's correct.  It usually doesn't occur to me to do this.  Also, we
don't have a "test-pdfmom" script so I have to do a lot of typing--I
could write a shell function--to exercise it from a build tree.

> Regardless, when I process the document with groff 1.23.0.rc1.3711-25fb
> and mom-2.5_c, passing pdfmom the -b flag (but not the -w flag), I
> receive a string of errors of the form
> 
>   troff: backtrace: '2023-04-24.mom':83: macro '3init'
>   troff: backtrace: file '2023-04-24.mom':92
>   troff:2023-04-24.mom:92: error: numeric overflow
> 
[rearranging a little here]

I have a few observations about this, one of which startled me.

1.  When I format the document with pdfmom from groff 1.23.0.rc4, but
without '-ww', I get _no diagnostics at all_.  But the output also
has no (text) content.

2.  When I add the '-ww' flag, I get tons of diagnostics.  They start
like this.

$ GROFF_BIN_PATH=./build GROFF_FONT_PATH=./build/font 
GROFF_TMAC_PATH=./contrib/mom ./build/pdfmom -b -ww -z ./ATTIC/frederic.mom
troff: backtrace: file './contrib/mom/om.tmac':20283
troff:./contrib/mom/om.tmac:20283: warning: macro 'PDFBOOKMARK.NAME' not defined
troff: backtrace: file './contrib/mom/om.tmac':23328
troff:./contrib/mom/om.tmac:23328: warning: macro 'pdfview' not defined
troff: backtrace: './contrib/mom/om.tmac':4286: macro 'PRINTSTYLE'
troff: backtrace: file './ATTIC/frederic.mom':3
troff:./ATTIC/frederic.mom:3: warning: register '#COLLATE' not defined
troff: backtrace: './contrib/mom/om.tmac':4341: macro 'PRINTSTYLE'
troff: backtrace: file './ATTIC/frederic.mom':3

...which is pretty reminiscent of the ones I got _without_ pdfmom(1).

> Secondly, the macro '3init' is not used in om.tmac.  I've scoured the
> tmac directory but am unable to locate where it's defined nor where
> it's being called.

It's a macro name constructed by tbl(1).  These days, our tbl man page
says:

  roff interface
[...]
GNU tbl internally employs register, string, macro, and diversion
names beginning with the numeral 3.  A document to be preproccessed
with GNU tbl should not use any such identifiers.

...but you probably don't violate this admonition.

> The first thing to notice is that the document is 71 lines long so
> the reported line numbers aren't useful.

No.  For a long time, GNU tbl had multiple bugs in its line number
handling.

[tbl] use of line continuation throws off input line counter
https://savannah.gnu.org/bugs/?62191

tbl reports incorrect line numbers in diagnostics
https://savannah.gnu.org/bugs/?60598

But I wouldn't swear to you that they're all squashed now.  They pass
the regression tests I have, which is a limited statement.

And, for full disclosure, the use of the `am` request is pretty much
guaranteed to throw off line numbers, at least in some circumstances.
Resolving that would be an interesting project.

> I've never seen this behaviour before.  It's been a while since I
> needed tbl(1) in a mom document so I'm thinking it crept in during
> one of the past year's bazillion commits.



> Most likely something to do with tbl(1) or with gropdf(1).  At any
> rate, I need help tracking this down.
> 
> Once we get the mysterious 3init problem solved, I can take a look
> at the OP's original problem.

Good news and bad news, which are the same news.  With groff 1.23.0.rc4,
none of the spew of diagnostics I get when using '-ww' with this
document implicates any tbl(1) macro or register names.  The scary
numeric overflow is gone, too.

The reason that's bad is that I don't have specific memory of fixing an
overflow bug in tbl.  In principle I could bisect it down...in a process
that binary searches the past year's bazillion commits.



> tbl(1) handling at or near a page transition presents a number of edge
> cases and I may not have caught them all.

I get most of the same diagnostics--if I use '-ww'--if I give 

Re: [mom] Extraneous empty line that starts a new page

[G. Branden Robinson]

Hi Frederic,

At 2023-04-24T21:56:58+0200, Frederic Chartier wrote:
> Here's another tbl-related problem I've encountered, in case the two
> are connected. Groff acts as if every table were preceded by an empty
> paragraph. This is why there is so much vertical space between the
> headings and the tables that follow them. My work-around was to put
> ".LS 0" in front of every ".TS".
> 
> I'm running groff 1.22.3, by the way. It's been patched but not
> since 2016 so if it's bugs I'm seeing, they're not new.

Space management around tables is the responsibility of each macro
package.  The job of tbl(1) itself is to render the table.  There was a
bug in the past several versions of groff in this area, but it involved
man(7) documents, not mom(7), and the issue was too little space _after_
a table, not too much _before_ it (also: in nroff mode only).

Regards,
Branden


signature.asc
Description: PGP signature

Re: [mom] Extraneous empty line that starts a new page

[G. Branden Robinson]

[self-clarification]

At 2023-04-24T18:13:09-0500, G. Branden Robinson wrote:
> Space management around tables is the responsibility of each macro
> package.  The job of tbl(1) itself is to render the table.  There was
> a bug in the past several versions of groff in this area, but it
> involved man(7) documents, not mom(7), and the issue was too little
> space _after_ a table, not too much _before_ it (also: in nroff mode
> only).

My use of the past tense suggests, but I did not explicitly state, that
the aforementioned bug is now fixed.  And it is, in the forthcoming
groff 1.23.0 release.

Some carnival barker _I_ am...

Regards,
Branden


signature.asc
Description: PGP signature

Re: groff-1.23.0.rc4 - no ./configure?

[Alejandro Colomar]

On 4/25/23 00:25, Alejandro Colomar wrote:
> [CC += CGit]
> 
> Hi Branden!
> 
> On 4/25/23 00:14, G. Branden Robinson wrote:
>> Hi Oliver,
>>
>> At 2023-04-24T22:40:23+0200, Oliver Corff wrote:
>>> I went to https://git.savannah.gnu.org/cgit/groff.git today to
>>> download the rc4 tarball groff-1.23.0.rc4.tar.gz and unpacked the
>>> archive.
>>
>> I've made the same mistake myself!
>>
>> The official distribution archives are not available via the cgit
>> interface.  cgit doesn't know about FSF deployment procedures and hasn't
>> been taught.
> 
> Curious way to put it.  I wondered something along those lines recently:
> Is it possible to teach cgit how to create a tarball?  It would be nice
> if I just made a tag and cgit would do the automated process necessary
> for the tarball.
> 
> Moreover, I considered not releasing tarballs anymore as a possibility,
> since one can produce them following some repeatable command.
> 
> Would I be able to teach cgit to run
> 
> $ make dist-gz
> 
> And then find the tarball in ./.tmp/$(git describe).tar.gz ?

Probably not.  My guess is that cgit just calls git-archive(1).

> 
> Cheers,
> Alex
> 
>>
>> As noted in the RC announcement email[1], you need to get the
>> distribution archive from the alpha.gnu.org website.
>>
>>   https://alpha.gnu.org/gnu/groff/
>>
>>> How do I configure the makefile? I fail to see a ./configure script.
>>
>> Carlos's response here was correct--you have to use the INSTALL.REPO
>> instructions if you want to build from the Git repository--but if you
>> want to provide feedback on the release candidate, then that's not the
>> procedure to follow.
>>
>> Regards,
>> Branden
>>
>> [1] https://lists.gnu.org/archive/html/groff/2023-04/msg00135.html
> 

Re: groff-1.23.0.rc4 - no ./configure?

[G. Branden Robinson]

At 2023-04-25T01:35:03+0200, Alejandro Colomar wrote:
> > Curious way to put it.  I wondered something along those lines
> > recently: Is it possible to teach cgit how to create a tarball?  It
> > would be nice if I just made a tag and cgit would do the automated
> > process necessary for the tarball.
> > 
> > Moreover, I considered not releasing tarballs anymore as a
> > possibility, since one can produce them following some repeatable
> > command.
> > 
> > Would I be able to teach cgit to run
> > 
> > $ make dist-gz
> > 
> > And then find the tarball in ./.tmp/$(git describe).tar.gz ?
> 
> Probably not.  My guess is that cgit just calls git-archive(1).

It's complicated, and has come up before[1].  I used to try to support
the cgit-constructed tarballs but it was too much support effort.

A big part of the problem is that whatever assembles the archives
doesn't pay attention to git submodules.  One of the most important
differences between a cgit-generated archive from the groff repo and a
distribution archive prepared by the maintainer is that the latter
includes the gnulib sources.  (Including the stuff that "make dist"
constructs for inclusion in the archive is the other important element.)

Regards,
Branden

[1] This is just one thread of several.

https://lists.gnu.org/archive/html/groff/2022-07/msg00064.html


signature.asc
Description: PGP signature

Re: [mom] Extraneous empty line that starts a new page

[Peter Schaffter]

Frederick --

On Mon, Apr 24, 2023, Frederic Chartier wrote:
> I'm running groff 1.22.3, by the way. It's been patched but not
> since 2016 so if it's bugs I'm seeing, they're not new.

Can you check whether you're using the latest version of mom
(2.5_c)?  If not, you can get it at

  https://www.schaffter.ca/mom/mom-2.5_c.tar.gz

The mom version that ships with 1.22.3 is quite out of date; this
may have a bearing on your problem.

-- 
Peter Schaffter
https://www.schaffter.ca

Re: [mom] Extraneous empty line that starts a new page

[Peter Schaffter]

Hi, Branden.

On Mon, Apr 24, 2023, G. Branden Robinson wrote:
> > Regardless, when I process the document with groff 1.23.0.rc1.3711-25fb
> > and mom-2.5_c, passing pdfmom the -b flag (but not the -w flag), I
> > receive a string of errors of the form
> > 
> >   troff: backtrace: '2023-04-24.mom':83: macro '3init'
> >   troff: backtrace: file '2023-04-24.mom':92
> >   troff:2023-04-24.mom:92: error: numeric overflow
> > 
> [rearranging a little here]
> 
> I have a few observations about this, one of which startled me.
> 
> 1.  When I format the document with pdfmom from groff 1.23.0.rc4, but
> without '-ww', I get _no diagnostics at all_.  But the output also
> has no (text) content.
> 
> 2.  When I add the '-ww' flag, I get tons of diagnostics.  They start
> like this.

I'll build/install/test 1.23.0_rc4 and report back with results.

> Good news and bad news, which are the same news.  With groff 1.23.0.rc4,
> none of the spew of diagnostics I get when using '-ww' with this
> document implicates any tbl(1) macro or register names.  The scary
> numeric overflow is gone, too.

Now, this is interesting.  Still running 1.23.0_rc1, I switched out
the tbl executable for the one that shipped with 1.22.4.  No numeric
overflow, everything went through fine.

It might be worth mentioning that the numeric overflow errors begin
with the second table in the OP's document.  The first, by itself,
generates none.
 
> > tbl(1) handling at or near a page transition presents a number of edge
> > cases and I may not have caught them all.
> 
> I get most of the same diagnostics--if I use '-ww'--if I give groff an
> input document consisting solely of this:
> 
> .PRINTSTYLE TYPESET
> 
> ...so much of this output may be a red herring

It is.
 
> For the time being I propose we back off of '-ww' usage with mom(7).
> I'm not sure it is helping illuminate anything.

Agreed.

> Maybe passing the white-gloved barracks inspection can be an objective
> for mom 2.6.  ;-)



Cheers.

-- 
Peter Schaffter
https://www.schaffter.ca

Re: Proposed: stop subjecting right-hand sides of `char` family requests to character translation

[G. Branden Robinson]

Hi Doug,

At 2023-04-02T13:40:41-0400, Douglas McIlroy wrote:
> My mistake. I found the word "entity" in groff.7, not groff_char.7.

I've pushed some documentation revisions to master that eliminate use of
the term "entity" when discussing groff's input language.  I had found
it confusing, too.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=0223aef4164a7b07cb933a397894878bb61773b5

> Nevertheless, thanks for the revised History section of groff_char.7.
> It's a far more definitive  account than I could give from my own
> memory.

My pleasure, and if any corrections should occur to you, I'd love to
hear them.

Regards,
Branden


signature.asc
Description: PGP signature

Re: groff-1.23.0.rc4 - no ./configure?

[Oliver Corff]

Hi Carlos,

thank you for directing me to the documentation buried in the two
INSTALL.* files.

May I suggest that the information along the way of obtaining the
tarball may be augmented?

My steps were:

1. I went to https://www.gnu.org/software/groff/#downloading

There the text reads: The development version is available from groff's
git repository . Read the
INSTALL.extra and INSTALL.REPO files within for build requirements and
instructions.

Which reconfirms your point, but

2. I went to the repository: https://savannah.gnu.org/git/?group=groff

It says: Browse Sources Repository

https://git.savannah.gnu.org/cgit/groff.git

3. I saw a list of tar.gz files, with the lates development version on
top. So I downloaded that and unpacked it locally.

4. Only then I saw the two INSTALL.* files and the instructions, but
executing ./bootstrap just resulted in

5. fatal: not a git repository (or any parent up to mount point /)

You may consider me being naive --- why do I stumble at things which are
"taken for granted"?

Is it possible to insert a phrase somewhere either in
https://www.gnu.org/software/groff/#downloading or in
https://savannah.gnu.org/git/?group=groff that these tarballs cannot be
used as is, but must be treated differently?

And, is it possible to put the information that these unpacked archives
cannot be used directly at the top of the INSTALL files?

Looking at a list of source tarballs and *thinking* they can be
downloaded, unpacked, configured and compiled is just enough off target.
It seems I miss the necessary threshold knowledge here.

Best regards,

Oliver.


On 24/04/2023 23:54, Carlos wrote:

On Mon, Apr 24, 2023 at 10:40:23PM +0200, Oliver Corff wrote:

Dear all,

I went tohttps://git.savannah.gnu.org/cgit/groff.git  today to download
the rc4 tarball groff-1.23.0.rc4.tar.gz and unpacked the archive.

How do I configure the makefile? I fail to see a ./configure script.

Thank you,

Best regards,

Oliver.

--
Dr. Oliver Corff
Mail:oliver.co...@email.de



Hello Oliver. The following is directly from INSTALL.REPO

Once dependencies are met of course.


Bootstrapping from a Git checkout
-

Invoke the bootstrap script.

 $ ./bootstrap


What bootstrapping does
---

The foregoing procedure will do two things:

   - clone the gnulib repository as a Git submodule in 'gnulib', add the
 needed gnulib source files in 'lib' as well as required gnulib m4
 macros in 'gnulib_m4'; and

   - invoke 'autoreconf', which will call the GNU Autotools ('aclocal',
 'autoconf', 'automake') in the right order to create the following
 files.

 -- INSTALL (a symlink to gnulib's INSTALL file)
 -- Makefile.in
 -- aclocal.m4
 -- autom4te.cache/
 -- build-aux/ (which contains all the helper scripts)
 -- configure
 -- src/include/config.hin

'aclocal.m4' is a generated file; groff's m4 macros are included via the
'acinclude.m4' file.


Building


You can now invoke the 'configure' script.  It produces the
'config.status' script, which generates the Makefile.  Then call 'make'
to build the groff project.  You can do these from the source tree.

 $ ./configure
 $ make # run with -j option if desired

You can alternatively build groff outside of its source tree, which is
cleaner, leaving fewer files to confuse 'git status' if you aim to
undertake development.

 $ mkdir build
 $ cd build
 $ ../configure
 $ make # run with -j option if desired

A separate build tree need not be a subdirectory of the source.


Evaluation
--

Several dozen sanity checks can be performed within the build tree.

 $ make check # run with -j option if desired


Installation


When the build is finished you can install the groff build artifacts.

 $ make install install-doc # run with 'sudo' if necessary



--
Dr. Oliver Corff
Wittelsbacherstr. 5A
10707 Berlin
G E R M A N Y
Tel.: +49-30-85727260
Mail:oliver.co...@email.de

Re: groff-1.23.0.rc4 - no ./configure?

[G. Branden Robinson]

Hi Oliver,

I've reported our desire for a switch to shut off these un-useful
cgit-generated archive links to the GNU Savannah admins.

https://savannah.nongnu.org/support/?110873

I've also updated the groff download instructions on its home page to
try to clarify matters, and add a link to the GNU alpha site for release
candidates.

https://www.gnu.org/software/groff/#downloading

Regards,
Branden


signature.asc
Description: PGP signature