Follow-up Comment #13, bug #63635 (group groff): At 2025-04-27T18:35:51-0400, anonymous wrote: > [comment #11 comment #11:] >> [comment #10 comment #10:] >>> neatroff's maintainer's opinion is that this change is unnecessary, >>> because one can save the hyphenation mode to a register before >>> disabling it. >> >> Part of my motivation for the new _groff_ feature is that there is no >> portable way to do that. >> >> If one doesn't care about AT&T _troff_ and can presume the >> availability of _groff_'s `.hy` register extension, then that >> approach is fine. >> >> Man pages, for example, can't make that presumption. > > But isn't that the same problem with `hydefault`, which will also be a > groff extension?
No, because of the quirky/surprising meaning of the `hy` request when
given no argument (said meaning being traceable deep into 1970s *roff
history[1]). People, especially man page authors, tend to assume it
means "restore the previous hyphenation mode", just like `ft` and `ps`
without arguments restore the previous font selection and type size,
respectively.
But it doesn't. (I'd agree with anyone who argued that it should have,
but this opportunity was squandered 50 years ago.) `hy` without an
argument restores the "default" hyphenation mode, which in AT&T troff is
"1". groff maintained "compatibility" with this behavior even though it
was no help in producing identical automatic hyphenation breaks (the
hyphenation systems and patterns are strongly dissimilar). In defense
of groff to date, discarding this aspect of portability for some other
behavior raises the question of _what_ the new behavior _should_ be, an
issue not heretofore addressed. This is my crack at it.
The new `hydefault` request (1) permits language localization macro
files to configure a default automatic hyphenation mode that congrues
with the expectations of the corresponding language-specific hyphenation
patterns and (2) gives the groff installation the ability to configure
the default hyphenation mode on a per-environment basis. While this
power _could_ futhermore be exercised by a *roff document,[2] the
envisioned use case is in a site configuration file like "troffrc",
"man.local", or "mdoc.local", so that the machine administrator can
configure hyphenation to their preference.
So in this scenario, it doesn't matter that the extension is not
exercisable portably in a man page. Indeed, such exercise would largely
defeat the purpose, though I know some man page authors have a stronger
desire to impose their formatting preferences on the reader than they do
to compose a man page that is adaptable to the _reader's_ preferences.
As the "NEWS" file says:
* A new request, `hydefault`, and read-only register, `.hydefault`,
manage the default automatic hyphenation mode of an environment.
This resolves a long-standing problem of *roff formatting.
When processing input like this,
.nh
and we temporarily shut off automatic hyphenation,
.hy
the foregoing request would not do exactly what we expect.
AT&T and other troffs apply a hyphenation mode of 1 to the final
input line (and subsequent ones), rather than restoring the mode in
use before the `nh` request. Apart from overturning user
expectations, for GNU troff "1" is not an appropriate mode for its
English hyphenation patterns. (For example, "alibi" would break as
"ali-bi" instead of "al-ibi" after this argumentless `hy`
invocation.) With updates to groff's localization files accompanying
this release, the foregoing input now works as desired.
Adjustment suffers from a similar problem; see bug #65954.
> (By the way, neatroff also has register `.hy`.)
Yes. That's immaterial to the problem I tried to solve with
`hydefault`.
[1] See, for example, PWB/UNIX 1.0 sources, which predate Seventh
Edition Unix (1979).
https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s7/croff/n5.c
casehy(){
register i;
hyf = 1;
if(skip())return;
noscale++;
i = atoi();
noscale = 0;
if(nonumb)return;
hyf = max(i,0);
}
[2] A (non-man-page) document that otherwise employs automatic
hyphenation might want create and use an environment to shut it off,
perhaps to quote a passage in a foreign language that groff doesn't
support.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63635>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
