Re: Differences in `ne` and `bp` line-breaking behavior

[G. Branden Robinson]

Hi onf,

At 2024-12-02T02:14:56+0100, onf wrote:
> No changes to groff are, strictly speaking, necessary.
> Your planned changes to .ad aren't necessary by the same logic either.
> But you desire them anyway because they make groff's behavior more
> reasonable. The same desire has motivated my proposal.

You omit part of the logic.  I see `ad` _actually get used_.  In man
pages.  Frequently, it is used incorrectly.  You can tell this because
the request is either a no-op where it is used, or has a perverse
effect, like frustrating the reader's deconfiguration of adjustment,
making some paragraphs in the man page have ragged right margins and the
others, not.  These are obviously unintentional errors.[1]  I've
submitted patches to projects like ncurses and bash (that got accepted,
possibly because I included explanations) to correct the misuse.

So part of my motivation for reforming/revising adjustment management is
that I _see_ people mis-applying the existing language feature.  They
don't get it.  When enough people don't get it, that suggests that the
problem is more with the language than with its users.

By contrast, your sample size for `ne` misuse is one--yourself.
Formerly two, before I came to understand the request.

Moreover, I don't think `ne` will ever see uptake among man page
authors--for a couple of good reasons.  One is that man pages are
rendered at widely disparate line lengths.  Also, there are subtle
annoyances involving changes in line height due to headings being set a
larger type size (but only in troff mode), and the height of tables
(horizontal rules and horizontal box edges in tbl(1) each take up an
additional vee, but only in nroff mode)  Much of the time, a guess
one makes about how many vees are needed to avoid stranded lines in a
man page is going to be wrong.  Further, many man page authors care only
about terminal output, and accustomed to "continuous rendering"[2] where
the problem of stranded lines never rears its head in the first place.

I don't think most man page authors are going to develop motivation to
exercise this feature whether it behaves as you want, or not.

And that's okay, because a superior solution IMO is to (1) support
keeps, which I think can be done straightforwardly and adopted without
much effort or subtlety of understanding by man page authors and (2)
more ambitiously, reëngineer our man(7) (and mdoc(7)?) paragraphing
macros under the hood to automatically format paragraphs into a
diversion, and avoid stranded lines with internal logic.  This will pay
big rewards--the document author won't even need to think about
it[3]--but will require some cleverness in implementation.  Doug McIlroy
put me on the scent of one approach, "self-renewing input traps", but I
haven't set aside the time to explore this, nor seen it done by anyone
else (a foreboding sign).

But, those things are for groff 1.25 at the earliest.  Though if (1) is
as easy as I think it is, maybe I could still get it in for 1.24...

> > Formatter requests are primitive things.  Most requests don't also
> > perform breaks. Only a handful do. Those that do support the
> > no-break control character to _schedule_ a change to formatter state
> > at the next break, when that happens for some other reason.
> 
> Please tell me how that is the case here:
>   $ nroff << EOF | sed -E 's/^/./'
>   .pl 3
>   .fi
>   One two three
>   four five six
>   'bp
>   seven eight nine
>   .br
>   eleven twelve.
>   EOF
> output:
>   .
>   .
>   .
>   .One two three four five six seven eight nine
>   .eleven twelve.
>   .
> 
> It's obvious here that 'bp breaks page IMMEDIATELY, not when the .br

Eh?

If it broke the page "IMMEDIATELY", you'd get this:

One two three four five six

seven eight nine eleven twelve.

But don't take my word for it.  Ask "groff -a".

$ printf 'Hello, world!\n.bp\n.c2 @\none two three\nfour five six\n@bp\nseven 
eight nine\n.br\nten eleven twelve\n' | groff -a

Hello, world!


one two three four five six seven eight nine
ten eleven twelve

Now let's try it with the regular control character.

$ printf 'Hello, world!\n.bp\none two three\nfour five six\n.bp\nseven eight 
nine\n.br\nten eleven twelve\n' | groff -a

Hello, world!

one two three four five six

seven eight nine
ten eleven twelve

> It's obvious here that 'bp breaks page IMMEDIATELY,

It doesn't.  It _schedules_ (or enqueues) a page break to occur when the
next (line) break does, causing the line to be set on the next page.

As with the phrase "prior to output", you and I seem to have strongly
divergent interpretations of certain phrases.

> The difference between .bp and 'bp is that one also breaks the pending
> input line and the other does not, NOT that the latter schedules page
> break after next line break.

This statement is unintelligible to me.  You appear to be contradicting
the Aristotelian law of identity.

The `bp` request, regardless of one's choice of control character,
_always_ schedules a page break at 

Re: Differences in `ne` and `bp` line-breaking behavior

[G. Branden Robinson]

Hi onf,

At 2024-12-02T02:26:12+0100, onf wrote:
> D'oh. I am sure I confused you even more. I meant to say either: To
> summarize, `ne` would break line if not in compatibility mode and
> called with the regular control character.
> 
> ... or ...
>   To summarize, `ne` would NOT break line if
> a) in compatibility mode
> b) not in compatibility mode and called with the NO-BREAK
>control character

Not this time--speaking for myself at least.  I managed to read right
over your error.  I find that this happens with distressing frequency in
my own writing.  If anyone is annoyed by how many typo fixes I push
after a set of commits, rest assured that I am even _more_ annoyed.
Something about the act of putting my errors out for the world to see
sharpens my ability to detect them.  While they're safe and warm in my
working copy, they hide from my brain like malevolent little insects.

Regards,
Branden


signature.asc
Description: PGP signature

stumped on a simple autoconf/m4/sh problem

[G. Branden Robinson]

[please reply to the groff@ as well; I am not subscribed to autoconf@]

Apparently I am having a moment of dumb.

In preparation for a 1.24 release, I am trying to get groff building on
Solaris 10, which has yet again received a stay of execution from
Oracle.[1]

https://blogs.oracle.com/solaris/post/new-end-date-of-extended-support-for-oracle-solaris-10-and-113

One of Solaris 10's many problems is its rotten `tr` implementation,
which is non-conforming with POSIX and writes wretchedly anonymous and
unhelpful diagnostic messages as well.  On the bright side, if one has
GNU coreutils installed, providing `gtr`, you can use that and be happy.
And that is what the FSF France's compiler farm has done.

So that's what I'm trying to make a groff build do.

AC_DEFUN([GROFF_FIND_POSIX_CONFORMING_TR], [
  AC_MSG_CHECKING([for a 'tr' that supports POSIX character classes])
  TR=no
  for cmd in tr gtr
  do
if test \
  "`printf 'a\tb' | $cmd '[[:cntrl:]]' '[[ *]]' 2> /dev/null`" \
  = 'a b'
then
  TR=$cmd
  break
fi
  done
  if test $TR != no
  then
AC_MSG_RESULT([$TR])
AC_SUBST([TR])
  else
AC_MSG_RESULT([(none)])
AC_MSG_NOTICE([A 'tr' command that supports POSIX character \
classes was not found.

Some 'hdtbl' example documents will fail to generate, and some test
scripts exercised by 'make check' will also fail.
])
  fi
])

