Follow-up Comment #2, bug #68708 (group groff): Hi Ingo,
At 2026-09-19T17:50:55-0400, Ingo Schwarze wrote:
> Follow-up Comment #1, bug #68708 (group groff):
>
> I consider it useful that arguments of .No are _not_ hyphenated.
Hmm. I lean the other way.
Here's what documentation has to say about this macro.
groff_mdoc(7):
Normal text macro
‘No’ formats subsequent argument(s) normally, ending the effect of
‘Em’ and similar. Parsing is not suppressed, so you must prefix
words like ‘No’ with ‘\&’ to avoid their interpretation as mdoc
macros.
Usage: .No argument ...
.Em Use caution No here . → Use caution here.
.Em No dogs allowed . → No dogs allowed.
.Em \&No dogs allowed . → No dogs allowed.
The default width is 12n.
mandoc_mdoc(7):
Physical markup
Em italic font or underline (emphasis) (>0 arguments)
Sy boldface font (symbolic) (>0 arguments)
No return to roman font (normal) (>0 arguments)
...
No word ...
Normal text. Closes the scope of any preceding in‐line macro.
When used after physical formatting macros like Em or Sy,
switches back to the standard font face and weight. Can also
be used to embed plain text strings in macro lines using
semantic annotation macros.
Examples:
.Em italic , Sy bold , No and roman
.Sm off
.Cm :C No / Ar pattern No / Ar replacement No /
.Sm on
See also Em, Ql, and Sy.
So neither of these projects--the only ones in the world that interpret
the mdoc(7) language, as far as I know--explicitly addresses the
interaction of `No` with hyphenation.
My argument would be that `No` is described as formatting text
"normally", and since, in _groff_, text is _normally_ subject to
automatic hyphenation (unless deconfigured by the user with `-r HY=0` or
an analogous change to the "mdoc.local" file), so too should the
arguments to the `No` macro.
It's fair to ask why one would ever use `No` for the purpose of
recovering automatic hyphenation when one could just break the input
line and write a _roff_ text line.
That's a good question, but its scope swiftly escapes from the enclosure
of automatic hyphenation.
> To understand why, consider how the No macro is typically used. While
> in man(7), macros are typically used stand-alone, in mdoc(7) code, it
> is very common to form groups of macros, marking individual parts of
> larger expressions or chunks of text with their respective semantic
> roles.
Yes, but "semantics" can have varying implications for automatic
hyphenation. A URL should not be hyphenated, but the link text can be.
Similarly, Guillem Jover was right to be incensed that function names
given as arguments to `Fn` should not be subject to hyphenation.
> That is where the .No macro is normally used, it is almost never used
> stand-alone in practice.
>
> Specifically, the .No and .Ns macros are typically used when, in the
> middle of a larger expression or chunk of text where most words or
> parts are marked up with a semantic function, one word or a few words
> occur that should specifically *not* be marked up - but that does
> *not* mean that in the middle of such a larger expression (often an
> in-line syntax display) you suddenly want individual words hyphenated,
> not even when they happen to be normal English words.
Yes, I see the existence of `No` and `Ns` as, probably, a necessary
consequence of mdoc(7)'s bespoke macro processing system. Among its
several other objectives, it was apparently designed to keep the user
from ever having to type the `\c` escape sequence. But because `\c`
was present in the *roff language for a reason, mdoc(7) ended up having
to give the author a means of saying, roughly, "pretend there's no macro
here" and "pretend macro arguments don't have to be separated by
spaces". The latter would have been mightily tedious for punctuation
attachment, so the macro package parses arguments and makes a special
decision of the argument appears to be an item of punctuation.
I say again, it looks to me for all the world like mdoc(7) was designed
to be lifted free of *roff and set down on top of a completely different
formatting system. I'll bet the BSDI founders who were, I suspect, hell
bent on keeping groff out of their product did not think it would take
thirty years for that completely different formatting system to
materialize.
I wonder who I can blame for this spite-driven engineering management.
I wonder if it was McKusick.
J'McKuse!
> They are so few and far between that i only found a single one, which
> is in ksh(1):
>
> The following parameters are set and/or used by the shell:
> .Bl -tag -width "EXECSHELL"
> .It Ev _ No (underscore)
> When an external command is executed by the shell, this parameter is set ...
>
> You certainly wouldn't want the "(under-
> score)" in the item head hyphenated.
No real hazard of that here. The minimum practical line length for a
man page is 65n,[1] and list items always break the line first.
Here, let me experiment with the mdoc macros for a moment, as I'm not
nearly as familiar with them as I am with the man(7) package.
$ printf '.Dd 2026-09-20\n.Dt foo 1\n.Os\n.Bl -tag -width "fnord"\n.It
foo\nstuff\n.It bar baz\nmore stuff\n.El' | nroff -r LL=72n -mdoc
foo(1) General Commands Manual foo(1)
foo stuff
bar baz
more stuff
GNU 2026‐09‐20 foo(1)
I think it's more likely the ksh(1) author didn't want "(underscore)"
_italicized_. That is after all the first thing you tell people about
the `No` macro in the documentation.
mandoc_mdoc(7):
Physical markup
Em italic font or underline (emphasis) (>0 arguments)
Sy boldface font (symbolic) (>0 arguments)
No return to roman font (normal) (>0 arguments)
However, I won't be surprised if you disagree, because I notice a
groff/mandoc discrepancy.
Here is a sample input:
$ cat ./ATTIC/altksh.mdoc
.Dd 2026-09-26
.Dt ksh 1
.Os "fake Korn shell"
.Sh Name
.Nm ksh
.Nd a fake Korn shell man page
.Sh Description
The following parameters are set and/or used by the shell:
.Bl -tag -width "EXECSHELL"
.It Ev _ (underscore)
When an external command is executed by the shell,
this parameter is set.
.El
$ nroff -dAD=l -rLL=72n -mandoc ./ATTIC/altksh.mdoc
ksh(1) General Commands Manual ksh(1)
Name
ksh —— a fake Korn shell man page
Description
The following parameters are set and/or used by the shell:
_ (underscore)
When an external command is executed by the shell, this
parameter is set.
fake Korn shell 2026‐09‐26 ksh(1)
$ mandoc -O width=72 ./ATTIC/altksh.mdoc | ul
ksh(1) General Commands Manual ksh(1)
Name
ksh – a fake Korn shell man page
Description
The following parameters are set and/or used by the shell:
_ (underscore)
When an external command is executed by the shell, this
parameter is set.
fake Korn shell 2026-09-26 fake Korn shell
While font changes are lost here, _groff_ italicizes "(underscore)".
_mandoc_ does not. Guess I need to look up the specification of `Ev`.
groff_mdoc(7) says, essentially, that it sets "an" environment variable.
mandoc_man(7) says much more, but still doesn't get across to me clearly
that, while it clearly accepts multiple arguments, whether the
"semantics" apply to _all_ non-punctuation, non-macro arguments, or just
the first. For that matter, I don't know if punctuation arguments
terminate a "semantic scope". If I had to guess, I'd expect so.
Perhaps you can tell me where mandoc_mdoc(7) spells out these matters.
> The vast majority of .No macros do not contain a word long enough to
> be hyphenated, anyway. Consequently, for well above 99% of .No
> macros, the question is moot in the first place.
I agree. But that makes it harder to use the world's mdoc documents to
decide this question.
Anyway, I don't expect to be able to move on this issue soon even if I
do decide on reform. Addressing it means having to more deeply
understand groff mdoc's internal macro parsing system, the comments of
which use the term "string" in a deeply confusing way.
Sometimes it's a *roff string, and sometimes it's not.
<Borat double thumbs-up gesture>
Regards,
Branden
[1] Man page authors already struggle with the necessity of using _tbl_
text blocks when the line length is 80 ens, and frequently,
blithely overset a line of that length in their ignorance. Ratchet
the length down to 65n and you'll see even more problems. Going
below that isn't practical, as even expertly composed historical
man pages that use _tbl_ will go wrong.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68708>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
