gbranden pushed a commit to branch master
in repository groff.
commit b94a52e559a1a6db8aba5b165b0bef29694bed68
Author: G. Branden Robinson <[email protected]>
AuthorDate: Sat Apr 25 17:59:54 2026 -0500
ChangeLog: Add info to old entries.
---
ChangeLog | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 6160992fd..e5f9f0bd2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -3,10 +3,11 @@
* tmac/an.tmac (SH, SS, TP): Throw warning if macro called while
an input trap is pending (for example, `.TP` followed
immediately by `.SH`). This input is not specified or
- countenanced by any man(7) documentation I know of, and produces
- unpredictable output across implementations. (Given the
- foregoing example, Plan 9 troff truncates the input at that
- point.) Seen in the wild in fvwm-config(1).
+ countenanced by any man(7) documentation I know of, mandoc(1)'s
+ "-T lint" warns about it, and it produces unpredictable output
+ across implementations. (Given the foregoing example, Plan 9
+ troff truncates the input at that point.) Seen in the wild in
+ fvwm-config(1).
Fixes <https://savannah.gnu.org/bugs/?68279>.
@@ -1264,14 +1265,16 @@
character '-' is also valid, since it marks a hyphenation point.
Consequently, we now throw a warning in category "char" on
attempted hyphenation exception words like "non*sense" and
- "0123456789". Drop later conditional loop break if the
- hyphenation code is zero since that now cannot be the case--we
- now don't enter the containing branch in the first place.
- Replace a test of the index into the hyphenation exception word
- being greater than zero with an assert(3)ion of the same inside
- the branch, as it's now an invariant that a valid hyphenation
- exception word contains a nonzero count of characters bearing
- hyphenation codes.
+ "0123456789". (You can still make these eligible for
+ hyphenation breaking by using the `hcode` request to assign
+ hyphenation codes to non-letters.) Drop later conditional loop
+ break if the hyphenation code is zero since that now cannot be
+ the case--we now don't enter the containing branch in the first
+ place. Replace a test of the index into the hyphenation
+ exception word being greater than zero with an assert(3)ion of
+ the same inside the branch, as it's now an invariant that a
+ valid hyphenation exception word contains a nonzero count of
+ characters bearing hyphenation codes.
* doc/groff.texi.in (Warnings):
* src/roff/troff/troff.1.man (Warnings): Document new warning
@@ -2396,7 +2399,8 @@
use its stored length to decide when to stop instead of relying
on the `string_iterator` accessing each element to return an
`EOF` character. This change prepares for a future where GNU
- troff's internal character type does not encode `EOF`. This
+ troff's internal character type might not encode `EOF` (at least
+ not in the same way that the C standard I/O library does). This
change also weakens the resemblance of file and string
iterators, but that seems acceptable to me, because string and
macro contents have already undergone input processing. In the
_______________________________________________
groff-commit mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/groff-commit