Please excuse any non-idiomatic conventions in the foregoing; I am still
acquiring seasoning as an Autoconf macro writer.

The problem is that the test exercising `$cmd` succeeds on Solaris 10
when it should not.

No quoting screwups leap out at me:

$ sed -n '31492,31525p' configure
  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a 'tr' that supports 
POSIX character classes" >&5
$as_echo_n "checking for a 'tr' that supports POSIX character classes... " >&6; 
}
  TR=no
  for cmd in tr gtr
  do
if test \
  "`printf 'a\tb' | $cmd '[:cntrl:]' '[ *]' 2> /dev/null`" \
  = 'a b'
then
  TR=$cmd
  break
fi
  done
  if test $TR != no
  then
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $TR" >&5
$as_echo "$TR" >&6; }

  else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: (none)" >&5
$as_echo "(none)" >&6; }
{ $as_echo "$as_me:${as_lineno-$LINENO}: A 'tr' command that supports POSIX 
character \
classes was not found.

Some 'hdtbl' example documents will fail to generate, and some test
scripts exercised by 'make check' will also fail.
" >&5
$as_echo "$as_me: A 'tr' command that supports POSIX character \
classes was not found.

Some 'hdtbl' example documents will fail to generate, and some test
scripts exercised by 'make check' will also fail.
" >&6;}
  fi

But here's what happens...

checking for a 'tr' that supports POSIX character classes... tr

Yikes!

When I run equivalent code from the shell prompt:

if test "`printf 'a\tb' | tr '[:cntrl:]' '[ *]' 2> /dev/null`" = 'a b'; then 
echo good tr; else echo bad tr; fi
printf 'a\tb' | tr '[:cntrl:]' '[ *]' 2> /dev/null
bad tr

(That's bash-3.2, essential survival gear on a Solaris 10 system.)

$ if test "`printf 'a\tb' | tr '[:cntrl:]' '[ *]' 2> /dev/null`" = 'a b'; then 
echo good tr; else echo bad tr; fi
bad tr

(That's Solaris 10 /bin/sh, the World's Worst Living Shell.)

So the "good tr" branch is being taken in the configure script, but not
in vivo at a shell prompt.  I can't explain this.

Would someone kindly point out my rookie mistake?  My eyes are blind.

Regards,
Branden

[1] We have unconfirmed report that this is due to Larry Ellison
exercising a personal vendetta against me.


signature.asc
Description: PGP signature

Re: Build error in Devuan stable

[Alejandro Colomar]

Hi Branden,

Do you intend to fix this?  Should I report a bug in Savannah?

Cheers,
Alex

On Mon, Nov 25, 2024 at 12:36:49AM +0100, Alejandro Colomar wrote:
> On Sun, Nov 24, 2024 at 11:43:57PM +0100, onf wrote:
> > On Sun Nov 24, 2024 at 10:52 PM CET, Alejandro Colomar wrote:
> > > I'm having a build error when trying to build groff HEAD in Devuan
> > > stable.  ./bootstrap and ./configure succeed, and them make(1) fails.
> > > Below is the failure.  Let me know if you need more details.
> > >
> > > [...]
> > >   GEN  doc/groff.dvi
> > > [...]
> > > /usr/bin/texi2dvi: etex exited with bad status, quitting.
> > > make: *** [Makefile:15737: doc/groff.dvi] Error 1
> > 
> > As the output shows, this is a problem with building the Texinfo manual
> > rather than with building groff itself. Unfortunately the current build
> > process makes the manual inseparable from the program itself, so that
> > if you can't build the manual, the entire build fails... which doesn't
> > make a lot of sense since it's written in Texinfo, not troff, so its
> > build failing means nothing in terms of groff's functionality.
> > 
> > I recently suggested a patch which skips building the manual if makeinfo
> > isn't present or is outdated.[1] You can easily modify it to disable
> > building the manual even if it's present. Simply do this to the patch:
> >   s/(groff_have_makeinfo=)yes/\1no/
> > 
> > and apply it. Re-running make should suffice according to the docs; if
> > it doesn't, run the whole bootstrap > configure > make process again.
> 
> Thanks!  +1 to your proposal.
> 
>   Acked-by: Alejandro Colomar 
> 
> Branden, you may want to have a look at the Linux man-pages build
> system.  I'm not proposing that you replace autotools with some
> hand-written Makefiles, but the way the dependencies are laid out are
> interesting.  You can run `make` (a.k.a., `make build`) which runs all
> default targets.  In the man-pages project it only stamps the page date
> and project version into each page.  In other projects of mine (liba2i),
> it builds the library shared object (.so).
> 
> But then I allow building less than that with specialized `make build-*`
> targets:
> 
>   $ make help
>   To see a list of targets, run:
>   $ make nothing -p \
>   | grep '^\.PHONY:' \
>   | tr ' ' '\n' \
>   | grep -v '^\.PHONY:' \
>   | sort;
> 
>   To see a list of variables, run:
>   $ find GNUmakefile share/mk/configure -type f \
>   | sort \
>   | xargs grep '^[^[:space:]].*=' \
>   | sed 's/=.*/=/' \
>   | grep -v -e ':DEFAULT_.*=' -e ':MAKEFILE_.*INCLUDED :=';
> 
>   To see a list of dependencies (package/program), run:
>   $ find share/mk/configure/build-depends -type f \
>   | sed 's,share/mk/configure/build-depends/,,' \
>   | sed 's,\.mk,,' \
>   | sort;
> 
> 
>   $  make nothing -p \
>   | grep '^\.PHONY:' \
>   | tr ' ' '\n' \
>   | grep -v '^\.PHONY:' \
>   | sort \
>   | grep ^build;
>   build
>   build-all
>   build-catman
>   build-catman-eqn
>   build-catman-grotty
>   build-catman-troff
>   build-catman-troff-man
>   build-catman-troff-mdoc
>   build-ex
>   build-ex-cc
>   build-ex-dir
>   build-ex-ld
>   build-ex-src
>   build-fonts
>   build-fonts-download
>   build-fonts-tinos
>   build-html
>   build-html-post-grohtml
>   build-html-troff
>   build-html-troff-man
>   build-html-troff-mdoc
>   build-man
>   build-man-man
>   build-man-mdoc
>   build-man-so
>   build-pdf
>   build-pdf-book
>   build-pdf-pages
>   build-pdf-pages-eqn
>   build-pdf-pages-gropdf
>   build-pdf-pages-troff
>   build-pdf-pages-troff-man
>   build-pdf-pages-troff-mdoc
>   build-pre
>   build-pre-preconv
>   build-pre-tbl
>   build-ps
>   build-ps-eqn
>   build-ps-grops
>   build-ps-troff
>   build-ps-troff-man
>   build-ps-troff-mdoc
> 
> And have similar install-* targets:
> 
>   $ make nothing -p \
>   | grep '^\.PHONY:' \
>   | tr ' ' '\n' \
>   | grep -v '^\.PHONY:' \
>   | sort \
>   | grep ^install;
>   install
>   install-all
>   install-bin
>   install-html
>   install-man
>   install-man1
>   install-man2
>   install-man2const
>   install-man2type
>   install-man3
>   install-man3const
>   install-man3head
>   install-man3type
>   install-man4
>   install-man5
>   install-man6
>   install-man7
>   install-man8
>   install-manintro
>   install-pdf
>   install-pdf-book
> 
> This allows you to build parts of the project without needing to build
> the entire project, for whatever reasons

Re: Nested SY/YS

[G. Branden Robinson]

Hi Alex,

At 2024-12-01T15:17:22+0100, Alejandro Colomar wrote:
> I was wondering if it would be good to nest SY/YS.
> 
> What do you think of this?:
> 
>  .SY void\~*bsearch (
>  .BI const\~void\~ key [. size ],
>  .BI const\~void\~ base [. size \~*\~. n ],
>  .BI size_t\~ n ,
>  .BI size_t\~ size ,
>  .br
> -.BI int\~(* compar )(const\~void\~[. size ],
> +.SY int\~(*\f[I]compar\f[]) (
> +.BI const\~void\~[. size ],
>  .BI const\~void\~[. size ]));
> +.YS
>  .YS
> 
> 
> Which would ideally produce:
> 
>void *bsearch(const void key[.size],
>  const void base[.size * .n], size_t n, size_t size,
>  int (*compar)(const void [.size],
>const void [.size]));

How many documents in the Linux man-pages corpus do you expect to
benefit from such a feature?

Regards,
Branden


signature.asc
Description: PGP signature

Re: [HTML] Command Missing

[Tadziu Hoffmann]

> I get an error "sh: line 1: missing: command not found"
> And then:
> Calling 'echo showpage | missing -q -dBATCH -dSAFER -dDEVICEHEIGHTPOINTS=792 
> -dDEVICEWIDTHPOINTS=700 -dFIXEDMEDIA=true -sDEVICE=pnmraw -r100 
> -dTextAlphaBits=4 -dGraphicsAlphaBits=4  -sOutputFile=/tmp/groff-page-p9UCo9 
> /tmp/groff-ps-Z50Aox -
> ' returned status 32512

Judging from the command line and the parameters,
"missing" should have been "gs".

Differences in `ne` and `bp` line-breaking behavior

[onf]

Hi all,

I have discovered recently that `ne` and `bp` behave differently in
regards to pending input lines. `bp` breaks such lines, while `ne`
does not. In practice this means that `ne` does not behave like a
conditional `bp` as one would reasonably expect. This issue has been
discussed extensively on groff's bug tracker.[1]

I propose the following changes to make their behavior consistent:

 1. `ne` breaks line before breaking the page as `bp` does
 2. `ne` does not break line before breaking the page if called with
the no-break control character (which currently doesn't modify
its behavior in any way)

The second point means that the old behavior of .ne can be recovered
via 'ne. This matches the behavior of 'bp, which breaks page without
breaking the line as well.

Note that this change would break compatibility with other troff
implementations. However, it would be easy to fix any documents
which rely on the current behavior by substituting[2] any .ne
for 'ne, which, as pointed out above, behaves exactly like .ne
in other troff implementations.

I invite anyone who disagrees with this proposal to raise any
objections they might have, either here or on the bug tracker.

~ onf

[1] https://savannah.gnu.org/bugs/?66447

[2] sed -Ei 
"s/^\\.([[:blank:]]*)ne([[:blank:]]+)|^([.'][[:blank:]]*(i[fe].*|el)[[:blank:]]+)\\.([[:blank:]]*)ne([[:blank:]]+)/\\3'\\1\\5ne\\2\\6/"
 $(find -name '*.tr' -or -name '*.tmac')

This can handle .ne in if/ie/el one-liners and any whitespace
between the control character and the `ne`. I have tested it
quite a bit, but I suggest checking the result and possibly
creating a backup just in case I missed something anyway.
(sed -Ei.bak # ...)

Re: Differences in `ne` and `bp` line-breaking behavior

[onf]

On Mon Dec 2, 2024 at 2:14 AM CET, onf wrote:
> To summarize, `ne` would break line if
>   a) in compatibility mode
>   b) not in compatibility mode and called with the regular control
>  character

D'oh. I am sure I confused you even more. I meant to say either:
  To summarize, `ne` would break line if not in compatibility mode
  and called with the regular control character.

... or ...
  To summarize, `ne` would NOT break line if
a) in compatibility mode
b) not in compatibility mode and called with the NO-BREAK
   control character

