Update of bug #66803 (group groff):
Status: None => Confirmed
Assigned to: None => gbranden
_______________________________________________________
Follow-up Comment #1:
[comment #0 original submission:]
> [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=493a01c02 Commit
> 493a01c02] (among other changes) changed the documentation of .hw slightly,
> to say the specified hyphenation exceptions are "associated with the ...
> environment." This does not appear to be accurate.
You're right, and furthermore we now have `phw`, a facility lacking in 2020,
to more directly inquire about such things.
$ cat EXPERIMENTS/66803-hw-and-environment.groff
.ll 1p
1. facilitate
.tm user-defined hyphenation of "facilitate" in environment \n[.ev]:
.phw
.hw fac-ilit-ate
.tm user-defined hyphenation of "facilitate" in environment \n[.ev]:
.phw
2. facilitate
.ev new
.tm user-defined hyphenation of "facilitate" in environment \n[.ev]:
.phw
.ll 1p
3. facilitate
.pl \n[nl]u
$ ./build/test-groff -Wbreak -z EXPERIMENTS/66803-hw-and-environment.groff
2>&1 | grep fac
user-defined hyphenation of "facilitate" in environment 0:
user-defined hyphenation of "facilitate" in environment 0:
fac-ilit-ate
user-defined hyphenation of "facilitate" in environment new:
fac-ilit-ate
> This commit similarly made the manual claim that .hla is associated with the
> environment, which we know from the brouhaha around bug #66387 was never
> historically the case.
Hmm, yeah, your (correct) observation perceives additional chaos regarding
whether hyphenation parameters are global or environmental.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66803>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