My apologies.

~ onf

Re: Differences in `ne` and `bp` line-breaking behavior

[onf]

Hi Branden,

On Mon Dec 2, 2024 at 12:51 AM CET, G. Branden Robinson wrote:
> At 2024-12-01T23:06:41+0100, onf wrote:
> > I propose the following changes to make their behavior consistent:
> > 
> >  1. `ne` breaks line before breaking the page as `bp` does
> >  2. `ne` does not break line before breaking the page if called with
> > the no-break control character (which currently doesn't modify
> > its behavior in any way)
> > 
> > The second point means that the old behavior of .ne can be recovered
> > via 'ne. This matches the behavior of 'bp, which breaks page without
> > breaking the line as well.
>
> I don't agree with this change, because it's not necessary.

No changes to groff are, strictly speaking, necessary.
Your planned changes to .ad aren't necessary by the same logic either.
But you desire them anyway because they make groff's behavior more
reasonable. The same desire has motivated my proposal.

> Formatter requests are primitive things.  Most requests don't also perform
> breaks. Only a handful do. Those that do support the no-break control
> character to _schedule_ a change to formatter state at the next break,
> when that happens for some other reason.

Please tell me how that is the case here:
  $ nroff << EOF | sed -E 's/^/./'
  .pl 3
  .fi
  One two three
  four five six
  'bp
  seven eight nine
  .br
  eleven twelve.
  EOF
output:
  .
  .
  .
  .One two three four five six seven eight nine
  .eleven twelve.
  .

It's obvious here that 'bp breaks page IMMEDIATELY, not when the .br
is issued. The difference between .bp and 'bp is that one also breaks
the pending input line and the other does not, NOT that the latter
schedules page break after next line break.

My proposal seeks to make `ne`'s behavior consistent with that of `bp`.

> [...] There's nothing wrong with or weird about having a `ne`
> request when an output line is pending.

Please explain how, given the following descriptions from groff(7):
  .bp   Break page and start a new one.
  .ne d Break page if distance to next page location trap is less
than distance d (default scaling unit v).

is it not reasonable to expect these two lines to behave similarly:
  .ne 3v
  .if \n[.t]u<3v .bp

... because they don't.

> > Note that this change would break compatibility with other troff
> > implementations. However, it would be easy to fix any documents
> > which rely on the current behavior by substituting[2] any .ne
> > for 'ne, which, as pointed out above, behaves exactly like .ne
> > in other troff implementations.
> > 
> > I invite anyone who disagrees with this proposal to raise any
> > objections they might have, either here or on the bug tracker.
>
> I don't exactly object, but I'm pretty deeply uncertain about it.
>
> And we'd need to retain traditional handling of `ne` for AT&T
> compatibility mode, anyway.

The 'anyway' sounds like you think I am suggesting we remove the
current behavior entirely. As I explained in the part you quoted
above, that is not the case. `ne` would still behave as it does
now if called with the no-break control character (i.e. 'ne).

> If you disagree with that, then I _do_ object.

I see no reason to change the behavior in compatibility mode, I just
forgot about it. We can simply add this to the proposal:
  3. `ne` does not break line in compatibility mode

To summarize, `ne` would break line if
  a) in compatibility mode
  b) not in compatibility mode and called with the regular control
 character

~ onf

Re: Differences in `ne` and `bp` line-breaking behavior

[G. Branden Robinson]

At 2024-12-01T22:17:47-0600, Dave Kemper wrote:
> On Sun, Dec 1, 2024 at 8:27 PM G. Branden Robinson
>  wrote:
> > By contrast, your sample size for `ne` misuse is one--yourself.
> > Formerly two, before I came to understand the request.
> 
> Well, I agree with onf's point that .ne's behavior defies user
> expectation, so you can lump me in with that sample.

Well, maybe mine too.  This one surprised me:

$ printf 'Hello, world!\n.bp\n.c2 @\none two three\nfour five six\n@bp\nseven 
eight nine\n.br\nten eleven twelve\n' | groff -a

Hello, world!


one two three four five six seven eight nine
ten eleven twelve

I wasn't expecting TWO page breaks there.  But I've got 'em.  Is that
wrong?  I'm not sure.

And, just to head off the usual hecklers, let's ask groff 1.22.3.

$ printf 'Hello, world!\n.bp\n.c2 @\none two three\nfour five six\n@bp\nseven 
eight nine\n.br\nten eleven twelve\n' | ~/groff-1.22.3/bin/groff -a

Hello, world!


one two three four five six seven eight nine
ten eleven twelve

> Now, plenty of other roff behaviors also defy expectation, but we keep
> them around for back-compatibility reasons.  The reason I suggested
> starting this thread was to find out whether .ne's nonbreaking
> behavior is one that any users rely on. And this remains an open
> question: so far the discussion has been mostly theoretical.

Conceded.

> This is at best a tangential point: roff is used for plenty of things
> besides man pages.

Not at best tangential--man pages are the _predominant_ application of
roff in publicly available documents.  That matters.

> Arguably, man pages shouldn't use .ne at all for the various reasons
> you cite.

They should if they're typesetting them (and care about stranded lines),
until I can finagle in keeps and automatic paragraph diversions, thus
inaugurating a golden age of prosperity and pleasant typography.

Energy too cheap to meter!  A chicken in every pot!

> So discussions about how .ne should behave fall primarily under the
> domain of non-man documents.

It is the expertise of non-man users of the `ne` request that I would
most like to solicit.

> The syntax of \s was altered not because of exhibits of its misuse,
> but because its behavior was so aberrant that it surprised one of the
> most veteran of roff veterans.  So I'm not sure the above is the right
> hurdle to ask a proposal to clear.

I agree.  I think that was a case of a syntactical infelicity that was
just too ugly to live, so we killed it.  (And still caused offense among
the most rock-ribbed of grognards, in a notable case of being more
catholic than Popes Kernighan and McIlroy.)

> I'd rather ask, does it make the language easier to grasp / more
> intuitive without introducing incompatibilities that will break
> historical usage?

You state the criterion well, expressing the concerns we must balance.

I got yelled at from multiple quarters for a proclaimed excessive
disregard of the latter when changing the way the ms(7) package handled
no-space mode in places where inter-paragraph distance and display
distance could accumulate.

It is to my great misfortune that Bill Tuthill did not document
semantics for 4.2BSD ms's `DD` register _at all_.  It is not even
mentioned in his document presenting BSD's extensions[1], and gets only
the most rudimentary presentation possible in its man page.[2]

DD  display distancedisplays1v (if n), .5v (if t)

Given that, you know that it exists.  How does it or should it interact
with other features?  Why, you can make up your own mind about that, and
you will be absolutely correct, and anyone who disagrees with you is a
malicious idiot who's just trying to break your document.

Good times.

Regards,
Branden

[1] 
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/doc/msmacros/ms.diffs
[2] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/man/man7/ms.7


signature.asc
Description: PGP signature

Re: Differences in `ne` and `bp` line-breaking behavior

[Dave Kemper]

On Sun, Dec 1, 2024 at 8:27 PM G. Branden Robinson
 wrote:
> By contrast, your sample size for `ne` misuse is one--yourself.
> Formerly two, before I came to understand the request.

Well, I agree with onf's point that .ne's behavior defies user
expectation, so you can lump me in with that sample.  Now, plenty of
other roff behaviors also defy expectation, but we keep them around
for back-compatibility reasons.  The reason I suggested starting this
thread was to find out whether .ne's nonbreaking behavior is one that
any users rely on. And this remains an open question: so far the
discussion has been mostly theoretical.

> Moreover, I don't think `ne` will ever see uptake among man page
> authors--for a couple of good reasons.

This is at best a tangential point: roff is used for plenty of things
besides man pages.  Arguably, man pages shouldn't use .ne at all for
the various reasons you cite.  So discussions about how .ne should
behave fall primarily under the domain of non-man documents.

> "Part of my motivation for reforming/revising adjustment management is
> that I see people mis-applying the existing language feature."
>
> Show me exhibits of people besides yourself making the same mistake with
> `ne`.

The syntax of \s was altered not because of exhibits of its misuse,
but because its behavior was so aberrant that it surprised one of the
most veteran of roff veterans.  So I'm not sure the above is the right
hurdle to ask a proposal to clear.  I'd rather ask, does it make the
language easier to grasp / more intuitive without introducing
incompatibilities that will break historical usage?

Re: Differences in `ne` and `bp` line-breaking behavior

[G. Branden Robinson]

Hi onf,

At 2024-12-02T04:45:27+0100, onf wrote:
> On Mon Dec 2, 2024 at 3:26 AM CET, G. Branden Robinson wrote:
> > >   One two three
> > >   four five six
> > >   'bp
> > >   seven eight nine
[...]
> > > It's obvious here that 'bp breaks page IMMEDIATELY, not when the
> > > .br
> >
> > Eh?
> >
> > If it broke the page "IMMEDIATELY", you'd get this:
> >
> > One two three four five six
> > 
> > seven eight nine eleven twelve.
> > [...]
> 
> No, you wouldn't, because that line is still pending.

Then the page break is not immediate.

> We seem to interpret the word 'page break' differently.  I interpret
> it the way it's used in the groff manpage, that is, as a way of saying
> "end the page and start a new one". In contrast, 'line break' means
> "end the line and start a new one". The way `bp` works is it ends line
> & page if it's called with a regular control character, and ends only
> the page if it's called with the no-break control character. Given
> that both of these requests are described as breaking the page in the
> manpage, I expect both of them to behave in the same way.

The description of `ne` in groff(7) could be deficient.  The document
does try to caution the reader of this:

Request short reference
   Not all details of request behavior are outlined here.  See the
   groff Texinfo manual or, for features new to GNU troff,
   groff_diff(7).

I haven't done a brutal red-teaming of these request summaries for a few
reasons.

1.  It's a big job.

2.  People who love this sort of short [sic] reference tend to love CSTR
#54 even more, to the point that some regard it as superior to any
groff documentation past, present, and future.  It's impossible to
win with that latter subset of people, so we get no suggestions for
correction/revision of the man page in that respect.

3.  Some day, groff(7) will have sections and subsections corresponding
to more or less every node in chapter 5 of our Texinfo manual, so
the summaries will be less susceptible to being read as the whole
story.  Every 12-18 months Larry McVoy shows up to ask why we
haven't rewritten our Texinfo manual using a groff macro package
yet.  I've offered an answer, which to date has not elicited an
expression of satisfaction from him: "I'm workin' on it."  I observe
that CSTR #54, the gold standard, is characterized in _Unix Text
Processing_, another esteemed text, as "original" and
"authoritative" but also "dense": maybe some gold doesn't glitter.

At any rate, CSTR #54 does little that can't be accomplished in a
man page.  Prior to the "Tutorial Examples" section, which is
canonically inappropriate for "reference, not tutorial" man pages,
it employs a footnote only once and multiple columnation not at all.

Consequently, I think it's reasonable to provide groff's equivalent
of CSTR #54 as a man page.

I therefore eagerly solicit your suggestion for how the summary of `ne`
in groff(7) can be request to accurately document its present behavior.

That's not a substitute for reforming its behavior, but a bug fix for
the man page in its current form.

> > [...]
> > > It's obvious here that 'bp breaks page IMMEDIATELY,
> >
> > It doesn't.  It _schedules_ (or enqueues) a page break to occur when
> > the next (line) break does, causing the line to be set on the next
> > page.
> 
> Um, what?
> 
> > As with the phrase "prior to output", you and I seem to have
> > strongly divergent interpretations of certain phrases.
> 
> Agreed.
> 
> > > The difference between .bp and 'bp is that one also breaks the
> > > pending input line and the other does not, NOT that the latter
> > > schedules page break after next line break.
> >
> > This statement is unintelligible to me.  You appear to be
> > contradicting the Aristotelian law of identity.
> 
> Well, likewise for your statements above.

In situations like these it is often useful to enlist a third party as
mediator/interpreter.  Perhaps they can help us find a common language.

> Uh. The limiting principle is that the request's description claims it
> breaks the page.
>   $ man 7 groff | grep -Ei '^ *\..*break.*page'
>   .bp   Break page and start a new one.
>   .bp ±NBreak page, starting a new one numbered ±N.
>   .ne   Break page if distance to next page location trap is less
>   .ne d Break page if distance to next page location trap is less

See above.  You're giving the deliberately terse description in "Request
short reference" more weight than perhaps it can bear.

> Just a friendly reminder that it was also your "frustrated intuition"
> before you somehow decided that it's not a bug, but a feature.

Sure.  Sometimes my frustrated intuitions are resolved by fixing bugs,
and sometimes by improving my understanding.

> > The disruptive aspect is that anyone relying on the existing
> > behavior (and not rendering in compatibility mode) would have to
> > alter their documents to make the

Re: Differences in `ne` and `bp` line-breaking behavior

[G. Branden Robinson]

At 2024-12-02T05:15:36+0100, onf wrote:
> page break = end line, end page
[...]
> page break = end page
> 
> Please correct me if I'm wrong.

I don't think we're to the point yet where I can say you're right or
wrong.

> Consulting the web, a 'page break' is variously defined as one of:
>   start of a new page
>   end of a page
>   end a page without filling it with text
>   end the current page and begin the next
> 
> I think the core of the problem lies in the fact that neither of us
> distinguished between a soft and hard page break.
> 
> I realize my usage hasn't been entirely consistent either, because
> a "hard" page break (.bp) implies a line break to me, and so I
> sometimes expected 'page break' to imply a line break and sometimes
> not, just as you seem to have.
> 
> Consulting the web, a 'hard page break' is defined as variations on:
>   The hard page break puts the next word at the top of a new page.
> 
> Whereas a soft page break is described as:
>"Soft" page breaks are created by word processing and report
>programs based on the current page length setting.
> 
> When I read "break page" in the manpage, I expect it to mean a hard
> page break, because a soft page break is automatically inserted when
> the text exceeds page length. I expect .ne to emit a hard page break
> for the same reason.
> 
> Hopefully we are on the same page now. (Pun somewhat intended.)

Maybe not, but we're getting there.  Let me throw in this wrinkle.

There's a distinction between page _ejection_ and commencement of a new
one.  I turn again to our Texinfo manual.  This is language that
originates with me, so please read it critically and point out
ambiguities.

---snip---
   Vertical spacing has an impact on page-breaking decisions.
Generally, when a break occurs, the formatter moves the drawing position
to the next text baseline automatically.  If the formatter were already
writing to the last line that would fit on the page, advancing by one
vee would place the next text baseline off the page.  Rather than let
that happen, 'roff' formatters instruct the output driver to eject the
page, start a new one, and again set the drawing position to one vee
below the page top; this is a "page break".

   When the last line of input text corresponds to the last output line
that fits on the page, the break caused by the end of input will also
break the page, producing a useless blank one.  Macro packages keep
users from having to confront this difficulty by setting "traps" (*note
Traps::); moreover, all but the simplest page layouts tend to have
headers and footers, or at least bear vertical margins of at least one
vee.
---end snip---

I would argue that a roff formatter doesn't really expose page ejection
as an atomic primitive.  To undertake any further typesetting
operations, a new page must begin after an ejection.  But, when there is
no more input to read, there will be no further typesetting operations,
and ejection should _not_ be followed by commencement of a new page.

Where I've encountered this point rubbing a bit is when issuing `ne`
requests that demand exactly as much space as remains before the next
page location trap.  If you get this wrong, you can wastefully forfeit
the use of the last line of formattable body text on the page.

I'll grant that some hair-splitting examples in our Texinfo manual would
probably be helpful here.

Ranging a bit further afield, the ms(7), mm(7), and doc-old packages
define their paragraphing macros to `ne` 2v as a matter of course.

This means that, with any of those packages, if you start a one-line
paragraph at the last usable line of body text on the page, it will be
deferred to the next page even though it would fit.  The paragraphing
macro doesn't know at the time that it's called that you'll have such a
short one.  This seems like an intentional compromise to avoid stranding
a line in the more common case of paragraphs longer than 2 lines.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Differences in `ne` and `bp` line-breaking behavior

[onf]

On Mon Dec 2, 2024 at 5:54 AM CET, G. Branden Robinson wrote:
> At 2024-12-01T22:17:47-0600, Dave Kemper wrote:
> > On Sun, Dec 1, 2024 at 8:27 PM G. Branden Robinson
> >  wrote:
> > > By contrast, your sample size for `ne` misuse is one--yourself.
> > > Formerly two, before I came to understand the request.
> > 
> > Well, I agree with onf's point that .ne's behavior defies user
> > expectation, so you can lump me in with that sample.
>
> Well, maybe mine too.  This one surprised me:
>
> $ printf 'Hello, world!\n.bp\n.c2 @\none two three\nfour five six\n@bp\nseven 
> eight nine\n.br\nten eleven twelve\n' | groff -a
> 
> Hello, world!
> 
> 
> one two three four five six seven eight nine
> ten eleven twelve
>
> I wasn't expecting TWO page breaks there.  But I've got 'em.  Is that
> wrong?  I'm not sure.

I was expecting them there. In fact, what I wasn't expecting when I
began using troff is for multiple .bp requests to be 'squeezed' into
one. This becomes really annoying when trying to pad the end of a
booklet with blank pages (which is necessary for imposition onto a
larger paper format), for instance. In fact, I thought that putting
some vertical space and \& after a .bp makes troff not squeeze the
following .bp, but I fail to bring this behavior about with nroff.
I am consoled by the discovery that 'bp apparently doesn't do that.

Does anyone know what's the rationale behind multiple .bp requests
being squeezed?

> > This is at best a tangential point: roff is used for plenty of things
> > besides man pages.
>
> Not at best tangential--man pages are the _predominant_ application of
> roff in publicly available documents.  That matters.

That doesn't necessarily mean groff should base its behavior on the
expectations of manpage writers, though.

> > I'd rather ask, does it make the language easier to grasp / more
> > intuitive without introducing incompatibilities that will break
> > historical usage?
>
> You state the criterion well, expressing the concerns we must balance.

So far our discussions have been more about the former, though.
You asserted that the current behavior is correct and my intuition
incorrect. You also asserted I am the only person who expects `ne`
to behave in this way.

~ onf

Re: stumped on a simple autoconf/m4/sh problem

[Jacob Bachmeyer]

On 12/1/24 21:03, G. Branden Robinson wrote:

[...]

So the "good tr" branch is being taken in the configure script, but not
in vivo at a shell prompt.  I can't explain this.


First question:  what shell is configure actually running under?

Autoconf makes an effort to find a plausible POSIX shell, and /bin/sh on 
Solaris 10 is not it.  The copy of bash-3.2 you used for interactive 
testing was probably not it either.  I seem to recall that grepping 
config.status for CONFIG_SHELL should tell you.


Off the top of my head, try `CONFIG_SHELL=/full/name/of/bash-3.2 
configure` and see if the test works.



Would someone kindly point out my rookie mistake?
I am not so certain that this is exactly a rookie mistake---it looks 
like you may have uncovered a shell bug, but in which shell?



-- Jacob

Re: Differences in `ne` and `bp` line-breaking behavior

[onf]

On Mon Dec 2, 2024 at 3:26 AM CET, G. Branden Robinson wrote:
> [...]
> >   $ nroff << EOF | sed -E 's/^/./'
> >   .pl 3
> >   .fi
> >   One two three
> >   four five six
> >   'bp
> >   seven eight nine
> >   .br
> >   eleven twelve.
> >   EOF
> > output:
> >   .
> >   .
> >   .
> >   .One two three four five six seven eight nine
> >   .eleven twelve.
> >   .
> > 
> > It's obvious here that 'bp breaks page IMMEDIATELY, not when the .br
>
> Eh?
>
> If it broke the page "IMMEDIATELY", you'd get this:
>
> One two three four five six
> 
> seven eight nine eleven twelve.
> [...]

No, you wouldn't, because that line is still pending.
We seem to interpret the word 'page break' differently.
I interpret it the way it's used in the groff manpage, that is,
as a way of saying "end the page and start a new one". In contrast,
'line break' means "end the line and start a new one". The way `bp`
works is it ends line & page if it's called with a regular control
character, and ends only the page if it's called with the no-break
control character. Given that both of these requests are described
as breaking the page in the manpage, I expect both of them to behave
in the same way.

> [...]
> > It's obvious here that 'bp breaks page IMMEDIATELY,
>
> It doesn't.  It _schedules_ (or enqueues) a page break to occur when the
> next (line) break does, causing the line to be set on the next page.

Um, what?

> As with the phrase "prior to output", you and I seem to have strongly
> divergent interpretations of certain phrases.

Agreed.

> > The difference between .bp and 'bp is that one also breaks the pending
> > input line and the other does not, NOT that the latter schedules page
> > break after next line break.
>
> This statement is unintelligible to me.  You appear to be contradicting
> the Aristotelian law of identity.

Well, likewise for your statements above.

> > My proposal seeks to make `ne`'s behavior consistent with that of
> > `bp`.
>
> Looking over the request list, why not have `cu` or `ev` imply breaks as
> well?  Or `hy`?  Why not `ft` and `ps`?  What's the limiting principle?

Uh. The limiting principle is that the request's description claims it
breaks the page.
  $ man 7 groff | grep -Ei '^ *\..*break.*page'
  .bp   Break page and start a new one.
  .bp ±NBreak page, starting a new one numbered ±N.
  .ne   Break page if distance to next page location trap is less
  .ne d Break page if distance to next page location trap is less

> > Please explain how, given the following descriptions from groff(7):
> >   .bp   Break page and start a new one.
> >   .ne d Break page if distance to next page location trap is less
> > than distance d (default scaling unit v).
> > 
> > is it not reasonable to expect these two lines to behave similarly:
> >   .ne 3v
> >   .if \n[.t]u<3v .bp
> > 
> > ... because they don't.
>
> Maybe one of the *roff veterans on the list can challenge your
> frustrated intuition here.  I don't seem to be making any headway.

Just a friendly reminder that it was also your "frustrated intuition"
before you somehow decided that it's not a bug, but a feature.

> [...]
> > As I explained in the part you quoted above, that is not the case.
> > `ne` would still behave as it does now if called with the no-break
> > control character (i.e. 'ne).
>
> The disruptive aspect is that anyone relying on the existing behavior
> (and not rendering in compatibility mode) would have to alter their
> documents to make the appropriate change.

Yes. I think I said that in the first message of this thread?

> That's not forbidden.  We can cross Rubicons.  The "NEWS" file documents
> these.  But a change needs to pay its freight.  As far as I know you're
> the only person in the world who's ever been this upset by the behavior
> of `ne`.  (You can't include me despite my documented confusion with the
> request, because I did not undertake a similar reform immediately
> myself, as I would have if I was certain I was right.  Instead I decided
> I didn't sufficiently understand what was going on with the formatter.
> [...]

I haven't been "this upset" by the behavior of `ne`. I was just puzzled
for a while before I realized it behaves differently than `bp`, which
lead me to file the bug.

On the other hand, I must admit I am frustrated by your replies on the
topic.

> > I see no reason to change the behavior in compatibility mode, I just
> > forgot about it. We can simply add this to the proposal:
> >   3. `ne` does not break line in compatibility mode
> > 
> > To summarize, `ne` would break line if
> >   a) in compatibility mode
> >   b) not in compatibility mode and called with the regular control
> >  character
>
> I'm not convinced.  I reiterate:
>
> "Part of my motivation for reforming/revising adjustment management is
> that I see people mis-applying the existing language feature."
>
> Show me exhibits of people besides yourself making the same mistake with
> `ne`.

When I beg

Re: Differences in `ne` and `bp` line-breaking behavior

[onf]

Reading your message for at least the third time, I conclude that:

On Mon Dec 2, 2024 at 3:26 AM CET, G. Branden Robinson wrote:
> [...]
> >   $ nroff << EOF | sed -E 's/^/./'
> >   .pl 3
> >   .fi
> >   One two three
> >   four five six
> >   'bp
> >   seven eight nine
> >   .br
> >   eleven twelve.
> >   EOF
> > output:
> >   .
> >   .
> >   .
> >   .One two three four five six seven eight nine
> >   .eleven twelve.
> >   .
> > 
> > It's obvious here that 'bp breaks page IMMEDIATELY, not when the .br
>
> Eh?
>
> If it broke the page "IMMEDIATELY", you'd get this:
>
> One two three four five six
> 
> seven eight nine eleven twelve.

page break = end line, end page

> [...]
> > It's obvious here that 'bp breaks page IMMEDIATELY,
>
> It doesn't.  It _schedules_ (or enqueues) a page break to occur when the
> next (line) break does, causing the line to be set on the next page.

page break = end page

Please correct me if I'm wrong.

Consulting the web, a 'page break' is variously defined as one of:
  start of a new page
  end of a page
  end a page without filling it with text
  end the current page and begin the next

I think the core of the problem lies in the fact that neither of us
distinguished between a soft and hard page break.

I realize my usage hasn't been entirely consistent either, because
a "hard" page break (.bp) implies a line break to me, and so I
sometimes expected 'page break' to imply a line break and sometimes
not, just as you seem to have.

Consulting the web, a 'hard page break' is defined as variations on:
  The hard page break puts the next word at the top of a new page.

Whereas a soft page break is described as:
   "Soft" page breaks are created by word processing and report
   programs based on the current page length setting.

When I read "break page" in the manpage, I expect it to mean a hard
page break, because a soft page break is automatically inserted when
the text exceeds page length. I expect .ne to emit a hard page break
for the same reason.

Hopefully we are on the same page now. (Pun somewhat intended.)

~ onf

Re: Differences in `ne` and `bp` line-breaking behavior

[onf]

Hi Branden,

On Mon Dec 2, 2024 at 5:27 AM CET, G. Branden Robinson wrote:
> At 2024-12-02T04:45:27+0100, onf wrote:
> > We seem to interpret the word 'page break' differently.  I interpret
> > it the way it's used in the groff manpage, that is, as a way of saying
> > "end the page and start a new one". In contrast, 'line break' means
> > "end the line and start a new one". [...]
>
> The description of `ne` in groff(7) could be deficient.  The document
> does try to caution the reader of this:
> [...]
>
> I haven't done a brutal red-teaming of these request summaries for a few
> reasons.
> [...]
> 2.  People who love this sort of short [sic] reference tend to love CSTR
> #54 even more, to the point that some regard it as superior to any
> groff documentation past, present, and future.  It's impossible to
> win with that latter subset of people, so we get no suggestions for
> correction/revision of the man page in that respect.

I happen to not be in that camp. I tend to use manpages as my primary
reference because they fit well with my terminal-focused workflow.
This is no different with groff. When the quality of a groff manpage
is lacking, I turn to other troffs' manpages before looking up other
sources. This is especially true for tbl and eqn, where I usually
consult the respective BSD mandoc manpage first.
(groff's tbl is too wordy and eqn assumes one already knows the
language)

> [...]
> Consequently, I think it's reasonable to provide groff's equivalent
> of CSTR #54 as a man page.

Unfortunately, CSTR #54's description of .ne is merely more terse.
It doesn't explain the topic much better.

> I therefore eagerly solicit your suggestion for how the summary of `ne`
> in groff(7) can be request to accurately document its present behavior.
>
> That's not a substitute for reforming its behavior, but a bug fix for
> the man page in its current form.

Fair enough.

> [...]
> > I haven't been "this upset" by the behavior of `ne`. I was just
> > puzzled for a while before I realized it behaves differently than
> > `bp`, which lead me to file the bug.
>
> You seem to me to be going at the matter pretty gung-ho, from which I
> inferred emotional investment.  I concede that I may be mistaken there.

You aren't mistaken about emotions being present, but about their
source. I generally tend to react this way whenever someone disagrees
with me about something which I perceive as "obviously true".

Granted, these "obviously true" things are often those that have
some emotional value to me, but I am pretty sure I would react
similarly if I was talking to someone and they believed that an
object which I see as red is yellow and I couldn't talk them out
of it.

Our current disagreement has been closer to that last example,
although I can't deny I would be somewhat glad if `ne`'s behavior
changed the way I suggested.

> [...]
> > When I began using troff, I started with John Ankarstrom's minimalist
> > Mk macro package[1].
>
> It is a hazard of reading a lot of Bakunin/Kropotkin/Berkman/Rocker/
> Chomsky that my brain always and without fail reads his surname as
> "Anarkstrom". [...]

I appreciate your taste.

> > Reading its README.pdf[2] file reveals he thinks
> > `ne` breaks line (page 4):
> >   The w macro is an alternative to troff’s ne request, which ensures
> >   that a given amount of space is available on the page – otherwise,
> >   a line break is issued – but unlike ne, which takes an exact amount
> >   of space as its argument, w takes a declarative specification
> >   describing the amount of desired space in terms of mk environments.
> > 
> > You could argue that it's a typo and he meant to write 'page break'
> > instead of 'line break'.
> > 
> > In any case, his `w` macro, which he himself describes as an
> > "alternative to ... ne" which differs only by "tak[ing] a
> > declarative specification ... of desired space", emulates `ne`
> > by doing this:
> >   .  if (\n(_su)>\n(.tu \{\
> >   .   br
> >   .   bp
> >   .  \}
> > 
> > which clearly indicates he expects such a feature to break line
> > (and doesn't realize .bp does this for him already).
>
> I'm uncertain what he meant.  I'd have to get experience with the
> package, and/or ask him.

Well, I've been using the package for a while now. (Technically
a heavily expanded and modified version I've gradually created.)
He uses `w` in the definitions of headings (`h`) and subheadings
(`s`) to ensure there is enough vertical space for the (sub)heading
and at least a single line of text after it:
  .w h p
where `w` = 'want space', `h` = 'heading', `p` = paragraph,
i.e. want enough space to fit a single line of heading and single
line of a paragraph.

I notice all the instances of `w` are preceded by `br`, but that is
probably because they are followed by an environment switch (`@e`).
`w` breaks line (and page) only if there is not enough space, so
that if there is enough, it would not break a pending input line
before the environm

Re: stumped on a simple autoconf/m4/sh problem

[G. Branden Robinson]

Hi Jacob,

Thanks for the quick response.

At 2024-12-01T23:48:09-0600, Jacob Bachmeyer wrote:
> On 12/1/24 21:03, G. Branden Robinson wrote:
> > [...]
> > 
> > So the "good tr" branch is being taken in the configure script, but not
> > in vivo at a shell prompt.  I can't explain this.
> 
> First question:  what shell is configure actually running under?
> 
> Autoconf makes an effort to find a plausible POSIX shell, and /bin/sh
> on Solaris 10 is not it.  The copy of bash-3.2 you used for
> interactive testing was probably not it either.  I seem to recall that
> grepping config.status for CONFIG_SHELL should tell you.

Here's what I get.

$ grep CONFIG_SHELL config.status
SHELL=${CONFIG_SHELL-/bin/bash}
  $as_echo "running CONFIG_SHELL=/bin/bash $*" >&6
  CONFIG_SHELL='/bin/bash'
  export CONFIG_SHELL

$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2007 Free Software Foundation, Inc.

> Off the top of my head, try `CONFIG_SHELL=/full/name/of/bash-3.2
> configure` and see if the test works.

Okay, I did.  The mystery would appear to deepen.

The same grep gets the same results.

I drive the build from a shell script because building on Solaris 10
_or_ 11 is a headache.  I'm attaching the script.

> > Would someone kindly point out my rookie mistake?
> I am not so certain that this is exactly a rookie mistake---it looks
> like you may have uncovered a shell bug, but in which shell?

I am baffled that bash 3.2 would behave one way interactively and
another when run via configure.  Presumably something else is going on?

Regards,
Branden
#!/bin/sh

export MAKE=make

if [ "$(uname -s)" = SunOS ]
then
  export PATH=/usr/xpg4/bin:$PATH
  export MAKE=$(which gmake)
  export AR=$(which gar)
  if [ "$(uname -r)" = 5.10 ]
  then
#export M4=$(which gm4)
export CONFIG_SHELL=/bin/bash
  fi
fi

gs=absent
urw=absent
urw_dir=/usr/share/fonts/type1/urw-base35

test -f /usr/bin/gs && gs=present
# fontconfig might litter this directory with a .uuid file >:-(
if [ -d $urw_dir ]
then
  count=$(find $urw_dir -type f | wc -l)
  test $count -gt 1 && urw=present
fi

echo SCENARIO: urw $urw, gs $gs

./configure --prefix=$HOME \
 && $MAKE

if [ $? = 0 ]
then
  # Expect test failures on Solaris 10.
  if [ "$(uname -s)" = SunOS ] && [ "$(uname -r)" = 5.10 ]
  then
# Fix up the test scripts to use a POSIX shell.
gsed -i -e '1s@#!/bin/sh@#!/usr/xpg4/bin/sh@' \
  `find . -name '*.sh' | grep /tests/`
$MAKE check
$MAKE install install-doc \
  && $MAKE uninstall \
  && $MAKE distclean
  else
echo GBR: PATH=$PATH
$MAKE check \
  && $MAKE install install-doc \
  && $MAKE uninstall \
  && $MAKE distclean
  fi
fi

list=$(find $HOME/bin $HOME/lib $HOME/share -type f)

if [ -n "$list" ]
then
  echo '*** installation directories are NOT clean (.../info/dir is OK)'
else
  echo '$HOME/{bin,lib,share}' directories are clean
fi


signature.asc
Description: PGP signature

Nested SY/YS

[Alejandro Colomar]

Hi Branden,

I was wondering if it would be good to nest SY/YS.

What do you think of this?:

 .SY void\~*bsearch (
 .BI const\~void\~ key [. size ],
 .BI const\~void\~ base [. size \~*\~. n ],
 .BI size_t\~ n ,
 .BI size_t\~ size ,
 .br
-.BI int\~(* compar )(const\~void\~[. size ],
+.SY int\~(*\f[I]compar\f[]) (
+.BI const\~void\~[. size ],
 .BI const\~void\~[. size ]));
+.YS
 .YS


Which would ideally produce:

   void *bsearch(const void key[.size],
 const void base[.size * .n], size_t n, size_t size,
 int (*compar)(const void [.size],
   const void [.size]));


Cheers,
Alex

-- 



signature.asc
Description: PGP signature

Re: Differences in `ne` and `bp` line-breaking behavior

[G. Branden Robinson]

Hi onf,

At 2024-12-01T23:06:41+0100, onf wrote:
> I have discovered recently that `ne` and `bp` behave differently in
> regards to pending input lines. `bp` breaks such lines, while `ne`
> does not. In practice this means that `ne` does not behave like a
> conditional `bp` as one would reasonably expect. This issue has been
> discussed extensively on groff's bug tracker.[1]
> 
> I propose the following changes to make their behavior consistent:
> 
>  1. `ne` breaks line before breaking the page as `bp` does
>  2. `ne` does not break line before breaking the page if called with
> the no-break control character (which currently doesn't modify
> its behavior in any way)
> 
> The second point means that the old behavior of .ne can be recovered
> via 'ne. This matches the behavior of 'bp, which breaks page without
> breaking the line as well.

I don't agree with this change, because it's not necessary.  Formatter
requests are primitive things.  Most requests don't also perform breaks.
Only a handful do.  Those that do support the no-break control character
to _schedule_ a change to formatter state at the next break, when that
happens for some other reason.

With `ne` in particular, this was a point I had to learn when getting
windows and orphans under control in groff's man pages.  But after a
little while, the light came on.  I added a caveat to our Texinfo manual
about it:

 This method is reliable only if no output line is pending when 'ne'
 is invoked.  When macro packages are used, this is often not the
 case: their paragraphing macros perform the break.  You may need to
 experiment with placing the 'ne' after the paragraphing macro, or
 'br' and 'ne' before it.

...but I now think I can recast that.  There's nothing wrong with or
weird about having a `ne` request when an output line is pending.

> Note that this change would break compatibility with other troff
> implementations. However, it would be easy to fix any documents
> which rely on the current behavior by substituting[2] any .ne
> for 'ne, which, as pointed out above, behaves exactly like .ne
> in other troff implementations.
> 
> I invite anyone who disagrees with this proposal to raise any
> objections they might have, either here or on the bug tracker.

I don't exactly object, but I'm pretty deeply uncertain about it.

And we'd need to retain traditional handling of `ne` for AT&T
compatibility mode, anyway.  If you disagree with that, then I _do_
object.

> [1] https://savannah.gnu.org/bugs/?66447

Regards,
Branden


signature.asc
Description: PGP signature