[bug #63176] [me] After column-count changes, -me might place running text on page below footnote

2024-07-31 Thread G. Branden Robinson
Follow-up Comment #9, bug #63176 (group groff):


> But some of the running text landing _below_ the footnote suggests something
is interfering with this order of events.

Having *just* seen this *exact* problem while fiddling with and verifying the
function of the "hdfo.roff" example in our Texinfo manual, this might be
because a trap macro has forgotten to invoke a request with the no-break
control character.

Words from a partially collected line will spurt out like mustard if, inside
trap-called macros, one isn't careful with requests that imply breaks.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66033] [devps] support "maintainer-mode" regeneration of font descriptions

2024-07-31 Thread G. Branden Robinson
Update of bug #66033 (group groff):

 Summary: generate grops fonts during a groff build => [devps]
support "maintainer-mode" regeneration of font descriptions

___

Follow-up Comment #1:

Revising summary.

This isn't something we can do in just _any_ build without extending our build
dependencies to include now-archaic collections of Adobe Type 1 fonts, which
are not Free Software.

Font _metrics_, which are all we care about from these collections, are simple
numeric descriptions of coarse properties of glyphs in a font, and are not
copyrightable.

In theory someone could extract the metrics from the 2 Type 1 collections we
require (see section "Old fonts" of _grops_(1)), and ship those, but I don't
personally see the point since they will seldom change.  Better just to make
this part of the boxes-to-tick list of items in our
[https://git.savannah.gnu.org/cgit/groff.git/tree/FOR-RELEASE FOR-RELEASE
file].

Odds are, once we've got the procedure documented and tested, we'll never,
ever have to do it again.  (Adobe has retired the Type 1 format.)

The Unicode Consortium will keep us busier.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66038] [troff] want "invalid line length" diagnostic to not misrepresent user input

2024-07-31 Thread G. Branden Robinson
Update of bug #66038 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.24.0 

___

Follow-up Comment #7:


commit 93d264070da6fff3f78c3831032eeba46aeeb2aa
Author: G. Branden Robinson 
Date:   Tue Jul 30 21:40:44 2024 -0500

[troff]: Fix Savannah #66038 ("computed" lengths).

* src/roff/troff/div.cpp (page_length):
* src/roff/troff/env.cpp (line_length, title_length): Tweak diagnostic
  to say "computed" rather than "invalid", because while the value we're
  complaining about _is_ invalid, it is also a numeric expression that
  may have traveled a great distance through the alimentary canal of GNU
  troff's arithmetic evaluator, and bear little resemblance to what the
  user typed in a source document.  Among other things, we no longer
  have any idea what scaling units were supplied, but can report them
  only in basic units.

Fixes <https://savannah.gnu.org/bugs/?66038>.  Thanks to Dave Kemper for
the report.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66038>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66040] [troff] no longer warns about unrecognized .hcode input

2024-07-31 Thread G. Branden Robinson
Update of bug #66040 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.24.0 

___

Follow-up Comment #12:


commit c34502070b1374cceec484b0b825f80ab8d812bf
Author: G. Branden Robinson 
Date:   Mon Jul 29 23:11:11 2024 -0500

[troff]: Fix Savannah #66040 (`hcode` & `\[xxx]`).

* src/roff/troff/input.cpp (set_hyphenation_code): Restore diagnostic
  message when attempting to assigning the hyphenation code of a special
  character to another character (special or ordinary).  Also initialize
  local variable much closer to where we test its value, for
  readability.

Fixes <https://savannah.gnu.org/bugs/?66040>.  Thanks to Dave Kemper for
the report.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66040>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[groff] 08/14: doc/groff.texi.in: Clarify comment on comment.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 676a1b7b32a1355ede22e2d29e2ada1dc7156dae
Author: G. Branden Robinson 
AuthorDate: Fri Jul 26 14:27:41 2024 -0500

doc/groff.texi.in: Clarify comment on comment.

...for the benefit of people reading this sentence in isolation.
---
 doc/groff.texi.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 127828f2e..ec719402a 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -7429,8 +7429,8 @@ nor between arguments.
 
 @cindex undefined request
 @cindex request, undefined
-A comment on a line by itself is treated as a blank line, because after
-eliminating the comment, that is all that remains.
+A @code{\"} comment on a line by itself is treated as a blank line,
+because after eliminating the comment, that is all that remains.
 
 @Example
 Test

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 05/14: [docs]: Clarify mention of refer(1) behavior.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 6bc634938436132cfbd8e21f40634b498bb3d465
Author: G. Branden Robinson 
AuthorDate: Fri Jul 26 14:23:48 2024 -0500

[docs]: Clarify mention of refer(1) behavior.
---
 doc/groff.texi.in | 4 ++--
 man/groff.7.man   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 34f1c7afc..c787d5d90 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -6633,8 +6633,8 @@ forms.
 @cindex macro names, starting with @code{[} or @code{]}, and @code{refer}
 If you begin a macro, string, or diversion name with either of the
 characters @samp{[} or @samp{]}, you foreclose use of the @code{grefer}
-preprocessor, which recognizes @samp{.[} and @samp{.]} as bibliographic
-reference delimiters.
+preprocessor, which recognizes input lines starting with @samp{.[} and
+@samp{.]} as bibliographic reference delimiters.
 
 @Defesc {\\A, @code{'}, anything, @code{'}}
 Interpolate@tie{}1 if @var{anything} is a valid identifier, and@tie{}0
diff --git a/man/groff.7.man b/man/groff.7.man
index 5cdb1ed6e..2fa40f112 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -1357,8 +1357,8 @@ or diversion name with either of the characters 
\[lq][\[rq] or
 you foreclose use of the
 .MR @g@refer @MAN1EXT@
 preprocessor,
-which recognizes \[lq].[\[rq] and \[lq].]\[rq] as bibliographic
-reference delimiters.
+which recognizes input lines starting with \[lq].[\[rq] and \[lq].]\[rq]
+as bibliographic reference delimiters.
 .
 .
 .P

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 03/14: [docs]: Discuss header/footer measurement matters.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 70b75da11a415c82bc6382afecb67c71864f5391
Author: G. Branden Robinson 
AuthorDate: Tue Jul 30 21:35:10 2024 -0500

[docs]: Discuss header/footer measurement matters.

Thanks to Dave Kemper for the suggestion.
---
 doc/groff.texi.in | 13 +
 1 file changed, 13 insertions(+)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index b82c19866..2882d0db0 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -14822,6 +14822,19 @@ the @code{tl} request.
 .wh -1i fo  \" trap 1 inch from bottom
 @endExample
 
+@strong{Caution:@:} A word about measurements is in order.  Recall that
+the @code{sp} request vertically spaces such that the next text baseline
+(of one vee in height by definition) sets with the amount of space given
+to @code{sp}'s argument @emph{above} it.  Thus in the example above,
+when the @samp{hd} trap springs at vertical position @samp{0},
+invoking @samp{sp .5i}, we get the desired half-inch of top margin.
+With the @samp{ft} trap, we space after the body text by one half-inch
+@emph{minus one vee} to leave a half-inch bottom margin.  The footer
+title, if anything taller than a baseline rule, thus ``encroaches'' into
+the half-inch margin between the body text and the bottom margin, just
+as the header title symmetrically intruded into the half-inch of space
+between its own cap-height and that of the top of the body text.
+
 To use these traps, copy the above (or load it from a file with the
 @code{so} or @code{mso} requests), then set up the strings it uses.
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 12/14: [troff]: Fix Savannah #66038 ("computed" lengths).

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 93d264070da6fff3f78c3831032eeba46aeeb2aa
Author: G. Branden Robinson 
AuthorDate: Tue Jul 30 21:40:44 2024 -0500

[troff]: Fix Savannah #66038 ("computed" lengths).

* src/roff/troff/div.cpp (page_length):
* src/roff/troff/env.cpp (line_length, title_length): Tweak diagnostic
  to say "computed" rather than "invalid", because while the value we're
  complaining about _is_ invalid, it is also a numeric expression that
  may have traveled a great distance through the alimentary canal of GNU
  troff's arithmetic evaluator, and bear little resemblance to what the
  user typed in a source document.  Among other things, we no longer
  have any idea what scaling units were supplied, but can report them
  only in basic units.

Fixes <https://savannah.gnu.org/bugs/?66038>.  Thanks to Dave Kemper for
the report.
---
 ChangeLog  | 16 
 src/roff/troff/div.cpp |  2 +-
 src/roff/troff/env.cpp |  4 ++--
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fec31e24d..20bf4efd8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,19 @@
+2024-07-30  G. Branden Robinson 
+
+   * src/roff/troff/div.cpp (page_length):
+   * src/roff/troff/env.cpp (line_length, title_length): Tweak
+   diagnostic to say "computed" rather than "invalid", because
+   while the value we're complaining about _is_ invalid, it is also
+   a numeric expression that may have traveled a great distance
+   through the alimentary canal of GNU troff's arithmetic
+   evaluator, and bear little resemblance to what the user typed in
+   a source document.  Among other things, we no longer have any
+   idea what scaling units were supplied, but can report them only
+   in basic units.
+
+   Fixes <https://savannah.gnu.org/bugs/?66038>.  Thanks to Dave
+   Kemper for the report.
+
 2024-07-30  G. Branden Robinson 
 
* doc/groff.texi.in (Manipulating Hyphenation): Fix incorrect
diff --git a/src/roff/troff/div.cpp b/src/roff/troff/div.cpp
index 5b352a315..dc029be0b 100644
--- a/src/roff/troff/div.cpp
+++ b/src/roff/troff/div.cpp
@@ -704,7 +704,7 @@ void page_length()
   vunits temp;
   if (has_arg() && get_vunits(, 'v', topdiv->get_page_length())) {
 if (temp < vresolution) {
-  warning(WARN_RANGE, "setting invalid page length %1u to device"
+  warning(WARN_RANGE, "setting computed page length %1u to device"
  " vertical motion quantum",
  temp.to_units());
   temp = vresolution;
diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index 6c443a3a9..35a81d12c 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -1435,7 +1435,7 @@ void line_length()
   hunits temp;
   if (has_arg() && get_hunits(, 'm', curenv->line_length)) {
 if (temp < hresolution) {
-  warning(WARN_RANGE, "setting invalid line length %1u to device"
+  warning(WARN_RANGE, "setting computed line length %1u to device"
  " horizontal motion quantum",
  temp.to_units());
   temp = hresolution;
@@ -1454,7 +1454,7 @@ void title_length()
   hunits temp;
   if (has_arg() && get_hunits(, 'm', curenv->title_length)) {
 if (temp < hresolution) {
-  warning(WARN_RANGE, "setting invalid title length %1u to device"
+  warning(WARN_RANGE, "setting computed title length %1u to device"
  " horizontal motion quantum",
  temp.to_units());
   temp = hresolution;

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 09/14: doc/groff.texi.in: Slightly recast.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 24ab0648a3a0560aa3e9f87f3da7f32bfeb4704e
Author: G. Branden Robinson 
AuthorDate: Fri Jul 26 14:30:20 2024 -0500

doc/groff.texi.in: Slightly recast.
---
 doc/groff.texi.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index ec719402a..0d3051532 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -7441,7 +7441,7 @@ Test
 @result{} Test
 @endExample
 
-To avoid this, it is common to combine the empty request with the
+To compensate, it is common to combine the empty request with the
 comment escape sequence as @samp{.\"}, causing the input line to be
 ignored.
 
@@ -7754,8 +7754,8 @@ To apply auto-incrementation to a register, interpolate 
it with
 Increment or decrement @var{ident} (one-character
 name@tie{}@var{i}, two-character name @var{id}) by the register's
 auto-incrementation value and then interpolate the new register value.
-If @var{ident} has no auto-incrementation value, interpolate as with
-@code{\n}.
+If @var{ident} has no auto-incrementation value, GNU @code{troff}
+interpolates its value without alteration.
 @endDefesc
 
 @need 1000

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 06/14: [docs]: Recast unrecognized escape sequence stuff.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 17e55e8b93fd886c673a0954d0abf08c8e1655b9
Author: G. Branden Robinson 
AuthorDate: Fri Jul 26 14:25:09 2024 -0500

[docs]: Recast unrecognized escape sequence stuff.
---
 doc/groff.texi.in |  8 
 man/groff.7.man   | 17 +
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index c787d5d90..eaafb6e70 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -7088,10 +7088,10 @@ package you use; consult its documentation to learn of 
``safe''
 sequences or alternative facilities it provides to achieve the desired
 result.
 
-If an escape character is followed by a character that does not
-identify a defined operation, the escape character is ignored (producing
-a diagnostic of the @samp{escape} warning category, which is not enabled
-by default) and the following character is processed normally.
+If an escape character is followed by a character that does not identify
+a defined operation, GNU @code{troff} ignores the escape character
+(producing a warning in category @samp{escape} if enabled), processing
+the next character as if it were not preceded by an escape character.
 
 @Example
 $ groff -T ps -ww
diff --git a/man/groff.7.man b/man/groff.7.man
index 2fa40f112..674842321 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -1686,15 +1686,16 @@ In no case can an escape sequence parameter contain a 
newline.
 .
 .
 .P
-If an escape character is followed by a character that does not
-identify a defined operation,
-the escape character is ignored
-(producing
-a diagnostic of the
+If an escape character is followed by a character
+that does not identify a defined operation,
+GNU
+.I troff \" GNU
+ignores the escape character
+(producing a warning in category
 .RB \[lq] escape \[rq]
-warning category,
-which is not enabled by default)
-and the following character is processed normally.
+if enabled),
+processing the next character
+as if it were not preceded by an escape character.
 .
 .
 .P

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 02/14: doc/groff.texi.in: Fix typo/thinko.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit c14e85d16b4299cd545ba449603a27c89d73eb49
Author: G. Branden Robinson 
AuthorDate: Tue Jul 30 21:04:22 2024 -0500

doc/groff.texi.in: Fix typo/thinko.

Thanks to Dave Kemper for catching it.
---
 doc/groff.texi.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 1ea82341d..b82c19866 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -14801,7 +14801,7 @@ there.
 A macro package might set headers and footers as follows; this example
 configures vertical margins of one inch to the body text, and one
 half-inch to the titles.  Observe the use of the no-break control
-character with the @code{sp} and @code{br} requests to position our text
+character with the @code{sp} and @code{bp} requests to position our text
 baselines and prevent a partially collected line from being written
 outside the body text, and the page number character @samp{%} used with
 the @code{tl} request.

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 04/14: [docs]: Clarify description of `pline` request.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 174bd8d4699d9fa7464323d57ef7a233eebc
Author: G. Branden Robinson 
AuthorDate: Fri Jul 26 13:57:23 2024 -0500

[docs]: Clarify description of `pline` request.
---
 doc/groff.texi.in | 4 ++--
 man/groff.7.man   | 3 +--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 2882d0db0..34f1c7afc 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -17058,8 +17058,8 @@ exit codes respectively, to halt further processing 
when continuing
 would be fruitless.  Examine the state of the formatter with requests
 that write lists of defined names (macros, strings, and diversions),
 colors, composite characters, environments, hyphenation exceptions,
-registers, page location traps, and a list of pending output nodes
-corresponding to the previous input line to the standard error stream.
+registers, page location traps, and a list of output nodes corresponding
+to the pending input line to the standard error stream.
 @c END Keep parallel with section "Debugging" of groff(7).
 
 @Defreq {lf, line [@Var{file}]}
diff --git a/man/groff.7.man b/man/groff.7.man
index eead32590..5cdb1ed6e 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -8448,8 +8448,7 @@ registers
 .RB ( .pnr );
 page location traps
 .RB ( .ptr );
-and a list of pending output nodes corresponding to the previous input
-line
+and a list of output nodes corresponding to the pending input line
 .RB ( .pline )
 to the standard error stream.
 .\" END Keep (roughly) parallel with groff.texi node "Debugging".

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 01/14: ChangeLog: Correct bug closers in old entries.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 1b01538fdad56fa8d863b4160b694eeaee84266d
Author: G. Branden Robinson 
AuthorDate: Fri Jul 26 13:48:30 2024 -0500

ChangeLog: Correct bug closers in old entries.
---
 ChangeLog | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 751d40c90..011fe7e77 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -420,14 +420,14 @@
ERANGE to reject high values.  The test 'n > INT_MAX' would
never be true.
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (10/10).
+   Fixes <https://savannah.gnu.org/bugs/?65451> (6/6).
 
 2024-03-16  Alejandro Colomar 
 
* src/utils/indxbib/indxbib.cpp (check_integer_arg): Collapse
related tests.
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (09/10).
+   Fixes <https://savannah.gnu.org/bugs/?65452> (4/4).
 
 2024-03-16  Alejandro Colomar 
 
@@ -435,7 +435,7 @@
code.  The tests (LONG_MAX > INT_MAX && n > INT_MAX) and (n >
INT_MAX) are equivalent.
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (08/10).
+   Fixes <https://savannah.gnu.org/bugs/?65452> (3/4).
 
 2024-03-16  Alejandro Colomar 
 
@@ -443,14 +443,14 @@
`errno` before calling `strtol()`.  Otherwise, `errno` may hold
`ERANGE` from before.  See strtol(3).
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (07/10).
+   Fixes <https://savannah.gnu.org/bugs/?65452> (2/4).
 
 2024-03-16  Alejandro Colomar 
 
* src/utils/indxbib/indxbib.cpp (check_integer_arg): Don't
`else` after [[noreturn]].
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (06/10).
+   Fixes <https://savannah.gnu.org/bugs/?65452> (1/4).
 
 2024-03-16  Alejandro Colomar 
 
@@ -473,7 +473,7 @@
* src/utils/indxbib/indxbib.cpp (main): And use it where the
same logic was being open-coded.
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (05/10).
+   Fixes <https://savannah.gnu.org/bugs/?65451> (5/6).
 
 2024-03-16  Alejandro Colomar 
 
@@ -481,7 +481,7 @@
redundant) check.  `str == end` can only happen if strtol(3)
returns 0.
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (04/10).
+   Fixes <https://savannah.gnu.org/bugs/?65451> (4/6).
 
 2024-03-16  Alejandro Colomar 
 
@@ -506,7 +506,7 @@
after strtol(3).  `str == end` can only happen if strtol(3)
returns 0.
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (03/10).
+   Fixes <https://savannah.gnu.org/bugs/?65451> (3/6).
 
 2024-03-16  Alejandro Colomar 
 
@@ -514,7 +514,7 @@
code.  strtol(3) can only report ERANGE, if the base is valid
{and it is}.
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (02/10).
+   Fixes <https://savannah.gnu.org/bugs/?65451> (2/6).
 
 2024-03-16  Alejandro Colomar 
 
@@ -522,7 +522,7 @@
checks.  ERANGE can only happen if strtol(3) returns either
LONG_MIN or LONG_MAX.
 
-   Fixes <https://savannah.gnu.org/bugs/?65451> (01/10).
+   Fixes <https://savannah.gnu.org/bugs/?65451> (1/6).
 
 2024-07-12  G. Branden Robinson 
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 11/14: [docs]: Correct discussion of hyphenation codes.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 4449a4f061949c4db6c216288e8530d34bdb691c
Author: G. Branden Robinson 
AuthorDate: Tue Jul 30 21:14:56 2024 -0500

[docs]: Correct discussion of hyphenation codes.

* doc/groff.texi.in (Manipulating Hyphenation): Fix incorrect claim and
  expand discussion.  A special character _can_ be an argument to the
  `hcode` request, and this has been true for over 20 years (for
  example, in "tmac/ps.tmac").  Problem dates back to commit bd66717ef7,
  16 April 2001.

* man/groff.7.man (Request short reference):
* man/groff_diff.7.man (New requests): Sync language with our Texinfo
  manual, and clarify.
---
 ChangeLog| 12 
 doc/groff.texi.in| 46 +-
 man/groff.7.man  | 12 
 man/groff_diff.7.man | 34 ++
 4 files changed, 67 insertions(+), 37 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c456c0b92..fec31e24d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2024-07-30  G. Branden Robinson 
+
+   * doc/groff.texi.in (Manipulating Hyphenation): Fix incorrect
+   claim and expand discussion.  A special character _can_ be an
+   argument to the `hcode` request, and this has been true for over
+   20 years (for example, in "tmac/ps.tmac").  Problem dates back
+   to commit bd66717ef7, 16 April 2001.
+
+   * man/groff.7.man (Request short reference):
+   * man/groff_diff.7.man (New requests): Sync language with our
+   Texinfo manual, and clarify.
+
 2024-07-29  G. Branden Robinson 
 
* src/roff/troff/input.cpp (set_hyphenation_code): Restore
diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 0d3051532..78fe349d6 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -8964,25 +8964,32 @@ loaded at startup, or in a macro package), GNU 
@code{troff} won't
 automatically hyphenate at all.
 @endDefreq
 
-@Defreq {hcode, c1 code1 [c2 code2] @dots{}}
+For automatic hyphenation to work, the formatter must know which letters
+are equivalent; for example, the letter @samp{E} behaves like @samp{e};
+only the latter typically appears in hyphenation pattern files.  GNU
+@code{troff} expects characters that participate in automatic
+hyphenation to be assigned @dfn{hyphenation codes} that define these
+equivalence classes.  At startup, GNU @code{troff} assigns hyphenation
+codes to the letters @samp{a}--@samp{z}, applies the same codes to
+@samp{A}--@samp{Z} in one-to-one correspondence, and assigns a code of
+zero to all other characters.
+
+The @code{hcode} request extends this principle to letters outside the
+Unicode basic Latin alphabet; without it, words containing such letters
+won't be hyphenated properly even if the corresponding hyphenation
+patterns contain them.
+
+@Defreq {hcode, dst1 src1 [dst2 src2] @dots{}}
 @cindex hyphenation code (@code{hcode})
 @cindex code, hyphenation (@code{hcode})
-Set the hyphenation code of character @var{c1} to @var{code1}, that of
-@var{c2} to @var{code2}, and so on.  A hyphenation code must be an
-ordinary character (not a special character escape sequence) other than
-a digit or a space.  The request is ignored if given no arguments.
-
-For automatic hyphenation to work, hyphenation codes must be set up.  At
-startup, GNU @code{troff} assigns hyphenation codes to the letters
-@samp{a}--@samp{z} (mapped to themselves), to the letters
-@samp{A}--@samp{Z} (mapped to @samp{a}--@samp{z}), and zero to all other
-characters.  Normally, hyphenation patterns contain only lowercase
-letters which should be applied regardless of case.  In other words,
-they assume that the words `FOO' and `Foo' should be hyphenated exactly
-as `foo' is.  The @code{hcode} request extends this principle to letters
-outside the Unicode basic Latin alphabet; without it, words containing
-such letters won't be hyphenated properly even if the corresponding
-hyphenation patterns contain them.
+Set the hyphenation code of ordinary or special character @var{dst1} to
+that of @var{src1}, and so on.  @var{dst1} must be an ordinary character
+(other than a numeral) or a special character, and @var{src1} must be an
+ordinary character (other than a numeral) or a special character to
+which a hyphenation code has already been applied.  Assigning the code
+of an ordinary character code to itself effectively creates a unique
+hyphenation code (which can then be copied to others).  @code{hcode}
+ignores spaces between arguments.
 
 For example, the following @code{hcode} requests are necessary to assign
 hyphenation codes to the letters @samp{���}, needed for German.
@@ -9001,6 +9008,11 @@ umlaut@tie{}a is zero by default, just like a space.  
There is a German
 hyphenation pattern that covers @w{`kinder'}, so GNU @code{troff} finds
 the hyphenation `kin-der'.  The other two hyphenation points
 (`kin-der-

[groff] 14/14: groff_mm(7): Fix content, style, and markup nits.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 583f52a8c073e69682359879bb0a49f3add910be
Author: G. Branden Robinson 
AuthorDate: Wed Jul 31 01:12:57 2024 -0500

groff_mm(7): Fix content, style, and markup nits.

Content:
* Specify the 3.3 version of DWB mm as the one that groff mm largely
  reimplements.  Recent changes have made them more similar, especially
  with respect to `LT` letters and `MT` memoranda.
* Advise user to double-quote macro arguments requiring spaces.  Expand
  example of macro call accordingly.
* Define the term "hook" in introduction to "Macros" section, and apply
  it without recapitulating explanation in macro descriptions.

Style:
* Favor active voice over passive.
* Suggest use of explicit scaling units earlier and at less length.
* Fix grammar nit.

Markup:
* Break input lines before multi-word parentheticals.
---
 contrib/mm/groff_mm.7.man | 79 ---
 1 file changed, 41 insertions(+), 38 deletions(-)

diff --git a/contrib/mm/groff_mm.7.man b/contrib/mm/groff_mm.7.man
index d02bd721d..a236eb9ee 100644
--- a/contrib/mm/groff_mm.7.man
+++ b/contrib/mm/groff_mm.7.man
@@ -128,8 +128,8 @@ adds an item and
 .B LE
 ends the (nested) list.
 .
-Customized list arrangements are supported by
-.BR LB .
+.B LB
+begins a list with customizable layout parameters.
 .
 .B DS
 and
@@ -144,7 +144,7 @@ either is terminated with
 .I groff mm
 is intended to be compatible with the
 .I mm
-implementation found in the AT Documenter's Workbench (DWB),
+implementation found in the AT Documenter's Workbench (DWB) 3.3,
 with the following limitations and changes.
 .
 .
@@ -292,13 +292,15 @@ and vertical ones in vees
 (scaling unit
 .BR v ).
 .
+Use explicit scaling units for clarity and predictable behavior.
+.
 .
 .\" 
 .SS "Document styles"
 .\" 
 .
 .I groff mm
-offers three different frameworks for document organization.
+offers three frameworks for document organization.
 .
 .BR \%COVER /\: \%COVEND
 is a flexible means of preparing any document requiring a cover page.
@@ -593,30 +595,18 @@ for instance with
 .SH Macros
 .\" 
 .
-Where a macro accepts an argument expressing a measurement,
-horizontal ones
-(such as indentation)
-are by default reckoned in ens,
-and vertical ones
-(such as spacing around a display)
-are reckoned in vees.
-.
-Use an explicit scaling unit for clarity and predictable behavior.
+Double-quote macro arguments that contain space characters.
 .
-.
-.P
-An explicitly empty argument may be specified with a pair of double
-quotes;
-to call a macro
-.B XX
-with an empty second argument but non-empty first and third ones,
-you could input the following.
+An explicitly empty argument may be specified
+with an empty pair of double quotes;
+for example,
+the following macro call has three arguments.
 .
 .
 .P
 .RS
 .EX
-\&.XX foo \[dq]\[dq] baz
+\&.XX \[dq]foo bar\[dq] \[dq]\[dq] baz
 .EE
 .RE
 .
@@ -630,6 +620,17 @@ if any).
 .
 .
 .P
+.I Hook
+macros are undefined by default;
+.I mm
+calls them to enable customization of its behavior.
+.
+(DWB
+.I mm
+termed these \[lq]exits\[rq].)
+.
+.
+.P
 Macro names longer than two characters are GNU extensions;
 some shorter names were not part of DWB
 .IR mm 's
@@ -717,8 +718,8 @@ and
 .
 .TP
 .B AFX
-This user-definable hook macro assumes responsibility for formatting
-the affiliated firm name defined by
+Define this hook macro to assume responsibility for formatting the
+affiliated firm name defined by
 .B AF
 in memorandum types 0 and 4 and documents using the
 .I ms
@@ -729,10 +730,10 @@ If not defined
 internally defined macros handle this task;
 see sections \[lq]Internals\[rq] and \[lq]Files\[rq] below.
 .
-Applications include setting the firm name in a different font family,
-at a larger type size,
+Applications include setting the firm name in a different font family
+or at a larger type size,
 drawing a rule across the page,
-and including an logo image using
+and including a logo image using
 .IR groff 's
 .B PDFPIC
 or
@@ -2032,22 +2033,22 @@ register.
 .IP
 .I Customizing heading behavior.
 .
-.I mm
+.B H
 calls
-.I hook
-macros to enable further customization of headings.
-.
-(DWB
-.I mm
-termed them \[lq]exits\[rq].)
+.BR HX ,
+.BR HY ,
+and
+.B HZ
+hook macros to further customize headings.
 .
-Hooks can change the heading's
+These can change the heading's
 .I mark
 (the numbered portion before any heading title),
 its vertical spacing,
 and its vertical space requirements
 (for instance,
-to require a minimum quantity of subsequent output lines).
+to require a minimum quantity of subsequent output lines on the page,
+breaking the p

[groff] 10/14: [troff]: Fix Savannah #66040 (`hcode` & `\[xxx]`).

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit c34502070b1374cceec484b0b825f80ab8d812bf
Author: G. Branden Robinson 
AuthorDate: Mon Jul 29 23:11:11 2024 -0500

[troff]: Fix Savannah #66040 (`hcode` & `\[xxx]`).

* src/roff/troff/input.cpp (set_hyphenation_code): Restore diagnostic
  message when attempting to assigning the hyphenation code of a special
  character to another character (special or ordinary).  Also initialize
  local variable much closer to where we test its value, for
  readability.

Fixes <https://savannah.gnu.org/bugs/?66040>.  Thanks to Dave Kemper for
the report.
---
 ChangeLog| 11 +++
 src/roff/troff/input.cpp | 14 ++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 011fe7e77..c456c0b92 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2024-07-29  G. Branden Robinson 
+
+   * src/roff/troff/input.cpp (set_hyphenation_code): Restore
+   diagnostic message when attempting to assigning the hyphenation
+   code of a special character to another character (special or
+   ordinary).  Also initialize local variable much closer to where
+   we test its value, for readability.
+
+   Fixes <https://savannah.gnu.org/bugs/?66040>.  Thanks to Dave
+   Kemper for the report.
+
 2024-07-25  G. Branden Robinson 
 
* src/roff/troff/number.cpp (get_vunits, get_hunits, get_number)
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index d0ef4a0f1..615cd3820 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -7291,15 +7291,21 @@ static void set_hyphenation_codes()
   break;
 tok.next();
 tok.skip();
-unsigned char c = tok.ch();
 if (tok.is_newline() || tok.is_eof()) {
   error("hyphenation codes must be specified in pairs");
   break;
 }
 charinfo *ci2 = tok.get_char(true /* required */);
-// nonsense redux
-if (0 /* nullptr */ == ci2)
-  break;
+unsigned char c = tok.ch();
+if (0 == c) {
+  if (0 /* nullptr */ == ci2)
+   break;
+  if (0 == ci2->get_hyphenation_code()) {
+   error("second member of hyphenation code pair must be an"
+ " ordinary character");
+   break;
+  }
+}
 // TODO: What if you want to unset a hyphenation code?  Accept 0?
 if (csdigit(c)) {
   error("hyphenation code cannot be digit");

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 07/14: doc/groff.texi.in: Fix comment.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 0555c458947cd131f84835c19487a9deec8cfebf
Author: G. Branden Robinson 
AuthorDate: Fri Jul 26 14:26:44 2024 -0500

doc/groff.texi.in: Fix comment.
---
 doc/groff.texi.in | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index eaafb6e70..127828f2e 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -7396,8 +7396,7 @@ We see here that in compatibility mode, the part of the 
argument after
 the @code{'} delimiter escapes from its context and, if nefariously
 crafted, influences the computation of the @var{wd} register's value in
 a surprising way.
-@c END Keep (roughly) parallel with subsection " Delimiters" of
-@c groff(7).
+@c END Keep (roughly) parallel with subsection "Delimiters" of groff(7).
 
 @node Comments, Registers, Formatter Instructions, GNU troff Reference
 @section Comments

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 13/14: tmac/an.tmac: Silence `HP` deprecation warning.

2024-07-31 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit d483834af930eeec2cc9f77441af5d581fe18c50
Author: G. Branden Robinson 
AuthorDate: Tue Jul 30 22:02:58 2024 -0500

tmac/an.tmac: Silence `HP` deprecation warning.

* tmac/an.tmac (HP): The `mS` extension register has changed its meaning
  (commit f680c55d38, 13 June) such that it is no longer a reliable
  indicator of whether the deprecation warning for this macro should be
  suppressed, so stop suppressing a deprecation warning based on its
  value.  In fact, stop issuing the deprecation warning altogether.
  (See <https://lists.gnu.org/archive/html/bug-ncurses/2024-04/
  msg00027.html>.)
---
 ChangeLog| 10 ++
 tmac/an.tmac |  1 -
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 20bf4efd8..f5230695c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-07-30  G. Branden Robinson 
+
+   * tmac/an.tmac (HP): The `mS` extension register has changed its
+   meaning (commit f680c55d38, 13 June) such that it is no longer a
+   reliable indicator of whether the deprecation warning for this
+   macro should be suppressed, so stop suppressing a deprecation
+   warning based on its value.  In fact, stop issuing the
+   deprecation warning altogether.  (See .)
+
 2024-07-30  G. Branden Robinson 
 
* src/roff/troff/div.cpp (page_length):
diff --git a/tmac/an.tmac b/tmac/an.tmac
index d0c1727f9..2b361970f 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -881,7 +881,6 @@ contains unsupported escape sequence
 .\" Set a paragraph with a hanging indentation.
 .\" .HP [indent]
 .de1 HP
-.  if !\\n[mS] \\*[an-deprecation-warn]\\
 .  an-break-paragraph
 .  ne (1v + 1u)
 .  if \\n[.$] .nr an-prevailing-indent (n;\\$1)

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[bug #62040] [troff] crash at formatter exit due to MTSM stack cleanup

2024-07-30 Thread G. Branden Robinson
Update of bug #62040 (group groff):

 Planned Release:  1.24.0 => None   

___

Follow-up Comment #18:

Unsetting "Planned Release" field so this duplicate doesn't show up in queries
of bugs fixed by _groff_ 1.24.0.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65977] [troff] `device` request should work early as `\X` does

2024-07-30 Thread G. Branden Robinson
Update of bug #65977 (group groff):

  Item Group: Warning/Suspicious behaviour => Incorrect behaviour 
  


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65980] [troff] diagnose why directory operands can't be opened

2024-07-30 Thread G. Branden Robinson
Update of bug #65980 (group groff):

Severity:   2 - Minor => 1 - Wish   


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65225] [tbl] character repetitions in cells broken (\Rx)

2024-07-30 Thread G. Branden Robinson
Update of bug #65225 (group groff):

  Item Group: Rendering/Cosmetics => Incorrect behaviour


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66038] [troff] want "invalid line length" diagnostic to not misrepresent user input

2024-07-30 Thread G. Branden Robinson
Update of bug #66038 (group groff):

  Status:   Need Info => In Progress
 Assigned to:barx => gbranden   

___

Follow-up Comment #6:

Cool--I'll proceed with that, then.

It's been 5 days since I've pushed--I think I'll clear my plate (and slightly
clear my Git stash) of some small fixes and get those lined up for a push
before returning to the heavier going of:

1. building the hyphenation code factory
2. implementing saturating arithmetic
3. landing next-generation adjustment/alignment control


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


Re: vim :hardcopy equivalent

2024-07-30 Thread G. Branden Robinson
At 2024-07-29T19:28:40-0500, Dave Kemper wrote:
> On Wed, Jul 24, 2024 at 2:24 PM G. Branden Robinson
> > Sure enough, there were problems.  I've fixed them in my working
> > copy and you can expect them in my next push.
> 
> Commit 0cc32d8b7
> (http://git.savannah.gnu.org/cgit/groff.git/commit/?id=0cc32d8b7)
> seems to be the cited fix.
> 
> I have one correction and one suggestion about this change.
> 
> Correction:
> The text "the @code{sp} and @code{br} requests" was added, but the
> example uses no .br.  According to the git log entry, this should say
> "bp".

Thanks!  Look for this in my next push.

> Suggestion:
> The git log entry, specifically the third and fourth items, explain
> why certain .sp parameters are written as they are.  At least the
> latter of these items, and maybe both, are subtle points about margin
> sizes worth explaining to readers (of the manual, not just of the git
> log).
> 
> (And I'm not sure the git log explanation is quite right: it says
> "adjusting [the footer] 1v up the page from the bottom of the body
> text" where it seems to mean "1v up the page from *half an inch below*
> the bottom of the body text."  As written, it sounds like the footer
> overstrikes the bottom of the body text.)

Okay.  I'll review the text and see how I might expand and correct it.

Regards,
Branden


signature.asc
Description: PGP signature


[bug #66040] [troff] no longer warns about unrecognized .hcode input

2024-07-30 Thread G. Branden Robinson
Follow-up Comment #10, bug #66040 (group groff):

I said:

> Accented vowels are members of those equivalence classes in GNU troff

That's actually not true.

In German, they're _all_ _sui generis_ except for the uppercase versions.


.hcode ä ä  â â  à à  á á  ã ã  å å  æ æ
.hcode ç ç
.hcode é é  è è  ë ë  ê ê
.hcode í í  ì ì  î î  ï ï
.hcode ñ ñ
.hcode ó ó  ò ò  ô ô  ö ö  ø ø
.hcode ú ú  ü ü  û û
.
.hcode Ä ä  Â â  À à  Á á  Ã ã  Å å  Æ æ
.hcode Ç ç
.hcode É é  È è  Ë ë  Ê ê
.hcode Í í  Ì ì  Î î  Ï ï
.hcode Ñ ñ
.hcode Ó ó  Ò ò  Ô ô  Ö ö  Ø ø
.hcode Ú ú  Ü ü  Û û
.
.hcode ß ß


What I gather is that what bug #42870, and you, are asking for is that we be
able to substitute special characters for these ordinary ones.

And if that is the case I agree.  I think the only reason it hasn't been done
is because there was no good answer for "what character code does a special
character have"?

*My* answer, which one may claim is not a very good one, is that we can make
one up--one that is larger than 255 so there is no chance of collision in GNU
_troff_'s currently limited mind.

The same technique can be retained in a UTF-8 GNU _troff_; Unicode is a
20.1-bit encoding in a 32-bit space.  We'll have some room.  And even if the
set of predefined special characters is completely handled by existing defined
Unicode code points (spoiler alert: it isn't, but just barely), users can
create new special characters with the `char` request so we'll still need the
flexibility anyway.

I mean, assuming any _groff_ user would ever write custom hyphenation pattern
files for their constructed language.

Proper hyphenation of Sindarin, coming in _groff_ 1.25!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66040] [troff] no longer warns about unrecognized .hcode input

2024-07-30 Thread G. Branden Robinson
Follow-up Comment #9, bug #66040 (group groff):

[comment #8 comment #8:]
> [comment #6 comment #6:]
> > [comment #5 comment #5:]
> > > The special character \['e] in the second line is still
> > > rejected even after being assigned a code in the first.
> > 
> > I noticed that too.  I think it's a bug.  I'm working on it.
> 
> I mean, sure, that could be called a bug... but why would it be a bug that
the special character is unrecognized only on its second appearance?

If you mean "as the second member of a pair with itself", I have an answer.

Because the formatter doesn't know what value to give it.  Under the hood,
it's just a character code--in other words, on an ISO 8859 system, the
hyphenation codes for 'a' through 'z' are 97 through 122--but our
documentation stands on its head to avoid saying that.  The trouble is that
there is a potentially larger space of _sui generis_ special characters, by
which I mean ones that don't belong to an equivalence class of a Basic Latin
letter.  Accented vowels are members of those equivalence classes in GNU
_troff_ but the German Eszett is not.  If we had an Icelandic locale, thorn
and eth would similarly have to have hyphenation codes above 127 decimal.

The real fun comes when you add letters from multiple ISO 8859 character sets.
 Before long you're going to have collisions.

So it's good that our documentation does the headstand.  We should not
disclose what the hyphenation code values _are_, we need only to ensure that
they sort into the correct equivalence classes, so that they then interoperate
as desired with the hyphenation patterns.

When we get support for UTF-8-encoded hyphenation pattern files, things will
become straightforward again.

In the meantime, what I think I will do is use a `static int` to mint a
sequence number (starting at 256) for hyphenation codes any time a special
character needs one _sui generis_.
 
> Why shouldn't it just be recognized in any .hcode invocation?

See above.

> And as it happens, that suggestion (bug #42870) was filed ten years ago--and
its fixing would make .hcode's behavior simple to use and simple to document,
whereas allowing it only in some cases complicates both of those.

The solution I proposed above would indeed fix bug #42870, I think.  Do you
agree?

If so, we probably ought to copy the meat of it over to that ticket and mark
it "in progress".
 
> > The part I'm griefed about is "(not a special character escape
sequence)".
> 
> It's griefworthy but it's not inaccurate.

It is.  A special character is _sometimes_ okay, and has been for a long time,
as I tried to illustrate in comment #6.

But it would be laborious and perhaps embarrassing to explain the cases where
it isn't.

> Overturning it is #42870's life goal.

Yes--if my plan survives contact with the enemy, the parenthetical can die.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66038] [troff] want "invalid line length" diagnostic to not misrepresent user input

2024-07-30 Thread G. Branden Robinson
Update of bug #66038 (group groff):

  Status:   Postponed => Need Info  
 Assigned to:gbranden => barx   

___

Follow-up Comment #4:

How about

"computed line length 0u rounded to device horizontal motion quantum"

?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


GNU maintainership update

2024-07-30 Thread G. Branden Robinson
Hi folks,

I've heard back from Bertrand Garrigues, and he advised that I start the
hand-off process for GNU maintainership of the groff package/project.

I have consequently contacted maintainers@gnu to initiate that process.
Neither of us have a clear idea how long it will take, but he seemed
confident that it wouldn't resemble an overnight procedure.

Bertrand agreed that a 1/year cadence for groff releases sounded good,
and said he'd be available to perform maintainer duties (mainly release
management for 1.24.0 later this year) as long as they were (in my own
wording) no more burdensome than those he had to handle for the groff
1.23.0 release.

Bertrand's contributions of (1) migration to GNU Automake for our build
system, (2) inclusion of gnulib as a C portability library, and (3)
inauguration of an automated test suite for the code base have in my
estimation delivered major benefits to the maintainability of groff; all
were strongly forward-looking choices not necessarily easily appreciated
directly by users.  The test harness alone has ensured that many
bugs and mistakes never landed in the Git repository in the first place.

As a developer, I would have found groff much less approachable and far
more frustrating had it not been for Bertrand's improvements.

Bertrand has been quiet for a while but his positive impact on groff is
unmistakable to a software engineer's eyes.

I hope you will join me in thanking him for his excellent work.

Regards,
Branden


signature.asc
Description: PGP signature


[bug #66040] [troff] no longer warns about unrecognized .hcode input

2024-07-30 Thread G. Branden Robinson
Follow-up Comment #7, bug #66040 (group groff):

On second thought, it feels more orthogonal to go ahead and copy an
uninitialized (zero) value from the second member of a hyphenation code pair.

And that would also solve the "problem" noted in a "TODO" commend of
permitting the removal of a value from a hyphenation code.

(Though that's already possible, I think, with requests like `hcode a $` or
`hcode \['e] #`.)

(Also this stuff is too friggin' hard to introspect.  I feel myself itching to
write a `phcode` request to dump these things.)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66040] [troff] no longer warns about unrecognized .hcode input

2024-07-30 Thread G. Branden Robinson
Follow-up Comment #6, bug #66040 (group groff):


[comment #5 comment #5:]
> [comment #4 comment #4:]
> >error("second member of hyphenation code pair must be an"
> >  " ordinary character, or a special character already"
> >  " assigned a hyphenation code");
> 
> This message's problem isn't that it's long--it might be that it's not long
enough!  Or at least not clear enough.  I would read the second clause to mean
this should work.

> .hcode \['e] e
> .hcode \['E] \['e]


> But it doesn't.  The special character \['e] in the second line is still
rejected even after being assigned a code in the first.

I noticed that too.  I think it's a bug.  I'm working on it.
 
> > Our documentation ("A hyphenation code must be an ordinary
> > character (not a special character escape sequence) other than
> > a digit or a space.") is wrong and I'll be fixing that, too.
> 
> The digit exception is correct: "echo '.hcode a 8' | groff" emits the error
"hyphenation code cannot be digit" in 1.22.4, 1.23, and current code.  The
space exception seems correct in the sense that there's not really a syntax
for indicating a space as an .hcode target: spaces are regarded as delimiting
the arguments, and escaping a space turns it into an escape sequence, no
longer a space.

The part I'm griefed about is "(not a special character escape sequence)".

A "hyphenation code" (an argument to the `hcode` request):

1.  is always permitted as the destination (first of a pair), as in


.hcode \[S ,]s


from "tmac/ps.tmac".

2.  _should_ be permitted as the source (second of a pair), *if* that code has
already been assigned a nonzero value.

> I can't comment aside from that, since I'm not sure what exception to the
special-character prohibition your proposed diagnostic is trying to convey.

Watch this space, so to speak.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66040] [troff] no longer warns about unrecognized .hcode input

2024-07-29 Thread G. Branden Robinson
Update of bug #66040 (group groff):

  Status:   Confirmed => In Progress

___

Follow-up Comment #4:

I have a fix.


diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index d0ef4a0f1..11d58e05b 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -7291,15 +7291,22 @@ static void set_hyphenation_codes()
   break;
 tok.next();
 tok.skip();
-unsigned char c = tok.ch();
 if (tok.is_newline() || tok.is_eof()) {
   error("hyphenation codes must be specified in pairs");
   break;
 }
 charinfo *ci2 = tok.get_char(true /* required */);
-// nonsense redux
-if (0 /* nullptr */ == ci2)
-  break;
+unsigned char c = tok.ch();
+if (0 == c) {
+  if (0 /* nullptr */ == ci2)
+   break;
+  if (0 == ci2->get_hyphenation_code()) {
+   error("second member of hyphenation code pair must be an"
+ " ordinary character, or a special character already"
+ " assigned a hyphenation code");
+   break;
+  }
+}
 // TODO: What if you want to unset a hyphenation code?  Accept 0?
 if (csdigit(c)) {
   error("hyphenation code cannot be digit");


Longest diagnostic message EVAR, I know.  Sorry not sorry?

Our documentation ("A hyphenation code must be an ordinary character (not a
special character escape sequence) other than a digit or a space.") is wrong
and I'll be fixing that, too.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #42870] [troff] `.hcode' and `.hw' are limited to ordinary characters

2024-07-29 Thread G. Branden Robinson
Update of bug #42870 (group groff):

  Status:  Unreproducible => Invalid
 Assigned to:carstenkunze => gbranden   
 Open/Closed:Open => Closed 
 Summary: `.hcode' and `.hw' are limited to raw 8bit
characters but should accept any characters entities. => [troff] `.hcode' and
`.hw' are limited to ordinary characters

___

Follow-up Comment #11:

I think this report was just mistaken in the first place.

Very few changes were made in "src/roff/troff" in 2014, and those that I see
have no bearing on hyphenation as far as I can tell.

Here's a counterexample for the `hcode` complaint.


$ cat EXPERIMENTS/weird-kindergarten.groff
.if r HCODE .hcode @ a
.ll 62n
\c
.nr oldline \n[nl]
.while (\n[oldline] = \n[nl]) kinderg@rten
.pl \n[nl]u
$ ~/groff-HEAD/bin/groff -T utf8 EXPERIMENTS/weird-kindergarten.groff
kinderg@rten kinderg@rten kinderg@rtenkinderg@rten
kinderg@rten
$ ~/groff-HEAD/bin/groff -r HCODE=1 -T utf8
EXPERIMENTS/weird-kindergarten.groff
kinderg@rten  kinderg@rten  kinderg@rten  kinderg@rten kinder‐
g@rten
$ ~/groff-stable/bin/groff -T utf8 EXPERIMENTS/weird-kindergarten.groff
kinderg@rten kinderg@rten kinderg@rtenkinderg@rten
kinderg@rten
$ ~/groff-stable/bin/groff -r HCODE=1 -T utf8
EXPERIMENTS/weird-kindergarten.groff
kinderg@rten  kinderg@rten  kinderg@rten  kinderg@rten kinder‐
g@rten
$ /usr/bin/groff -T utf8 EXPERIMENTS/weird-kindergarten.groff
kinderg@rten kinderg@rten kinderg@rtenkinderg@rten
kinderg@rten
$ /usr/bin/groff -r HCODE=1 -T utf8 EXPERIMENTS/weird-kindergarten.groff
kinderg@rten  kinderg@rten  kinderg@rten  kinderg@rten kinder‐
g@rten
$ ~/groff-1.22.3/bin/groff -T utf8 EXPERIMENTS/weird-kindergarten.groff
kinderg@rten kinderg@rten kinderg@rtenkinderg@rten
kinderg@rten
$ ~/groff-1.22.3/bin/groff -r HCODE=1 -T utf8
EXPERIMENTS/weird-kindergarten.groff
kinderg@rten  kinderg@rten  kinderg@rten  kinderg@rten kinder‐
g@rten


Resolving as invalid.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #42870] `.hcode' and `.hw' are limited to raw 8bit characters but should accept any characters entities.

2024-07-29 Thread G. Branden Robinson
Follow-up Comment #10, bug #42870 (group groff):

The example in comment #8 works for me with _groff_ 1.22.3 as well.

That was released in November 2014, a mere four months after the mailing list
thread linked in comment #1.

It's possible Werner was mistaken, and he misremembered a feature as missing
when it was present.

Or he swiftly fixed it for the 1.22.3 release.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #42870] `.hcode' and `.hw' are limited to raw 8bit characters but should accept any characters entities.

2024-07-29 Thread G. Branden Robinson
Follow-up Comment #9, bug #42870 (group groff):

The example in comment #8 works for me with _groff_ 1.22.4 and _groff_
1.23.0.

Possibly Werner fixed this a long time ago?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #42870] `.hcode' and `.hw' are limited to raw 8bit characters but should accept any characters entities.

2024-07-29 Thread G. Branden Robinson
Update of bug #42870 (group groff):

  Status:   Need Info => Unreproducible 
 Assigned to:None => carstenkunze   

___

Follow-up Comment #8:

I cannot reproduce the complaint about `hw` not working with 8-bit
characters.


$ cat EXPERIMENTS/escape-kindergarten.groff
.if r HW .hw kin-der-g\[a ad]r-ten
.ll 62n
\c
.nr oldline \n[nl]
.while (\n[oldline] = \n[nl]) kinderg\[a ad]rten
.pl \n[nl]u
$ ./build/test-groff -T utf8 EXPERIMENTS/escape-kindergarten.groff 
kindergärten kindergärten kindergärtenkindergärten
kindergärten
$ ./build/test-groff -r HW=1 -T utf8 EXPERIMENTS/escape-kindergarten.groff 
kindergärten kindergärten kindergärten kindergärten kindergär‐
ten


Looping in original reporter.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #42870] `.hcode' and `.hw' are limited to raw 8bit characters but should accept any characters entities.

2024-07-29 Thread G. Branden Robinson
Follow-up Comment #7, bug #42870 (group groff):

In case anyone's curious, here's a demonstration of "raw 8-bit characters"
working with `hw`.  I know that's not what's complained about but since I'm
digging into this, I thought I would share it.


$ cat EXPERIMENTS/kindergarten-utf8.groff
.if r HW .hw kin-der-gär-ten
.ll 62n
\c
.nr oldline \n[nl]
.while (\n[oldline] = \n[nl]) kindergärten
.pl \n[nl]u
$ iconv -f utf-8 -t iso-8859-1 EXPERIMENTS/kindergarten-utf8.groff >|
EXPERIMENTS/kindergarten.groff
$ ./build/test-groff -T utf8 EXPERIMENTS/kindergarten.groff
kindergärten kindergärten kindergärtenkindergärten
kindergärten
$ ./build/test-groff -r HW=1 -T utf8 EXPERIMENTS/kindergarten.groff
kindergärten kindergärten kindergärten kindergärten kindergär‐
ten




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #42870] `.hcode' and `.hw' are limited to raw 8bit characters but should accept any characters entities.

2024-07-29 Thread G. Branden Robinson
Follow-up Comment #6, bug #42870 (group groff):

(at least for `hcode`)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #42870] `.hcode' and `.hw' are limited to raw 8bit characters but should accept any characters entities.

2024-07-29 Thread G. Branden Robinson
Update of bug #42870 (group groff):

  Status:None => Need Info  

___

Follow-up Comment #5:


[comment #0 original submission:]
> `.hcode' and `.hw' are limited to raw 8bit characters.

This doesn't seem to be the case?


c65ea0c8fb tmac/ps.tmac (Werner LEMBERG  2003-12-22 10:49:55 +  68)
.fchar \[S ,] \o'S\[ac]'
c65ea0c8fb tmac/ps.tmac (Werner LEMBERG  2003-12-22 10:49:55 +  69)
.hcode \[S ,]s
c65ea0c8fb tmac/ps.tmac (Werner LEMBERG  2003-12-22 10:49:55 +  70)
.fchar \[s ,] \o's\[ac]'
c65ea0c8fb tmac/ps.tmac (Werner LEMBERG  2003-12-22 10:49:55 +  71)
.hcode \[s ,]s




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66040] [troff] no longer warns about unrecognized .hcode input

2024-07-29 Thread G. Branden Robinson
Update of bug #66040 (group groff):

  Status:None => Confirmed  
 Assigned to:None => gbranden   

___

Follow-up Comment #2:

Some "improvement"!  :-O


0f49e6b5ee1ec575ed42e55be388009a16320516 is the first bad commit
commit 0f49e6b5ee1ec575ed42e55be388009a16320516
Author: G. Branden Robinson 
Date:   Wed Nov 29 14:20:22 2023 -0600

[troff]: Improve `hcode` request validation.

* src/roff/troff/input.cpp (set_hyphenation_codes): Throw warning
  diagnostic if no arguments supplied.  Throw error diagnostic if there
  are an odd number of arguments.  Check second arguments of pairs for
  nonsense.

Also:
* Annotate null pointers with `nullptr` comment to ease any future
  transition to C++11, which defines it as a keyword.
* Reorder comparison to avoid inadvertent lvalue assignment.

Input:
$ nl hcode.groff
 1  .hcode
 2  .hcode \:
 3  .hcode a
 4  .hcode a\:
 5  .hcode aA

Before:
$ groff -ww hcode.groff
troff:hcode.groff:2: error: expected ordinary or special character, got an
escaped ':'
troff:hcode.groff:3: error: hyphenation code must be ordinary character
troff:hcode.groff:4: error: hyphenation code must be ordinary character

After:
$ ./build/test-groff -ww hcode.groff
troff:hcode.groff:1: warning: hyphenation code configuration request
expects arguments
troff:hcode.groff:2: error: expected ordinary or special character, got an
escaped ':'
troff:hcode.groff:3: error: hyphenation codes must be specified in pairs
troff:hcode.groff:4: error: expected ordinary or special character, got an
escaped ':'

 ChangeLog|  9 +
 src/roff/troff/input.cpp | 19 ---
 2 files changed, 25 insertions(+), 3 deletions(-)




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66040>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66040] [troff] no longer warns about unrecognized .hcode input

2024-07-29 Thread G. Branden Robinson
Update of bug #66040 (group groff):

 Summary: groff no longer warns about unrecognized .hcode
input => [troff] no longer warns about unrecognized .hcode input

___

Follow-up Comment #1:

Goodness.  It's against my ethos to kill off a valid diagnostic message.  ;-)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66038] [troff] want "invalid line length" diagnostic to quote user input

2024-07-29 Thread G. Branden Robinson
Follow-up Comment #2, bug #66038 (group groff):

I did not note in comment #1, but probably should have, that I belabored the
term "numerical expression" because while the easiest thing to think about it
is likely input such as the following...


.ll 78n
.pl 11i


These really are numeric _expressions_ and can be as complex as _groff_
arithmetic syntax allows, which is pretty darned complex, complete with
Boolean "and" and "or" operators, and bizarre stuff unfamiliar to C
programmers like the implicit scaling operator ';' and the boundary-relative
motion operator '|', which works everywhere, even where it makes no sense.


$ nroff 

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66038] [troff] want "invalid line length" diagnostic to quote user input

2024-07-29 Thread G. Branden Robinson
Update of bug #66038 (group groff):

Severity:   2 - Minor => 1 - Wish   
 Summary: "invalid line length" diagnostic misquotes user
input => [troff] want "invalid line length" diagnostic to quote user input


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66038] "invalid line length" diagnostic misquotes user input

2024-07-29 Thread G. Branden Robinson
Update of bug #66038 (group groff):

  Status:None => Postponed  
 Assigned to:None => gbranden   

___

Follow-up Comment #1:

[comment #0 original submission:]

> $ echo '.ll 12u' | groff -Tascii -ww
> troff::1: warning: invalid line length 0u rounded to device
horizontal motion quantum


> (I have not done a build since
[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=4a1898b70 commit
4a1898b70], a few days ago, changed this warning text.  It also slightly
refactored the test gating the diagnostic.  But it did not change the number
(temp.to_units()) reported by the diagnostic.  So, while I'm not running
bleeding-edge code, I'm reasonably confident the bug is still there.)

I don't think it is feasible to do what you desire here without a major change
to input processing.

You say "misquotes" but the parameter is not quoted, and for good reason.

The diagnostic doesn't know what the numerical expression was at the time the
message is constructed.  Those input characters are dead and gone, eaten by
the numeric expression interpreter in "number.cpp" (with some bits in
"hvunits.h").

When a request (or escape sequence) expects a numeric expression, it hands the
lexing/parsing ball off to the numeric expression interpreter, which is
responsible for consuming characters until it's "done"--has decided that it
has read a complete one.

Functions like `get_hunits()`, seen in the commit you referenced, would in my
opinion be better named `read_hunits()` because they advance the input cursor
(or "pointer to the input stream buffer" if one wants to think of it that
way).

So unfortunately the sort of diagnostics that complains here would have no
idea what to say if it _did_ want to quote the argument.
It would have two choices if it made the attempt: too soon, or too late. 

Setting to "Postponed" status, but it's probably a "Rejected", sorry to say.

Leaving open for comments.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


Re: [PATCH v3] [grotty]: Use terminfo.

2024-07-28 Thread G. Branden Robinson
Hi Lennart,

I composed this back in February but postponed it, and I don't know
remember why.

At 2024-02-26T14:40:53+, Lennart Jablonka wrote:
> Quoth G. Branden Robinson:
> > I'm attaching my progress so far.
> 
> Nice!  I guess I’ll drop a few comments on it.  (Uncommented hunks
> omitted.)

No worries.

> > +const int bufsz = len + sizeof msg1 + sizeof msg2 + 1 /* `\0` */;
> 
> bufsz should be size_t.  len is size_t, the sizeof expressions are
> size_t, and calloc takes size_t.

Yup.  You can tell I'm old, instinctively using an `int` instead of a
proper type.

> > +char *errbuf = static_cast(calloc(bufsz, sizeof (char)));
> > +(void) snprintf(errbuf, bufsz, "%s%s%s", msg1, terminal_type, msg2);
> 
> You could simplify that string handling using any of
>   • snprintf(malloc((size = snprintf(NULL, 0, …))), size, …),
>   • asprintf,
>   • the string class,
>   • the std::string class,

The last is not desirable, I think, until and unless we overhaul groff
to drop its own string class and use std::string _everywhere_.  I
shudder at the potential horrors of mixing up objects of these two
classes.

Apart from that, I dither over when and where to use C strings vs. groff
strings in the code.  I have groped in vain for an organizing principle
that would tell me, apart from "I need to call a standard libc function
that expects a C string".

> but …
> 
> > +const char no_database[] = "terminfo database entry not found";
> > +
> > +switch (err) {
> > +case -1:
> > +  fatal(no_database);
> > +  break;
> > +case 0:
> > +  fatal(errbuf);
> 
> Did I miss something on why you’re allocating the error buffer even if
> never used (err == 1), not freeing it in that case, and introducing a
> bug à la printf(user_input) (when TERM=%)

Insufficient attention on my part, most likely.

> instead of doing:
>
>   fatal("entry for '%1' not found in terminal database", terminal_type);

I'm sure I thought I had a reason at the time, but I don't recollect it
now.

> For the record, I think fatal() should be a simple wrapper for
> vfprintf.

That's not up to grotty.  `fatal()` is defined by libgroff and I would
prefer to land this change with no disturbance to any other part of the
system.  It should be easier to detect and remedy regressions that way.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/libs/libgroff/error.cpp?h=1.23.0#n123

> > +  if (tigetflag("hc")) {
> 
> Why are you using tigetflag instead of accessing the long names
> defined by term.h?  They do seem a little underspecified by X/Open
> Curses, but do exist, both there, somewhat, and in the
> implementations.

1.  I prefer narrow interfaces to broad ones;
2.  It seems clear enough;
3.  It communicates the type of the capability.

On the other hand, I also prefer communicative identifiers to cryptic
ones, and even terminfo codes (_usually_ limited to 5 characters) are on
the cryptic side.

So, not a hill I mean to die on.

> > +// hardcopy terminal
> > +do_sgr_italics = false;
> > +do_reverse_video = false;
> > +
> > +if (want_sgr_italics) {
> > +  if (want_capability_warnings)
> > +   warning("terminal type %1 is incapable of SGR italics",
> > +   terminal_type);
> 
> Above, you 'quoted' terminal_type; here, you don’t.

Good catch--thank you!

Regards,
Branden


signature.asc
Description: PGP signature


Re: hyphenating non-english characters

2024-07-27 Thread G. Branden Robinson
Hi Gáspár,

At 2024-07-27T08:51:32+0200, Gáspár Gergő wrote:
> I'm trying to make justified text look nicer, so I turned to
> hyphenation.

A reasonable desire.

> Hungarian is not supported out of the box by groff, but I found a tex
> patterns file which seems quite good, that is what I tried to use, to
> not much success.

You didn't indicate where the hyphenation pattern file came from
exactly (though its name is suggestive), or attach it, but odds are it's
UTF-8 encoded, and that is a problem for GNU troff in its present state,
which supports only single-byte encodings.  Further, in groff 1.24,
support for the ASCII-incompatible CCSID ["code page"] 1047 will be
withdrawn.  (This matters because UTF-8 is a compatible extension of ISO
646 a.k.a. "ASCII" but not of CCISD 1047.)

https://savannah.gnu.org/bugs/?65724

The good news is that if you convert the hyphenation pattern file to ISO
Latin-2 (ISO 8859-2), you should be able to use it.

> Hyphenation happens, but not as often as I'd hope.  After some more
> reading, I think the problem might be with the accented Hungarian
> characters not having hyphenation codes assigned to them, since
> hyphenation seemingly only happens near non-accented vowels.

That seems likely to me.  The code that reads hyphenation patterns
simply does not expect a multi-byte character encoding.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?h=1.23.0#n3856

> These are the requests that I used for hyphenation originally:
> .hla hu
> .hpf /home/gergo/projekt/jella/huhyphn.tex
> .hy 1

This is good, but incomplete, setup.  As you noted below, `hcode`
requests to assign hyphenation codes to non-ASCII code points are also
necessary.

It will also help to tell GNU troff to use an accurate input character
mapping.

.mso latin2.tmac

I would insert that request before the `hpf` request, and invoke `hcode`
requests _before_ `hpf`, but I will admit I haven't experimented with
arbitrary arrangements of these to see what breaks hyphenation support.

I will say with some confidence that `hla` should come first, because
the hyphenation language is a property of the environment, and is the
way you tell GNU troff which language you'll be defining hyphenation
codes and patterns for.

Due to that property and because you can change environments, it's not
difficult to support multilingual documents that apply appropriate
hyphenation rules to the input language.

> The manual told me that
>
> > A hyphenation code must be an ordinary character (not a special
> > character escape sequence) other than a digit or a space.

Yes.  In groff 1.24, loading "latin2.tmac" is what will _make_ input
characters like ű "ordinary" (otherwise they're out of range and get
warned about).

$ ~/groff-stable/bin/groff --version | head -n 1
GNU groff version 1.23.0
$ printf '\370\n' | ~/groff-stable/bin/groff -a -winput


$ groff --version | head -n 1
GNU groff version 1.23.0.1589-aa44
$ printf '\370\n' | groff -a -winput
troff::1: warning: character with input code 248 not defined

I haven't decided yet but 1.24's default might be to _not_ load
"latin1.tmac", since English is the default language and most English
doesn't need Latin-1 characters, but more importantly to get users into
position for a conversion to UTF-8 support in, I hope, groff 1.25.  I
don't think there is time given current developer resources to get groff
to UTF-8 from end to end in one fell swoop in time for a release this
year, and also, assuming that one is going from an 8-bit character
encoding to UTF-8 leads to mojibake.  Because UTF-8 is compatible with
7-bit ASCII, if groff 1.24 gets people to either (1) use ASCII or (2)
make their documents (or their system, via "troffrc" or similar)
_declare the default encoding they expect_, we can avoid frustrating
them later.

See .

> So I tried following the example, with these requests:
> .hcode á á Á á
> .hcode é é É é
> .hcode í í Í í
> .hcode ó ó Ó ó
> .hcode ö ö Ö ö
> .hcode ő ő Ő ő
> .hcode ú ú Ú ú
> .hcode ü ü Ü ü
> .hcode ű ű Ű ű

I expect that to work if you (1) get the hyphenation patterns recoded to
Latin-2 and (2) load "latin2.tmac" before attempting to format text.

> However, groff throws errors saying "error: hyphenation code must be
> ordinary character".

If you're using groff 1.23 or earlier, I'm a little surprised by this.

If you're using groff Git's master branch of recent vintage, this is
what I would expect.

> I tried with and without preconv to no avail.

preconv(1) is important in general for non-English language support in
groff, but does not apply to this situation because hyphenation pattern
files are parsed independently of text formatting and input processing.

> The example supplied in the manual, with German characters, didn't
> work either.

That is also a surprise, if you're running groff 1.23.  I will attempt
to reproduce this.  In Git, it's not a surprise and is a consequence of
me not getting around 

[bug #66000] [mm] early .CS call makes top page margin wrong thereafter

2024-07-27 Thread G. Branden Robinson
Follow-up Comment #4, bug #66000 (group groff):

[comment #0 original submission:]

> * "Judging by the DWB 3.3 troff manual, this looks like the way the `SG`
macro is supposed to work for memorandum type 0.  Memorandum type 4 should
redefine it to be a no-op.  groff mm's implementation evidently doesn't."
> ** This looks like it was addressed by
[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=774bac73c commit
774bac73c].

There were two parts to the fix.  The machinery, which you cited above, and
the exercise thereof:


commit ad8cd89d4a9be3ca42b25399cff67ae2bb7aaf51
Author: G. Branden Robinson 
Date:   Thu Jun 13 15:04:13 2024 -0500

[mm]: Adjust memorandum type 4 cosmetics.

* contrib/mm/mm/4.MT: Revise to more closely approximate DWB 3.3 troff
  output.  Initialize `let*sg-suppress-all` and `let*ns-suppress` true.

  (cov@print-title): Set document title closer to where DWB 3.3 puts it.
  Stop turning on fill mode unnecessarily.  It should already be on at
  the start of a document.  Save and restore adjustment mode instead of
  clobbering it.

  (cov@print-authors): Space by a full vee mode, before and after
  setting authors in nroff mode, since most nroff devices are incapable
  of the half-line motions used in troff mode.

  (cov@print-firm): Space by two vees before setting the document's
  affiliated firm name.

  (cov@print-abstract): Use mm macros instead of formatter requests to
  change fonts.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66000>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65099] 1.24.0 release goals

2024-07-26 Thread G. Branden Robinson
Update of bug #65099 (group groff):

  Depends on: => bugs #66031


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66031] @g@-ify our Texinfo manual

2024-07-26 Thread G. Branden Robinson
URL:
  <https://savannah.gnu.org/bugs/?66031>

 Summary: @g@-ify our Texinfo manual
   Group: GNU roff
   Submitter: gbranden
   Submitted: Fri 26 Jul 2024 07:01:04 PM UTC
Category: General
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 26 Jul 2024 07:01:04 PM UTC By: G. Branden Robinson 
Now that we generate "doc/groff.texi" from "doc/groff.texi.in" using _sed_(1),
we can apply the `@g@` prefix instead of hard-coding a prefix that will be
wrong for most/all GNU/Linux installations.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66031>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65452] [indxbib] possibly incomplete bounds check after strtol(3)

2024-07-26 Thread G. Branden Robinson
Update of bug #65452 (group groff):

  Status:None => Fixed  
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 
 Planned Release:None => 1.24.0 

___

Follow-up Comment #4:


commit a4fc074b36b2a6054608eb2f7e83d7b5803b8b58
Author: Alejandro Colomar 
Date:   Sat Mar 16 13:35:11 2024 +0100

[indxbib]: Collapse related tests.

* src/utils/indxbib/indxbib.cpp (check_integer_arg): Collapse related
  tests.

Fixes: d7b36a45fc3f ("[indxbib]: Mitigate Savannah #65452.")
Link: <https://savannah.gnu.org/bugs/?65452>
Cc: "G. Branden Robinson" 
Cc: Dave Kemper 
Cc: "James K. Lowden" 
Cc: Colin Watson 
Cc: Werner LEMBERG 
Cc: James Clark 
Signed-off-by: Alejandro Colomar 

commit dcf9bfbef5db9ab0286ac0cda2105616397f91d1
Author: Alejandro Colomar 
Date:   Sat Mar 16 13:35:06 2024 +0100

[indxbib]: Remove dead code.

* src/utils/indxbib/indxbib.cpp (check_integer_arg): Remove dead code.
  The tests (LONG_MAX > INT_MAX && n > INT_MAX) and (n > INT_MAX) are
  equivalent.

Fixes: d7b36a45fc3f ("[indxbib]: Mitigate Savannah #65452.")
Link: <https://savannah.gnu.org/bugs/?65452>
    Link: <https://lists.gnu.org/archive/html/groff/2024-03/msg00065.html>
Cc: "G. Branden Robinson" 
Cc: Dave Kemper 
Cc: "James K. Lowden" 
Cc: Colin Watson 
Cc: Werner LEMBERG 
Cc: James Clark 
Signed-off-by: Alejandro Colomar 

commit 573dcdc12ee01dc476c1c06a8b6fe5c8f9958ad3
Author: Alejandro Colomar 
Date:   Sat Mar 16 13:35:02 2024 +0100

[indxbib]: Clear `errno` before `strotol()` call.

* src/utils/indxbib/indxbib.cpp (check_integer_arg): Clear `errno`
  before calling `strtol()`.  Otherwise, `errno` may hold `ERANGE` from
  before.  See strtol(3).

Fixes: d7b36a45fc3f ("[indxbib]: Mitigate Savannah #65452.")
Link: <https://savannah.gnu.org/bugs/?65452>
Cc: "G. Branden Robinson" 
Cc: Dave Kemper 
Cc: "James K. Lowden" 
Cc: Colin Watson 
Cc: Werner LEMBERG 
Cc: James Clark 
Signed-off-by: Alejandro Colomar 

commit 655ecf086142a676252a385c1c7a8be838ae9f3a
Author: Alejandro Colomar 
Date:   Sat Mar 16 13:34:57 2024 +0100

[indxbib]: Don't `else` after [[noreturn]].

* src/utils/indxbib/indxbib.cpp (check_integer_arg): Don't `else` after
  [[noreturn]].

Fixes: d7b36a45fc3f ("[indxbib]: Mitigate Savannah #65452.")
Link: <https://savannah.gnu.org/bugs/?65452>
Cc: "G. Branden Robinson" 
Cc: Dave Kemper 
Cc: "James K. Lowden" 
Cc: Colin Watson 
Cc: Werner LEMBERG 
Cc: James Clark 
Signed-off-by: Alejandro Colomar 




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65452>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #64301] [troff] susceptible to integer overflow

2024-07-26 Thread G. Branden Robinson
Follow-up Comment #9, bug #64301 (group groff):

[comment #8 comment #8:]
> Comment #6 appears to have been truncated.

A definite hazard with Savannah, I've found, but not the case here.

It was a scribble meant to illustrate the use cases of `pl` and `ll` requests
with gigantic argument values.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


a groff convenience for quoting man pages (was: if source command.sh & set -e issue)

2024-07-26 Thread G. Branden Robinson
Hi Chet,

At 2024-07-26T11:18:57-0400, Chet Ramey wrote:
> The man page says, about this scenario:
> 
> "The  shell  does  not  exit if the command that fails is
>  part of the command list immediately following  a  while
>  or  until  keyword, part of the test following the if or
>  elif reserved words, part of any command executed  in  a
>  &&  or || list except the command following the final &&
>  or ||, any command in a pipeline but the last, or if the
>  command's  return  value is being inverted with !.  If a
>  compound command other than a subshell  returns  a  non-
>  zero  status because a command failed while -e was being
>  ignored, the shell does not exit."

Like you, I frequently have reason to quote man pages to people.  The
adjustment of lines ends up looking a bit weird for people who read
email using a proportional font.[1]  If you're running groff 1.23.0
(released July 2023) on the machine you send email from, you can tell it
to suppress adjustment to both margins on the fly, without changing any
configuration files or defaults.

I have a shell function called "mailman"--merrily colliding with the
name of other software I don't personally use.

# As gman, but format for email.
mailman () {
local cmd=
case "$1" in
(-*)
opts="$opts $1"
shift
;;
esac

set -- $(man -w "$@")
cmd=$(zcat --force "$@" | \
  grog -Tutf8 -b -ww -P -cbou -rU0 -rLL=72n -rHY=0 -dAD=l \
   $opts)
zcat --force "$@" | $cmd | less
}

There are many conveniences packed into that function.  I'm happy to
elaborate further; follow-ups might be better sited on the groff list
than bug-bash.

Regards,
Branden

[1] ...such as those accursed with GMail, which has proudly refused to
support an option for rendering emails in monospace for 20+ years,
because everyone at Google is smarter than you


signature.asc
Description: PGP signature


[bug #55154] [troff] `tr` request has undocumented and inconsistent space-character restrictions

2024-07-25 Thread G. Branden Robinson
Update of bug #55154 (group groff):

Severity:   2 - Minor => 3 - Normal 
  Item Group: Incorrect behaviour => Documentation  

___

Follow-up Comment #18:

Re-"item group"ing as "Documentation".

Behavior changes can be handled in other tickets.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #55154] [troff] `tr` request has undocumented and inconsistent space-character restrictions

2024-07-25 Thread G. Branden Robinson
Update of bug #55154 (group groff):

  Status:   Need Info => Confirmed  
 Assigned to:barx => None   
 Summary: .tr has undocumented and inconsistent
space-character restrictions => [troff] `tr` request has undocumented and
inconsistent space-character restrictions

___

Follow-up Comment #17:

Objective:

Account for all this:

> .tr a
> .tr b\~
> .tr c\
> .tr d\|
> .tr e\^
> .tr f\0
>
> This attempts to translate six alphabetic characters to six
> different types of space characters.  What it does instead is
> accept the first two translations and reject the last four: 

> Does this clarify the status for you?

Yes; thanks, Dave.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #57506] Suspicious "slant" values in devps/TI, devlbp/HI, devlbp/HBI

2024-07-25 Thread G. Branden Robinson
Update of bug #57506 (group groff):

 Assigned to:gbranden => None   

___

Follow-up Comment #17:

Unassigning from self; I don't have answers to Dave's questions in comment
#16.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

2024-07-25 Thread G. Branden Robinson
Follow-up Comment #36, bug #63018 (group groff):

[comment #34 comment #34:]
> [comment #33 comment #33:]
> > This started off as a simple request to give access to Dingbats
> > glyphs via their \[u] names... and then wandered!
>
> I agree, the solution you outline will resolve this bug's complaint.  So
taking this out of Need Info.
> 
> It appears that the files you attached all the way back in comment #5 cover
all this.

Quoting this just so to help it reach the top of mind in this epic ticket.

> > The main wandering was the desire to make the grops fonts to
> > be generated during a groff build, and I have given up on that
> > little beauty, although it is 99% doable.

I agree.  I got some ways toward it prior to _groff_ 1.23.0, but got hung up
on the "artifact management" problem.  A bit of work on "maintainer mode" is
required.  My attempt at that is why [this 
https://git.savannah.gnu.org/cgit/groff.git/tree/FOR-RELEASE?h=1.23.0#n12
exists].  It turned out that the X11 fonts were the easiest to deal with.  Too
bad they're by far the least used (well, maybe they beat out _grolbp_).

> That still seems a worthy long-term goal, though, and I'd hate to toss out
the 99%-of-the-way work you've already put in.  But this should definitely be
a separate ticket: It's not necessary in order to resolve the original
problem, as you note.

[comment #35 comment #35:]

> It might even be bug #65698 (which was spawned from Branden's list of tasks
in comment #13).  Or maybe #65698 is merely a prerequisite for generating the
grops fonts?  I don't have much of a handle on what #65698 is asking for.  (I
did open it, but merely parroting Branden's words.)

Rereading my own words, I'm a little fuzzy myself, even after going back down
to comment #13 for context.

I think the idea is that if the font-description-generating tools are
parameterized somehow as constructed in the Git repository, then we need a
process for building them, and that's what #65698 is about: maintainer-mode
targets for updating _afmtodit_, _hpftodit_, and _tfmtodit_ to contain
whatever refreshable information we want to include in them.

That's a separate task, but likely a prerequiste for...
 
> Branden, do I need to open a separate ticket for this?

Yes, for _different_ maintainer-mode targets that produce font descriptions we
check into the repository and ship in distribution archives describing the
"stock" fonts we expect to support for PostScript, LJ4, and DVI output
devices.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66000] [mm] early .CS call makes top page margin wrong thereafter

2024-07-25 Thread G. Branden Robinson
Follow-up Comment #3, bug #66000 (group groff):

[comment #1 comment #1:]

> I was planning to add an `AFX` macro to permit override of the formatting of
the "affiliated firm" header.  Historical practice is crazily divergent, being
an obvious site for the "[https://www.youtube.com/watch?v=4NomQYQK1bE
Cornflower Blue Icon Effect]".

This, while not quite the topic of this ticket, is done.


commit 54b2b3a8c7871ba36f0fa07118fa7a328c7b8e35
Author: G. Branden Robinson 
Date:   Sun Jul 21 12:36:00 2024 -0500

[mm]: Recognize an `AFX` hook macro.

* contrib/mm/mm/0.MT:
* contrib/mm/mm/4.MT:
* contrib/mm/mm/ms.cov: Call `AFX` hook macro if defined, instead of
  default formatting of affiliated firm.
* contrib/mm/groff_mm.7.man (Macros) : Document facility.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66000>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


Proposed: changes to soelim(1)

2024-07-25 Thread G. Branden Robinson
Dave and I have been discussing a change.

I propose permitting soelim(1) to interpret spaces in a `so` argument
as-is, and supporting `ds`-style leading double-quote removal (allowing
file names that begin with spaces).

Why?

To align with a proposed syntax extension to `so` and other requests in
the formatter.  See bug #65108.

Won't this break compatibility with everybody?

No.  Historically, neither formatters nor soelim programs don't
interpret backslash-escaped spaces as spaces, and in fact soelim
programs traditionally rewrite the first space they encounter in a `so`
argument as a newline (likely putting an undesired partial file name on
the output as formatted text).

See comments 3 and 4 to bug #65108.

Won't this break compatibility with our own users' past documents?

Partially.  If they only ever processed such `so` "requests" with
soelim(1), such that the formatter, troff(1), never saw them, and the
arguments contained backslash-space escape sequences to cause
interpolation of files with spaces in their file names, yes.

If they tried to get the formatter to do this itself, perhaps because
they didn't need a file interpolated during _preprocessing_, they were
disappointed because it didn't work.

The idea here is to make it work, and make it work the same way,
whether soelim(1) is used or not.

soelim(1) will thus be able to interpret arbitrary file names.  See the
bug for details, including the proposed approach to character encoding
challenges.

Please follow-up with feedback and comments here or in bug #66027.

https://savannah.gnu.org/bugs/?65108
https://savannah.gnu.org/bugs/?66027

Regards,
Branden

P.S.  Anyone think soelim(1) should be refusing to open file names with
  slashes in them by default, and should accept a `-U` option to
  override that restriction?


signature.asc
Description: PGP signature


[bug #66027] [soelim] stop requiring spaces to be backslash-escaped, and strip leading double quote

2024-07-25 Thread G. Branden Robinson
Update of bug #66027 (group groff):

  Depends on: => bugs #65108


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66027] [soelim] stop requiring spaces to be backslash-escaped, and strip leading double quote

2024-07-25 Thread G. Branden Robinson
URL:
  <https://savannah.gnu.org/bugs/?66027>

 Summary: [soelim] stop requiring spaces to be
backslash-escaped, and strip leading double quote
   Group: GNU roff
   Submitter: gbranden
   Submitted: Fri 26 Jul 2024 03:48:54 AM UTC
Category: Preprocessor soelim
Severity: 1 - Wish
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 26 Jul 2024 03:48:54 AM UTC By: G. Branden Robinson 
I propose permitting `soelim` to interpret spaces in a `so` argument as-is,
and supporting `ds`-style leading double-quote removal (allowing file names
that begin with spaces).

Why?

To align with a proposed syntax extension to `so` and other requests in the
formatter.  See bug #65108.

Won't this break compatibility with everybody?

No.  Historically, neither formatters nor _soelim_ programs don't interpret
backslash-escaped spaces as spaces, and in fact _soelim_ programs
traditionally rewrite the first space they encounter in a `so` argument as a
newline (likely putting an undesired partial file name on the output as
formatted text).

See comments 3 and 4 to bug #65108.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66027>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


Behavior change: no more nonpositive page lengths

2024-07-25 Thread G. Branden Robinson
I ended up pretty tightly constrained with my work on checked arithmetic
(itself a precursor to saturating arithmetic),[1] so I thought I should
advise regarding a non-backward-compatible change I've pushed to HEAD.

(Before anyone goes pale, this has nothing to do with a nonpositive
_vertical drawing position_, which is valid, useful, and fairly well
understood.)

A nonpositive page length, you may ask?

As far as I know, only GNU troff has ever documented what that means.

It's basically a combination of

.vpt 0

and

.pl 1v

...except a page actually _is_ ejected after every output line.
(An actual `.vpt 0` request prevents page ejection.)

Consider the following input document.

$ cat EXPERIMENTS/negative-page-length.roff
.pl 0-1
Sed ut perspiciatis, unde omnis iste natus error sit voluptatem
accusantium doloremque laudantium, totam rem aperiam eaque ipsa, quae ab
illo inventore veritatis et quasi architecto beatae vitae dicta sunt,
explicabo.  Nemo enim ipsam voluptatem, quia voluptas sit, aspernatur
aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione
voluptatem sequi nesciunt, neque porro quisquam est, qui dolorem ipsum,
quia dolor sit amet consectetur adipiscivelit, sed quia non-numquam eius
modi tempora incidunt, ut labore et dolore magnam aliquam quaerat
voluptatem.

$ ~/groff-stable/bin/groff --version | head -n 1
GNU groff version 1.23.0
$ ~/groff-stable/bin/groff -T ascii -aww EXPERIMENTS/negative-page-length.roff

Sed ut perspiciatis, unde omnis iste natus error sit voluptatem

accusantium doloremque laudantium, totam rem aperiam eaque ipsa,

quae ab illo inventore veritatis et quasi architecto beatae vitae

dicta sunt, explicabo. Nemo enim ipsam voluptatem, quia voluptas

sit, aspernatur aut odit aut fugit, sed quia consequuntur magni

dolores eos, qui ratione voluptatem sequi nesciunt, neque porro

quisquam est, qui dolorem ipsum, quia dolor sit amet consectetur

adipiscivelit, sed quia non-numquam eius modi tempora incidunt,

ut labore et dolore magnam aliquam quaerat voluptatem.

GNU troff does this is both nroff and troff modes.  DWB and Heirloom
Doctools nroff seem to ignore a nonpositive page length completely (as
bleeding-edge GNU troff now does).

$ ./bin/nroff negative-page-length.roff \" Heirloom
Sed ut perspiciatis, unde omnis iste natus error  sit  voluptatem
accusantium  doloremque laudantium, totam rem aperiam eaque ipsa,
quae ab illo inventore veritatis et quasi architecto beatae vitae
dicta sunt, explicabo.  Nemo enim ipsam voluptatem, quia voluptas
sit, aspernatur aut odit aut fugit, sed quia  consequuntur  magni
dolores  eos,  qui ratione voluptatem sequi nesciunt, neque porro
quisquam est, qui dolorem ipsum, quia dolor sit amet  consectetur
adipiscivelit,  sed  quia non-numquam eius modi tempora incidunt,
ut labore et dolore magnam aliquam quaerat voluptatem.
$ DWBHOME=. ./bin/nroff negative-page-length.roff
Sed ut perspiciatis, unde omnis iste natus error  sit  voluptatem
accusantium  doloremque laudantium, totam rem aperiam eaque ipsa,
quae ab illo inventore veritatis et quasi architecto beatae vitae
dicta sunt, explicabo.  Nemo enim ipsam voluptatem, quia voluptas
sit, aspernatur aut odit aut fugit, sed quia  consequuntur  magni
dolores  eos,  qui ratione voluptatem sequi nesciunt, neque porro
quisquam est, qui dolorem ipsum, quia dolor sit amet  consectetur
adipiscivelit,  sed  quia non-numquam eius modi tempora incidunt,
ut labore et dolore magnam aliquam quaerat voluptatem.

I consequently expect that this feature is more a case of Hyrum's Law,
something wizards of high troff sorcery discovered ages ago but which
was never officially countenanced until Werner Lemberg made an "XXX"
comment about it in the groff Texinfo manual in commit a947dc5443, 19
May 2000, and I eventually documented it in commit 9be6acf926, 29 May
2023.  (I don't remember doing that.  And I missed that a page length of
zero works the same way.)

So, since it was seemingly never documented anywhere until very
recently,[2] and isn't portable across troff and nroff formatters
anyway, I figured no one would weep too much if it went away.

Let the list know if you need a replacement feature.

Here's the commit, minus the ChangeLog entry and code change.

commit a00682e9cb4070e35139f6df59130d9ce12505ce
Author: G. Branden Robinson 
Date:   Thu Jul 25 15:20:55 2024 -0500

[troff]: Enforce minimum page length.

* src/roff/troff/div.cpp (page_length): Clamp `pl` request argument to
  the output device's vertical resolution (similarly to the way `ll` and
  `lt` behave).

* doc/groff.texi.in (Page Layout):
* NEWS: Document this.

[...]

diff --git a/NEWS b/NEWS
index 90a1646ad..c89f4b55b 100644
--- a/NEWS
+++ b/NEWS
@@ -22,6 +22,11 @@ o The `mso` request no longer attempts to open a macro file 
named, say,
   simply processes the macro search path for a file name matching the
   request argument, and succeeds or fails depending on an exact match

[bug #65108] [troff] support construction of general file name request arguments

2024-07-25 Thread G. Branden Robinson
Follow-up Comment #9, bug #65108 (group groff):


[comment #5 comment #5:]
> So I'm not sure whether or not you advocate retaining soelim's current
escape mechanism.  Maybe you're not yet either.

It's a question that tempts me to dither.
 
> My suggestion in comment #2 that support for soelim's escapes might need to
be dropped was based my concern that one syntax requiring backslashes for
spaces and one not would result in ambiguities in representing edge-case
filenames, such as ones containing a backslash followed by a space.  But I
think you've eliminated this possibility by not allowing a bare backslash to
represent itself, requiring it be doubled if the filename contains a
backslash.  (What miscreant named this file anyway?)

Right.

> But if soelim _is_ changed to no longer recognize "\ ", then rule 5a is
unnecessary and even a little counterintuitive.

Agreed.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65108] [troff] support construction of general file name request arguments

2024-07-25 Thread G. Branden Robinson
Follow-up Comment #8, bug #65108 (group groff):

[comment #7 comment #7:]
> One additional comment on the proposal:
> 
> [comment #3 comment #3:]
> > Only codes in the range 00-1F and 80-FF are accepted in
> > [`\[u00XX]`] syntax; those in the range 20-7F are ignored with a
> > diagnostic advising the user to deobfuscate their inputs.
> 
> I realize there's no good reason for a user to type "\[u0045]" instead of
"E"

There may in fact be one.  It could be a means of obtaining an ordinary
character (or the handful of special characters in Unicode Basic Latin) when
said characters in their conventional forms are at that time subject to `tr`
translation.

I don't know if this is feasible, as I still haven't mastered the
character-to-glyph resolution process. 
[https://www.gnu.org/software/groff/manual/groff.html.node/Using-Symbols.html#Using-Symbols
It's one of the more complex aspects of the formatter.]
  
> ... but at the same time there seems no reason for groff to object to it. 
It's ugly but not ambiguous or any harder to parse than the accepted ranges;
if anything, a diagnostic seems to complicate the code, which could otherwise
handle every \[u00XX] the same way.
> 
> Even if you're wedded to the diagnostic, I'd say at least process the
character.  Ignoring it seems needlessly punitive.

I have a very tall prescription pad.  But I'll hold my fire for now.  :)

> (Taking ticket out of "Need Info" assuming comment #5 addressed your
questions; let me know if I've overlooked anything.)

That's fine.

I think this is just waiting on me now to start implementing and decide:

A.  what to do about `\ ` in GNU _soelim_ and _troff_.
B.  whether to accept `\[u0021]` (or `\[u0020`?) through `\[u007E]` (or
`\[u007F]`?)
C.  if the answer to "B" is "yes", whether to warn about them


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65099] 1.24.0 release goals

2024-07-25 Thread G. Branden Robinson
Follow-up Comment #5, bug #65099 (group groff):

[comment #4 comment #4:]
> I submit bug #63827 as something that should be addressed in some manner
before release, even if only in the form of a stopgap like resyncing groff's
pdfmark subtree with the substantially updated code upstream.

It's on the dependency list.

If the bugs dependent on bug #66001 (saturating arithmetic) fall swiftly
enough, bug #61453 might be worth adding as a goal.  It feels thematically
related.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #61453] want native mechanism for continuous (non-paginated) rendering

2024-07-25 Thread G. Branden Robinson
Follow-up Comment #11, bug #61453 (group groff):

[comment #10 comment #10:]
> [comment #7 comment #7:]
> > I'm a little nervous of meddling with the semantics of a
> > negative page length given the potential for interaction with
> > negative vertical drawing positions.
> 
> There seem to be (at least) two ways to implement this.  When the user
specifies ".pl -1", the code can either:
> 
> 0 Store -1 as the page length.

I've just foreclosed this possibility (not because of this ticket, but because
it was [https://savannah.gnu.org/bugs/?64301 causing me headaches with
trapping arithmetic]).


commit a00682e9cb4070e35139f6df59130d9ce12505ce
Author: G. Branden Robinson 
Date:   Thu Jul 25 15:20:55 2024 -0500

[troff]: Enforce minimum page length.

* src/roff/troff/div.cpp (page_length): Clamp `pl` request argument to
  the output device's vertical resolution (similarly to the way `ll` and
  `lt` behave).

* doc/groff.texi.in (Page Layout):
* NEWS: Document this.


> 0 Set a new flag that indicates page-length handling is to be disregarded. 
Any code that compares against page length is made conditional on this flag
being unset.

This remains completely feasible.

> In many cases, implementation 1 may automatically do what's desired without
further code change.  But this raises your concern about interaction with
negative vertical drawing positions.

I have no intention of invalidating negative vertical drawing positions. 
Setting the `nl` register to `-1` to force a re-spring of a trap at vertical
position 0 is well established.  There are more exotic applications like
drawing an arc with its center off the page.
 
> Implementation 2 is a more invasive change.  But because it skips
page-length checking altogether, it avoids the prior concern.

Not terribly invasive, I think.  This would be a property of the top-level
diversion and no other formatter object I can think of.  That's also the only
thing that has page location traps in the first place, so I don't foresee any
problems with symbol visibility.  Possibly, all the changes that this feature
needs can be made to "div.cpp".


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61453>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


Re: [MOM[ unexpected behaviour when using blockquotes with two columns

2024-07-25 Thread G. Branden Robinson
At 2023-11-16T14:11:29-0500, Peter Schaffter wrote:
> On Thu, Nov 16, 2023, hbeze...@kliksafe.nl wrote:
> > 2. In groff_mom there's a link to the local html manual
> > (/usr/share/doc/ groff-1.23.0/html/mom/toc.html), but most recent
> > version of Groff on Arch Linux doesn't include the html pages, at
> > least not where the points to.
> 
> Branden?  Anyone?

I don't generally have deep insight into what packaging decisions
distributors make (what knowledge I acquire is mostly a side effect of
looking for bug reports, official or otherwise, against groff).

But this one, after several months, I think I can throw some light on.

Arch is apparently not in the habit of shipping mom's HTML
documentation.

They have a ticket about this.

https://gitlab.archlinux.org/archlinux/packaging/packages/groff/-/issues/1

Regards,
Branden


signature.asc
Description: PGP signature


[bug #64301] [troff] susceptible to integer overflow

2024-07-25 Thread G. Branden Robinson
Update of bug #64301 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #7:


commit a3e0a4fe337a1482410a307180825e55c0fc0869
Author: G. Branden Robinson 
Date:   Thu Jul 25 15:10:39 2024 -0500

src/roff/troff/number.cpp: Fix Savannah #64301.

* src/roff/troff/number.cpp (vunits::vunits, hunits::hunits): Migrate to
  C23 checked arithmetic macros.  Throw error if addition overflows.

Fixes <https://savannah.gnu.org/bugs/?64301>.  (For real this time,
fingers crossed.)

commit a7687009739feb5592f33de6e6a3573bae7fc349
Author: G. Branden Robinson 
Date:   Thu Jul 25 08:22:33 2024 -0500

[troff]: Add more tests of arithmetic.

* src/roff/groff/tests/arithmetic-works.sh: Add more tests.

Test fails at this commit.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64301>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65138] [troff] `device` request silently fails before first page begins

2024-07-25 Thread G. Branden Robinson
Update of bug #65138 (group groff):

  Status: In Progress => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #5:


commit 5be9a9cd0e177d9bcea8b03a68c8a711c16cf31e
Author: G. Branden Robinson 
Date:   Sun Jul 21 17:47:19 2024 -0500

Revert "[docs]: Fix Savannah #65118 (`device` behavior)."

This reverts commit c8935f2361b44414be83a34f5e7e4b2ad57cd8b2.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65138>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66006] [grog] Identifies .TS .TH .TE as a -man document

2024-07-25 Thread G. Branden Robinson
Update of bug #66006 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.24.0 

___

Follow-up Comment #4:


commit 6fa8faab78f5a802e87483aae2fdc2834e4130af
Author: G. Branden Robinson 
Date:   Sat Jul 20 14:26:02 2024 -0500

[grog]: Fix Savannah #66006 (TS/TH/TE -> "-man").

* src/utils/grog/grog.pl (interpret_line): Fix logic error; set Boolean
  scalar `have_seen_first_macro_call` _after_ testing it, not before,
  avoiding its tautological truth.  (infer_man_or_ms_package): Drop `TH`
  from list of "unique" man(7) macro names.  It isn't; most full-service
  macro packages use it to manage tbl(1) headings, and we already have
  special logic for handling it as the first call in a page anyway
  (where it is overwhelmingly idiomatic of a man(7) document).

Fixes <https://savannah.gnu.org/bugs/?66006>.  Thanks to Morten Bo
Johansen for the report.

commit 3b5626f5ef53810451d0874d918f86581d964bbb
Author: G. Branden Robinson 
Date:   Sat Jul 20 12:00:19 2024 -0500

[grog]: Regression-test Savannah #66006.

* src/utils/grog/tests/avoid-man-fakeout.sh: Do it.
* src/utils/grog/grog.am (grog_TESTS): Run test.

Test fails at this commit.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66006>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #66009] [troff] accepts `|` as operand delimiter, but should not

2024-07-25 Thread G. Branden Robinson
Update of bug #66009 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.24.0 

___

Follow-up Comment #1:


commit b0dfb7901897eed5f54b64557be72263bd670245
Author: G. Branden Robinson 
Date:   Sat Jul 20 16:15:45 2024 -0500

[docs]: Note prohibition of `|` as a delimiter.

commit c8625529c8e8c565522460c8d57182a9beb0c24c
Author: G. Branden Robinson 
Date:   Sat Jul 20 16:10:45 2024 -0500

[troff]: Fix Savannah #66009 (`|` not delimiter).

* src/roff/troff/input.cpp (is_char_usable_as_delimiter): Reject `|`.

Fixes <https://savannah.gnu.org/bugs/?66009>.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66009>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[groff] 15/21: src/roff/troff/number.cpp: Slightly refactor.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 05bcb560c8337e7b417c9d3497199ca20fe13bc1
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 14:31:39 2024 -0500

src/roff/troff/number.cpp: Slightly refactor.

* src/roff/troff/number.cpp (vunits::vunits, hunits::hunits): Move
  common subexpression to a temporary variable to prepare for reuse in
  C23 checked artihmetic macros.
---
 ChangeLog |  6 ++
 src/roff/troff/number.cpp | 20 
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a20737e48..88d6cd3be 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-07-25  G. Branden Robinson 
+
+   * src/roff/troff/number.cpp (vunits::vunits, hunits::hunits):
+   Move common subexpression to a temporary variable to prepare for
+   reuse in C23 checked artihmetic macros.
+
 2024-07-25  G. Branden Robinson 
 
[troff]: Enforce minimum page length.
diff --git a/src/roff/troff/number.cpp b/src/roff/troff/number.cpp
index a82a4eeda..7f43c0772 100644
--- a/src/roff/troff/number.cpp
+++ b/src/roff/troff/number.cpp
@@ -656,24 +656,28 @@ units scale(units n, units x, units y)
 
 vunits::vunits(units x)
 {
-  // Don't depend on rounding direction when dividing negative integers.
   if (vresolution == 1)
 n = x;
-  else
+  else {
+// Don't depend on rounding direction when dividing neg integers.
+int vcrement = (vresolution / 2) - 1;
 n = (x < 0
-? -((-x + (vresolution / 2) - 1) / vresolution)
-: (x + (vresolution / 2) - 1) / vresolution);
+? -((-x + vcrement) / vresolution)
+: (x + vcrement) / vresolution);
+  }
 }
 
 hunits::hunits(units x)
 {
-  // Don't depend on rounding direction when dividing negative integers.
   if (hresolution == 1)
 n = x;
-  else
+  else {
+// Don't depend on rounding direction when dividing neg integers.
+int hcrement = (hresolution / 2) - 1;
 n = (x < 0
-? -((-x + (hresolution / 2) - 1) / hresolution)
-: (x + (hresolution / 2) - 1) / hresolution);
+? -((-x + hcrement) / hresolution)
+: (x + hcrement) / hresolution);
+  }
 }
 
 // Local Variables:

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 14/21: [troff]: Enforce minimum page length.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit a00682e9cb4070e35139f6df59130d9ce12505ce
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 15:20:55 2024 -0500

[troff]: Enforce minimum page length.

* src/roff/troff/div.cpp (page_length): Clamp `pl` request argument to
  the output device's vertical resolution (similarly to the way `ll` and
  `lt` behave).

* doc/groff.texi.in (Page Layout):
* NEWS: Document this.
---
 ChangeLog  | 11 +++
 NEWS   |  5 +
 doc/groff.texi.in  | 12 ++--
 src/roff/troff/div.cpp | 13 ++---
 4 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 79882167f..a20737e48 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2024-07-25  G. Branden Robinson 
+
+   [troff]: Enforce minimum page length.
+
+   * src/roff/troff/div.cpp (page_length): Clamp `pl` request
+   argument to the output device's vertical resolution (similarly
+   to the way `ll` and `lt` behave).
+
+   * doc/groff.texi.in (Page Layout):
+   * NEWS: Document this.
+
 2024-07-25  G. Branden Robinson 
 
* src/roff/troff/env.cpp (line_length, title_length): Drop use
diff --git a/NEWS b/NEWS
index 90a1646ad..c89f4b55b 100644
--- a/NEWS
+++ b/NEWS
@@ -22,6 +22,11 @@ o The `mso` request no longer attempts to open a macro file 
named, say,
   simply processes the macro search path for a file name matching the
   request argument, and succeeds or fails depending on an exact match.
 
+o GNU troff no longer accepts nonpositive page lengths.  Attempting to
+  set one with the `pl` request clamps the page length to the vertical
+  motion quantum as `ll` does with the horizontal motion quantum in AT
+  and GNU troffs.
+
 o The `color`, `cp`, `linetabs`, and `vpt` requests now interpret
   arguments with negative values as instructions to disable the
   corresponding feature, using the *roff integer-to-Boolean conversion
diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 18aff8d8c..1ea82341d 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -10096,12 +10096,12 @@ The formatter permits configuration of the page 
length and page number.
 @cindex configuring the page length (@code{pl})
 @cindex setting the page length (@code{pl})
 Change (increase or decrease) the page length per the numeric expression
-@var{length}.  The default scaling unit is @samp{v}.  A negative
-@var{length} is valid, but an uncommon application:@: it prevents page
-location traps from being sprung,@footnote{@xref{Traps}.} and each
-output line is placed on a new page.  If @var{length} is invalid, GNU
-@code{troff} emits a warning in category @samp{number}.  If @var{length}
-is absent or invalid, @samp{11i} is assumed.
+@var{length}.  The default scaling unit is @samp{v}.  If @var{length} is
+invalid, GNU @code{troff} emits a warning in category @samp{number}.  If
+@var{length} is absent or invalid, @samp{11i} is assumed.  If
+@var{length} is nonpositive, GNU @command{troff} emits a warning in
+category @samp{range} and sets the page length to the device's vertical
+motion quantum; recall @ref{Motion Quanta}.
 
 @cindex page length register (@code{.p})
 The read-only register @samp{.p} interpolates the current page length.
diff --git a/src/roff/troff/div.cpp b/src/roff/troff/div.cpp
index 83f10e7bc..5b352a315 100644
--- a/src/roff/troff/div.cpp
+++ b/src/roff/troff/div.cpp
@@ -701,9 +701,16 @@ void page_offset()
 
 void page_length()
 {
-  vunits n;
-  if (has_arg() && get_vunits(, 'v', topdiv->get_page_length()))
-topdiv->set_page_length(n);
+  vunits temp;
+  if (has_arg() && get_vunits(, 'v', topdiv->get_page_length())) {
+if (temp < vresolution) {
+  warning(WARN_RANGE, "setting invalid page length %1u to device"
+ " vertical motion quantum",
+ temp.to_units());
+  temp = vresolution;
+}
+topdiv->set_page_length(temp);
+  }
   else
 topdiv->set_page_length(11*units_per_inch);
   skip_line();

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 09/21: doc/groff.texi.in: Fix unaligned example comments.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 87f6c37bf19e67ec7e105787b8b196567268b4c1
Author: G. Branden Robinson 
AuthorDate: Wed Jul 24 14:14:07 2024 -0500

doc/groff.texi.in: Fix unaligned example comments.
---
 doc/groff.texi.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 23ea7829e..01777b98e 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -14817,8 +14817,8 @@ and the page number character @samp{%} used with the 
@code{tl} request.
 .  tl ''%''
 .  bp
 ..
-.wh 0   hd \" trap at top of the page
-.wh -1i fo \" trap 1 inch from bottom
+.wh 0   hd  \" trap at top of the page
+.wh -1i fo  \" trap 1 inch from bottom
 @endExample
 
 To use these traps, copy the above (or load it from a file with the

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 21/21: [troff]: Fix misleading assertion messages.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit aa443ed776dc6b4851dc8671ba6c6345ddf7f5a9
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 15:52:39 2024 -0500

[troff]: Fix misleading assertion messages.

* src/roff/troff/number.cpp (get_vunits, get_hunits, get_number)
  (get_integer): Align assertion error messages with function names.
---
 ChangeLog | 6 ++
 src/roff/troff/number.cpp | 8 
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 064d965f1..751d40c90 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-07-25  G. Branden Robinson 
+
+   * src/roff/troff/number.cpp (get_vunits, get_hunits, get_number)
+   (get_integer): Align assertion error messages with function
+   names.
+
 2024-07-25  G. Branden Robinson 
 
* src/roff/troff/number.cpp (is_valid_expression_start): Fix
diff --git a/src/roff/troff/number.cpp b/src/roff/troff/number.cpp
index da61b1a92..bfa9518db 100644
--- a/src/roff/troff/number.cpp
+++ b/src/roff/troff/number.cpp
@@ -138,7 +138,7 @@ bool get_vunits(vunits *res, unsigned char si, vunits 
prev_value)
 *res = i;
 break;
   default:
-assert(0 == "unhandled case returned by get_incr_number()");
+assert(0 == "unhandled case in get_vunits()");
   }
   return true;
 }
@@ -166,7 +166,7 @@ bool get_hunits(hunits *res, unsigned char si, hunits 
prev_value)
 *res = i;
 break;
   default:
-assert(0 == "unhandled case returned by get_incr_number()");
+assert(0 == "unhandled case in get_hunits()");
   }
   return true;
 }
@@ -189,7 +189,7 @@ bool get_number(units *res, unsigned char si, units 
prev_value)
   error("integer subtraction wrapped");
 break;
   default:
-assert(0 == "unhandled case returned by get_incr_number()");
+assert(0 == "unhandled case in get_number()");
   }
   return true;
 }
@@ -212,7 +212,7 @@ bool get_integer(int *res, int prev_value)
   error("integer subtraction wrapped");
 break;
   default:
-assert(0 == "unhandled case returned by get_incr_number()");
+assert(0 == "unhandled case in get_integer()");
   }
   return true;
 }

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 05/21: [grog]: Regression-test Savannah #66006.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 3b5626f5ef53810451d0874d918f86581d964bbb
Author: G. Branden Robinson 
AuthorDate: Sat Jul 20 12:00:19 2024 -0500

[grog]: Regression-test Savannah #66006.

* src/utils/grog/tests/avoid-man-fakeout.sh: Do it.
* src/utils/grog/grog.am (grog_TESTS): Run test.

Test fails at this commit.
---
 ChangeLog |  7 +
 src/utils/grog/grog.am|  1 +
 src/utils/grog/tests/avoid-man-fakeout.sh | 43 +++
 3 files changed, 51 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index b53aed0e5..2d41dea84 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2024-07-20  G. Branden Robinson 
+
+   Regression-test Savannah #66006.
+
+   * src/utils/grog/tests/avoid-man-fakeout.sh: Do it.
+   * src/utils/grog/grog.am (grog_TESTS): Run test.
+
 2024-07-20  G. Branden Robinson 
 
* src/roff/troff/input.cpp (is_char_usable_as_delimiter): Reject
diff --git a/src/utils/grog/grog.am b/src/utils/grog/grog.am
index 2c3fcf05e..84616c04c 100644
--- a/src/utils/grog/grog.am
+++ b/src/utils/grog/grog.am
@@ -35,6 +35,7 @@ grog: $(grog_srcdir)/grog.pl $(SH_DEPS_SED_SCRIPT)
 
 grog_TESTS = \
   src/utils/grog/tests/PF-does-not-start-pic-region.sh \
+  src/utils/grog/tests/avoid-man-fakeout.sh \
   src/utils/grog/tests/avoid-refer-fakeout.sh \
   src/utils/grog/tests/detect-chem.sh \
   src/utils/grog/tests/preserve-groff-options.sh \
diff --git a/src/utils/grog/tests/avoid-man-fakeout.sh 
b/src/utils/grog/tests/avoid-man-fakeout.sh
new file mode 100755
index 0..5fa7171ae
--- /dev/null
+++ b/src/utils/grog/tests/avoid-man-fakeout.sh
@@ -0,0 +1,43 @@
+#!/bin/sh
+#
+# Copyright (C) 2024 Free Software Foundation, Inc.
+#
+# This file is part of groff.
+#
+# groff is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free
+# Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# groff is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+# for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+
+grog="${abs_top_builddir:-.}/grog"
+
+# Regression-test Savannah #66006.
+#
+# Don't confuse input that uses `TH` inside tbl(1) regions for man(7)
+# documents.
+
+input='.
+.TS
+tab(@)
+L L.
+Heading 1@Heading 2
+.TH
+datum 1@datum 2
+datum 3@datum 4
+.TE
+.'
+
+output=$(echo "$input" | "$grog")
+echo "$output"
+echo "$output" | grep -Fqx 'groff -t -'
+
+# vim:set ai et sw=4 ts=4 tw=72:

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 04/21: [docs]: Note prohibition of `|` as a delimiter.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit b0dfb7901897eed5f54b64557be72263bd670245
Author: G. Branden Robinson 
AuthorDate: Sat Jul 20 16:15:45 2024 -0500

[docs]: Note prohibition of `|` as a delimiter.
---
 doc/groff.texi.in | 7 ---
 man/groff.7.man   | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 5fa2f9c75..5c59b2c1a 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -7223,8 +7223,8 @@ Some escape sequences that require parameters use 
delimiters.  The
 neutral apostrophe @code{'} is a popular choice and shown in this
 document.  The neutral double quote @code{"} is also commonly seen.
 Letters, numerals, and leaders can be used.  Punctuation characters
-are likely better choices, except for those defined as infix operators
-in numeric expressions; see below.
+are likely better choices, except for those defined as operators in
+numeric expressions; see below.
 
 @Example
 \l'1.5i\[bu]' \" draw 1.5 inches of bullet glyphs
@@ -7335,9 +7335,10 @@ the numerals @code{0}-@code{9} and the decimal point 
@code{.}
 @ifinfo
 @cindex , as delimiter
 @end ifinfo
+@cindex @code{|}, as delimiter
 @cindex @code{(}, as delimiter
 @cindex @code{)}, as delimiter
-the (single-character) operators @samp{+-/*%<>=&:()}
+the (single-character) operators @samp{+-/*%<>=&:()|}
 
 @item
 @cindex space character, as delimiter
diff --git a/man/groff.7.man b/man/groff.7.man
index 78da627a2..eead32590 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -1832,7 +1832,7 @@ the numerals 0\[en]9 and the decimal point
 .
 .IP \[bu]
 the (single-character) operators
-.B +\-/*%<>=&:()
+.B +\-/*%<>=&:()|
 .
 .
 .IP \[bu]

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 13/21: [troff]: Slightly refactor.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 4a1898b70ed550c1c088fd6281fe4672de82a5d1
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 15:17:37 2024 -0500

[troff]: Slightly refactor.

* src/roff/troff/env.cpp (line_length, title_length): Drop use of
  needless temporary variable `minimum_length`.  Use global variable
  `hresolution` instead of static class member variable `font::hor`.
  Clarify wording of warning diagnostic message when (title) line length
  invalid.
---
 ChangeLog  |  8 
 src/roff/troff/env.cpp | 20 ++--
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index eb4ea86d1..79882167f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-07-25  G. Branden Robinson 
+
+   * src/roff/troff/env.cpp (line_length, title_length): Drop use
+   of needless temporary variable `minimum_length`.  Use global
+   variable `hresolution` instead of static class member variable
+   `font::hor`.  Clarify wording of warning diagnostic message when
+   {title} line length invalid.
+
 2024-07-20  G. Branden Robinson 
 
* src/utils/grog/grog.pl (interpret_line): Fix logic error; set
diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index 5186f987e..6c443a3a9 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -1433,12 +1433,12 @@ void right_justify()
 void line_length()
 {
   hunits temp;
-  hunits minimum_length = font::hor;
   if (has_arg() && get_hunits(, 'm', curenv->line_length)) {
-if (temp < minimum_length) {
-  warning(WARN_RANGE, "invalid line length %1u rounded to device"
- " horizontal motion quantum", temp.to_units());
-  temp = minimum_length;
+if (temp < hresolution) {
+  warning(WARN_RANGE, "setting invalid line length %1u to device"
+ " horizontal motion quantum",
+ temp.to_units());
+  temp = hresolution;
 }
   }
   else
@@ -1452,12 +1452,12 @@ void line_length()
 void title_length()
 {
   hunits temp;
-  hunits minimum_length = font::hor;
   if (has_arg() && get_hunits(, 'm', curenv->title_length)) {
-if (temp < minimum_length) {
-  warning(WARN_RANGE, "invalid title length %1u rounded to device"
- " horizontal motion quantum", temp.to_units());
-  temp = minimum_length;
+if (temp < hresolution) {
+  warning(WARN_RANGE, "setting invalid title length %1u to device"
+ " horizontal motion quantum",
+ temp.to_units());
+  temp = hresolution;
 }
   }
   else

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 03/21: [troff]: Fix Savannah #66009 (`|` not delimiter).

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit c8625529c8e8c565522460c8d57182a9beb0c24c
Author: G. Branden Robinson 
AuthorDate: Sat Jul 20 16:10:45 2024 -0500

[troff]: Fix Savannah #66009 (`|` not delimiter).

* src/roff/troff/input.cpp (is_char_usable_as_delimiter): Reject `|`.

Fixes <https://savannah.gnu.org/bugs/?66009>.
---
 ChangeLog| 7 +++
 src/roff/troff/input.cpp | 1 +
 2 files changed, 8 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index f819b45fb..b53aed0e5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2024-07-20  G. Branden Robinson 
+
+   * src/roff/troff/input.cpp (is_char_usable_as_delimiter): Reject
+   `|`.
+
+   Fixes <https://savannah.gnu.org/bugs/?66009>.
+
 2024-07-19  G. Branden Robinson 
 
Add test of *roff arithmetic.
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index ae833c6f5..d0ef4a0f1 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -2521,6 +2521,7 @@ static bool is_char_usable_as_delimiter(int c)
   case '(':
   case ')':
   case '.':
+  case '|':
 return false;
   default:
 return true;

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 01/21: ChangeLog: Clarify old entries.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 4cebd30052848eb6d4829ce020666a4b82511124
Author: G. Branden Robinson 
AuthorDate: Sat Jul 20 14:28:51 2024 -0500

ChangeLog: Clarify old entries.
---
 ChangeLog | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 72f9e976d..f819b45fb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -48,7 +48,7 @@
of primitive operation, and throw error diagnostic if arithmetic
wraps.
 
-   Fixes <https://savannah.gnu.org/bugs/?64301>.  You have to
+   Fixes <https://savannah.gnu.org/bugs/?64301>.  You had to
compile GNU troff with the (GCC) compiler option `-ftrapv` for
arithmetic to trap and cause a core dump.
 
@@ -119,7 +119,7 @@
 2024-07-14  G. Branden Robinson 
 
* tmac/groff_mdoc.7.man: Manipulate type size and vertical
-   spacing only in nroff mode.
+   spacing only in troff mode.
 
 2024-07-14  G. Branden Robinson 
 
@@ -279,7 +279,7 @@
Reduce cleverness of assignment nested inside conditional--a
favorite of C obscurantists and an especially gratuitous case
since it was preceded by a declarator without an initializer.
-   This aligns the function with another overloaded version of
+   This aligns `font::load()` with another overloaded version of
itself and with `font::scan_papersize()`.
 
 2024-07-13  G. Branden Robinson 
@@ -655,7 +655,7 @@
 
 2024-06-20  G. Branden Robinson 
 
-   Regression-test Savannah #65902.
+   [grog]: Regression-test Savannah #65902.
 
* src/utils/grog/tests/detect-chem.sh: Do it.
* src/utils/grog/grog.am (grog_TESTS): Run test.

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 07/21: [mm]: Recognize an `AFX` hook macro.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 54b2b3a8c7871ba36f0fa07118fa7a328c7b8e35
Author: G. Branden Robinson 
AuthorDate: Sun Jul 21 12:36:00 2024 -0500

[mm]: Recognize an `AFX` hook macro.

* contrib/mm/mm/0.MT:
* contrib/mm/mm/4.MT:
* contrib/mm/mm/ms.cov: Call `AFX` hook macro if defined, instead of
  default formatting of affiliated firm.
* contrib/mm/groff_mm.7.man (Macros) : Document facility.
---
 contrib/mm/ChangeLog  |  8 
 contrib/mm/groff_mm.7.man | 30 ++
 contrib/mm/mm/0.MT|  3 ++-
 contrib/mm/mm/4.MT|  3 ++-
 contrib/mm/mm/ms.cov  |  3 ++-
 5 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/contrib/mm/ChangeLog b/contrib/mm/ChangeLog
index c85f5c954..10c734f42 100644
--- a/contrib/mm/ChangeLog
+++ b/contrib/mm/ChangeLog
@@ -1,3 +1,11 @@
+2024-07-21  G. Branden Robinson 
+
+   * mm/0.MT:
+   * mm/4.MT:
+   * mm/ms.cov: Call `AFX` hook macro if defined, instead of
+   default formatting of affiliated firm.
+   * groff_mm.7.man (Macros) : Document facility.
+
 2024-07-14  G. Branden Robinson 
 
* mm/4.MT (cov@print-abstract):
diff --git a/contrib/mm/groff_mm.7.man b/contrib/mm/groff_mm.7.man
index 1c6c211fc..d02bd721d 100644
--- a/contrib/mm/groff_mm.7.man
+++ b/contrib/mm/groff_mm.7.man
@@ -716,6 +716,36 @@ and
 .
 .
 .TP
+.B AFX
+This user-definable hook macro assumes responsibility for formatting
+the affiliated firm name defined by
+.B AF
+in memorandum types 0 and 4 and documents using the
+.I ms
+cover page style.
+.
+If not defined
+(the default),
+internally defined macros handle this task;
+see sections \[lq]Internals\[rq] and \[lq]Files\[rq] below.
+.
+Applications include setting the firm name in a different font family,
+at a larger type size,
+drawing a rule across the page,
+and including an logo image using
+.IR groff 's
+.B PDFPIC
+or
+.B PSPIC
+macros.
+.
+See
+.B MT
+and
+.BR COVER .
+.
+.
+.TP
 .BR AL \~[\c
 .IR number-format \~[ text-indent \~[\c
 .BR 1 ]]]
diff --git a/contrib/mm/mm/0.MT b/contrib/mm/mm/0.MT
index 0fd3b676e..d7beb81a3 100644
--- a/contrib/mm/mm/0.MT
+++ b/contrib/mm/mm/0.MT
@@ -239,7 +239,8 @@ http://savannah.gnu.org/bugs/?group=groff.
 .\" definition.)
 .if !d cov*mt-printed \{\
 .  cov@print-title subject
-.  cov@print-firm
+.  ie d AFX .AFX
+.  el   .cov@print-firm
 .  cov@print-date date
 .  cov@print-authors from
 .  cov@print-abstract \\*[Abstract]
diff --git a/contrib/mm/mm/4.MT b/contrib/mm/mm/4.MT
index cf9c77a36..aae99d3bb 100644
--- a/contrib/mm/mm/4.MT
+++ b/contrib/mm/mm/4.MT
@@ -98,7 +98,8 @@ http://savannah.gnu.org/bugs/?group=groff.
 .if !d cov*mt-printed \{\
 .  cov@print-title
 .  cov@print-authors
-.  cov@print-firm
+.  ie d AFX .AFX
+.  el   .cov@print-firm
 .  if d cov*abstract \{\
 .  if !\n[cov*abstract-placement] .cov@print-abstract
 .  \}
diff --git a/contrib/mm/mm/ms.cov b/contrib/mm/mm/ms.cov
index 53df6d7f3..1c1ddb30c 100644
--- a/contrib/mm/mm/ms.cov
+++ b/contrib/mm/mm/ms.cov
@@ -101,7 +101,8 @@ http://savannah.gnu.org/bugs/?group=groff.
 .sp |4.2c
 .cov@print-title
 .cov@print-authors
-.cov@print-firm
+.ie d AFX .AFX
+.el   .cov@print-firm
 .cov@print-abstract "\\*[Abstract]"
 .cov@print-date
 .pg@enable-top-trap

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 20/21: [troff]: Fix missing space in diagnostic message.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit a37ae4b75406567a30b11dc699d35c1a7684aa9a
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 15:48:17 2024 -0500

[troff]: Fix missing space in diagnostic message.

* src/roff/troff/number.cpp (is_valid_expression_start): Do it.
---
 ChangeLog | 5 +
 src/roff/troff/number.cpp | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 731f6b00e..064d965f1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-07-25  G. Branden Robinson 
+
+   * src/roff/troff/number.cpp (is_valid_expression_start): Fix
+   missing space in diagnostic message.
+
 2024-07-25  G. Branden Robinson 
 
* src/roff/troff/number.cpp (vunits::vunits, hunits::hunits):
diff --git a/src/roff/troff/number.cpp b/src/roff/troff/number.cpp
index 0d91cfe96..da61b1a92 100644
--- a/src/roff/troff/number.cpp
+++ b/src/roff/troff/number.cpp
@@ -252,7 +252,7 @@ static bool is_valid_expression_start()
   }
   if (tok.is_right_brace()) {
 warning(WARN_RIGHT_BRACE, "expected numeric expression, got right"
-   "brace escape sequence");
+   " brace escape sequence");
 return false;
   }
   return true;

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 17/21: src/roff/troff/number.cpp: Fix Savannah #64301.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit a3e0a4fe337a1482410a307180825e55c0fc0869
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 15:10:39 2024 -0500

src/roff/troff/number.cpp: Fix Savannah #64301.

* src/roff/troff/number.cpp (vunits::vunits, hunits::hunits): Migrate to
  C23 checked arithmetic macros.  Throw error if addition overflows.

Fixes <https://savannah.gnu.org/bugs/?64301>.  (For real this time,
fingers crossed.)
---
 ChangeLog |  9 +
 src/roff/troff/number.cpp | 32 ++--
 2 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a99a5f3fe..731f6b00e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2024-07-25  G. Branden Robinson 
+
+   * src/roff/troff/number.cpp (vunits::vunits, hunits::hunits):
+   Migrate to C23 checked arithmetic macros.  Throw error if
+   addition overflows.
+
+   Fixes <https://savannah.gnu.org/bugs/?64301>.  (For real this
+   time, fingers crossed.)
+
 2024-07-25  G. Branden Robinson 
 
* src/roff/groff/tests/arithmetic-works.sh: Add more tests.
diff --git a/src/roff/troff/number.cpp b/src/roff/troff/number.cpp
index 7f43c0772..0d91cfe96 100644
--- a/src/roff/troff/number.cpp
+++ b/src/roff/troff/number.cpp
@@ -661,9 +661,19 @@ vunits::vunits(units x)
   else {
 // Don't depend on rounding direction when dividing neg integers.
 int vcrement = (vresolution / 2) - 1;
-n = (x < 0
-? -((-x + vcrement) / vresolution)
-: (x + vcrement) / vresolution);
+bool is_overflowing = false;
+if (x < 0) {
+  if (ckd_add(, -x, vcrement))
+   is_overflowing = true;
+  n = -n;
+}
+else {
+  if (ckd_add(, x, vcrement))
+   is_overflowing = true;
+}
+n /= vresolution;
+if (is_overflowing)
+  error("integer addition wrapped");
   }
 }
 
@@ -674,9 +684,19 @@ hunits::hunits(units x)
   else {
 // Don't depend on rounding direction when dividing neg integers.
 int hcrement = (hresolution / 2) - 1;
-n = (x < 0
-? -((-x + hcrement) / hresolution)
-: (x + hcrement) / hresolution);
+bool is_overflowing = false;
+if (x < 0) {
+  if (ckd_add(, -x, hcrement))
+   is_overflowing = true;
+  n = -n;
+}
+else {
+  if (ckd_add(, x, hcrement))
+   is_overflowing = true;
+}
+n /= hresolution;
+if (is_overflowing)
+  error("integer addition wrapped");
   }
 }
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 12/21: [groff]: Adapt test to forthcoming change.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 506fdfcdc78fd3ed76ab8edcd31e8cbd972ef5d4
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 09:06:41 2024 -0500

[groff]: Adapt test to forthcoming change.

We're about to start enforcing a minimum page length (as opposed to
accepting negative ones); these tests can leave the vertical drawing
position in (tracked by the `nl` register) in a weird place, so ensure
that we don't request a page length of less than 1v when truncating
nroff output for tidiness.
---
 .../groff/tests/some_escapes_accept_newline_delimiters.sh  | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/roff/groff/tests/some_escapes_accept_newline_delimiters.sh 
b/src/roff/groff/tests/some_escapes_accept_newline_delimiters.sh
index 96be05532..595e486d9 100755
--- a/src/roff/groff/tests/some_escapes_accept_newline_delimiters.sh
+++ b/src/roff/groff/tests/some_escapes_accept_newline_delimiters.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2022 Free Software Foundation, Inc.
+# Copyright (C) 2022-2024 Free Software Foundation, Inc.
 #
 # This file is part of groff.
 #
@@ -35,7 +35,7 @@ wail () {
 input="\A
 ABC
 D
-.pl \n(nlu"
+.pl 1v>?\n(nlu"
 
 echo "checking that newline is accepted as delimiter to 'A' escape" >&2
 error=$(printf "%s\n" "$input" | "$groff" -Tascii -ww -z 2>&1)
@@ -49,7 +49,7 @@ input=".sp
 \b
 ABC
 D
-.pl \n(nlu"
+.pl 1v>?\n(nlu"
 
 echo "checking that newline is accepted as delimiter to 'b' escape" >&2
 error=$(printf "%s\n" "$input" | "$groff" -Tascii -ww -z 2>&1)
@@ -62,7 +62,7 @@ echo "$output" | grep -Fqx "B D" || wail
 input="\o
 ABC
 D
-.pl \n(nlu"
+.pl 1v>?\n(nlu"
 
 echo "checking that newline is accepted as delimiter to 'o' escape" >&2
 error=$(printf "%s\n" "$input" | "$groff" -Tascii -ww -z 2>&1)
@@ -78,7 +78,7 @@ printf "%s\n" "$output" \
 input="\w
 ABC
 D
-.pl \n(nlu"
+.pl 1v>?\n(nlu"
 
 echo "checking that newline is accepted as delimiter to 'w' escape" >&2
 error=$(printf "%s\n" "$input" | "$groff" -Tascii -ww -z 2>&1)
@@ -91,7 +91,7 @@ test "$output" = "72 D" || wail
 input="\X
 tty: link http://example.com
 D
-.pl \n(nlu"
+.pl 1v>?\n(nlu"
 
 echo "checking that newline is accepted as delimiter to 'X' escape" >&2
 error=$(printf "%s\n" "$input" | "$groff" -Tascii -ww -z 2>&1)
@@ -104,7 +104,7 @@ test "$output" = ' D' || wail
 input="\Z
 ABC
 D
-.pl \n(nlu"
+.pl 1v>?\n(nlu"
 
 echo "checking that newline is accepted as delimiter to 'Z' escape" >&2
 error=$(printf "%s\n" "$input" | "$groff" -Tascii -ww -z 2>&1)

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 18/21: groff_diff(7): Relocate material.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 4b778256025cacd803916b083c10b5b63796f1c7
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 15:43:41 2024 -0500

groff_diff(7): Relocate material.

Better distingush AT/GNU troff differences that are affected by
compatibility mode from those that aren't.
---
 man/groff_diff.7.man | 190 +--
 1 file changed, 95 insertions(+), 95 deletions(-)

diff --git a/man/groff_diff.7.man b/man/groff_diff.7.man
index f49452cb3..199699de4 100644
--- a/man/groff_diff.7.man
+++ b/man/groff_diff.7.man
@@ -5386,101 +5386,6 @@ to the standard error stream.
 .
 .
 .\" 
-.SH "Other differences"
-.\" 
-.
-.\" TODO: Resync with the node of this name in our Texinfo manual.
-GNU
-.IR troff 's \" GNU
-features sometimes cause incompatibilities with documents written
-assuming old implementations of
-.IR troff . \" generic
-.
-Some GNU extensions to
-.I troff \" generic
-are supported by other implementations.
-.
-.
-.P
-AT
-.I troff \" AT
-discards trailing spaces from input lines,
-like GNU
-.IR troff , \" GNU
-but if it does so,
-AT
-.I troff \" AT
-also cancels end-of-sentence detection.
-.
-Use of the dummy character escape sequence
-.B \[rs]&
-is more portable.
-.
-.
-.P
-When adjusting to both margins,
-AT
-.I troff \" AT
-at first adjusts spaces starting from the right;
-GNU
-.I troff \" GNU
-begins from the left.
-.
-Both implementations adjust spaces from opposite ends on alternating
-output lines to prevent \[lq]rivers\[rq] in the text.
-.
-.
-.P
-GNU
-.I troff \" GNU
-does not always hyphenate words as AT
-.I troff \" AT
-does.
-.
-The AT implementation uses a set of hard-coded rules specific to
-U.S.\& English,
-while GNU
-.I troff \" GNU
-uses language-specific hyphenation pattern files derived from \*[tx].
-.
-In some versions of
-.I troff \" generic
-there was limited space to store hyphenation exceptions
-(arguments to the
-.B hw
-request);
-GNU
-.I troff \" GNU
-has no such restriction.
-.
-.
-.P
-GNU
-.I troff \" GNU
-handles the dummy character
-.B \[rs]&
-differently from AT
-.I troff \" AT
-when it is followed by the hyphenation control escape sequence
-.B \[rs]%
-at the beginning of a word.
-.
-GNU
-.I troff \" GNU
-does not regard the dummy character as \[lq]starting\[rq] the word;
-AT
-.I troff \" AT
-does.
-.
-Further,
-Heirloom Doctools
-.I troff \" Heirloom
-does not honor an explicit hyphenation point marked with
-.B \[rs]%
-after a word-initial one.
-.
-.
-.\" 
 .SH "Compatibility mode"
 .\" 
 .
@@ -5621,6 +5526,101 @@ turns compatibility mode
 while it interprets its argument list.
 .
 .
+.\" 
+.SH "Other differences"
+.\" 
+.
+.\" TODO: Resync with the node of this name in our Texinfo manual.
+GNU
+.IR troff 's \" GNU
+features sometimes cause incompatibilities with documents written
+assuming old implementations of
+.IR troff . \" generic
+.
+Some GNU extensions to
+.I troff \" generic
+are supported by other implementations.
+.
+.
+.P
+AT
+.I troff \" AT
+discards trailing spaces from input lines,
+like GNU
+.IR troff , \" GNU
+but if it does so,
+AT
+.I troff \" AT
+also cancels end-of-sentence detection.
+.
+Use of the dummy character escape sequence
+.B \[rs]&
+is more portable.
+.
+.
+.P
+When adjusting to both margins,
+AT
+.I troff \" AT
+at first adjusts spaces starting from the right;
+GNU
+.I troff \" GNU
+begins from the left.
+.
+Both implementations adjust spaces from opposite ends on alternating
+output lines to prevent \[lq]rivers\[rq] in the text.
+.
+.
+.P
+GNU
+.I troff \" GNU
+does not always hyphenate words as AT
+.I troff \" AT
+does.
+.
+The AT implementation uses a set of hard-coded rules specific to
+U.S.\& English,
+while GNU
+.I troff \" GNU
+uses language-specific hyphenation pattern files derived from \*[tx].
+.
+In some versions of
+.I troff \" generic
+there was limited space to store hyphenation exceptions
+(arguments to the
+.B hw
+request);
+GNU
+.I troff \" GNU
+has no such restriction.
+.
+.
+.P
+GNU
+.I troff \" GNU
+handles the dummy character
+.B \[rs]&
+differently from AT
+.I troff \" AT
+when it is followed by the hyphenation control escape sequence
+.B \[rs]%
+at the beginning of a word.
+.
+GNU
+.I troff \" GNU
+does not regard the

[groff] 11/21: doc/groff.texi.in: Revise `ll`, `lt` discussion.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit c89d403833fbefce2f03aec5f24c8f5c0286ee9c
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 14:15:34 2024 -0500

doc/groff.texi.in: Revise `ll`, `lt` discussion.

Paralellize discussions and more comprehensively discuss parameter
handling.  Clarify that the "previous" (title) line lengths are those
associated with the environment.
---
 doc/groff.texi.in | 37 ++---
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 8c004ce2d..18aff8d8c 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -9937,16 +9937,17 @@ with the environment (@pxref{Environments}).
 @DefreqItem {ll, @t{-}@Var{length}}
 @DefregItemx {.l}
 @DefregListEndx {.ll}
-Set the line length to @var{length}; if @var{length} is signed, adjust
-the line length by its value.  The default scaling unit is @samp{m}.  If
-not otherwise configured (see @pxref{Paper Format}), the default line
-length is 6.5@dmn{i}.
-
-If @var{length} is omitted, the line length is reset to that before the
-previous invocation of @code{ll}.  If @var{length} is negative, GNU
-@command{troff} emits a warning in category @samp{range} and sets the
-line length to the device's horizontal motion quantum; recall
-@ref{Motion Quanta}.
+Change (increase or decrease) the line length per the numeric expression
+@var{length}.  The default scaling unit is @samp{m}.  If not otherwise
+configured (see @pxref{Paper Format}), the default line length is
+6.5@dmn{i}.  If @var{length} is invalid, GNU @code{troff} emits a
+warning in category @samp{number} and ignores the request.  If
+@var{length} is nonpositive, GNU @command{troff} emits a warning in
+category @samp{range} and sets the line length to the device's
+horizontal motion quantum; recall @ref{Motion Quanta}.  The line length
+is associated with the environment (@pxref{Environments}).  If
+@var{length} is omitted, GNU @command{troff} restores the environment's
+previous line length.
 
 The effect of @code{ll} is delayed until a partially collected line (if
 it exists) is output.  In other words, it does not change a pending
@@ -9960,9 +9961,6 @@ line length that applies to the pending output line.
 Similarly to @code{.i} and @code{.in}, the difference between @code{.l}
 and @code{.ll} is that the latter takes into account whether a partially
 collected line still uses the previous length.
-
-The line length is associated with the environment
-(@pxref{Environments}).
 @endDefreq
 
 
@@ -10162,13 +10160,14 @@ sets a title line comprising only the left-aligned 
word @samp{Thesis}.
 @cindex title length, configuring (@code{lt})
 Change (increase or decrease) the line length used by titles per the
 numeric expression @var{length}.  The default scaling unit is @samp{m}.
-If @var{length} is negative, GNU emits a warning in category
-@samp{range} and treats @var{length} as @samp{0}.  If @var{length} is
+The formatter's default title length is @samp{6.5i}.  If @var{length} is
 invalid, GNU @code{troff} emits a warning in category @samp{number} and
-ignores the request.  The formatter's default title length is
-@samp{6.5i}.  With no argument, the title length is restored to the
-previous value.  The title length is is associated with the environment
-(@pxref{Environments}).
+ignores the request.  If @var{length} is nonpositive, GNU
+@command{troff} emits a warning in category @samp{range} and sets the
+title line length to the device's horizontal motion quantum; recall
+@ref{Motion Quanta}.  The title length is is associated with the
+environment (@pxref{Environments}).  If @var{length} is omitted, GNU
+@command{troff} restores the environment's previous title length.
 
 @cindex title line length register (@code{.lt})
 The read-only register @samp{.lt} interpolates the title line length.

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 08/21: Revert "[docs]: Fix Savannah #65118 (`device` behavior)."

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 5be9a9cd0e177d9bcea8b03a68c8a711c16cf31e
Author: G. Branden Robinson 
AuthorDate: Sun Jul 21 17:47:19 2024 -0500

Revert "[docs]: Fix Savannah #65118 (`device` behavior)."

This reverts commit c8935f2361b44414be83a34f5e7e4b2ad57cd8b2.
---
 ChangeLog|  9 -
 doc/groff.texi.in|  6 --
 man/groff_diff.7.man | 12 
 3 files changed, 27 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 69cb577ca..eb4ea86d1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -3660,15 +3660,6 @@
 
Fixes <https://savannah.gnu.org/bugs/?64959>.
 
-2024-01-08  G. Branden Robinson 
-
-   * doc/groff.texi (Postprocessor Access):
-   * man/groff_diff.7.man (New requests): Clarify a point of
-   `device` request behavior; a partially collected line in the
-   top-level diversion must exist at least once.
-
-   Fixes <https://savannah.gnu.org/bugs/?65138>.
-
 2024-01-08  G. Branden Robinson 
 
* src/roff/troff/div.cpp (top_level_diversion::output)
diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 5c59b2c1a..23ea7829e 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -16625,12 +16625,6 @@ rendered as glyphs in the output; instead, they remain 
abstract
 characters---in a PDF bookmark or a URL, for example.}  The use of any
 other escape sequence in @code{\X} parameters is normally an error.
 
-A device control command issued with the @code{device} request will not
-be reflected in the output unless a partially collected line exists at
-least once in the top-level diversion (recall @ref{Diversions}).  When
-experimenting with such device controls in minimal documents, a
-@code{br} request will ensure this to be the case.
-
 @kindex use_charnames_in_special
 @cindex @file{DESC} file, and @code{use_charnames_in_special} keyword
 @cindex @code{\X}, and special characters
diff --git a/man/groff_diff.7.man b/man/groff_diff.7.man
index f5347e6b7..f49452cb3 100644
--- a/man/groff_diff.7.man
+++ b/man/groff_diff.7.man
@@ -2305,18 +2305,6 @@ is stripped to allow the embedding of
 leading spaces.
 .
 .
-.IP
-A device control command issued with the
-.B device
-request will not be reflected in the output unless a partially collected
-line exists in the top-level diversion at least once.
-.
-When experimenting with such device controls in minimal documents,
-a
-.B br
-request will ensure this to be the case.
-.
-.
 .TP
 .BI .devicem\~ name
 Write contents of macro or string

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 10/21: doc/groff.texi.in: Improve header/footer example.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 0cc32d8b75d0e94ac2589c5eb5435d747a562d62
Author: G. Branden Robinson 
AuthorDate: Wed Jul 24 14:15:03 2024 -0500

doc/groff.texi.in: Improve header/footer example.

* Stop using no-break control character to invoke `tl` request; it's not
  necessary.
* _Do_ use no-break control character to invoke `sp` and `bp`;
  otherwise, the first word of a partially collected line can be output
  in the midst of header or footer material.
* Fix positioning of body text to one inch as touted; use
  boundary-relative motion operator to get there.
* Fix positioning of footer, adjusting it 1v up the page from the bottom
  of the body text so that the margin between them is one half-inch as
  touted.
* Improve discussion to motivate application of no-break control
  character to the `bp` request, as noted above.
---
 doc/groff.texi.in | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 01777b98e..8c004ce2d 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -14802,20 +14802,22 @@ there.
 A macro package might set headers and footers as follows; this example
 configures vertical margins of one inch to the body text, and one
 half-inch to the titles.  Observe the use of the no-break control
-character with @code{sp} request to position our text baselines,
-and the page number character @samp{%} used with the @code{tl} request.
+character with the @code{sp} and @code{br} requests to position our text
+baselines and prevent a partially collected line from being written
+outside the body text, and the page number character @samp{%} used with
+the @code{tl} request.
 
 @Example
 .\" hdfo.roff
 .de hd  \" page header
 '  sp .5i
-'  tl '\\*(Ti''\\*(Da'  \" title and date strings
-'  sp .5i
+.  tl '\\*(Ti''\\*(Da'  \" title and date strings
+'  sp |1i
 ..
 .de fo  \" page footer
-'  sp .5i
+'  sp .5i-1v
 .  tl ''%''
-.  bp
+'  bp
 ..
 .wh 0   hd  \" trap at top of the page
 .wh -1i fo  \" trap 1 inch from bottom

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 19/21: groff_diff(7): Doc `.tabs` reg as string-valued.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit dcf663b802a7abf186a8407758a6d7ee30c76af6
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 15:46:52 2024 -0500

groff_diff(7): Doc `.tabs` reg as string-valued.
---
 man/groff_diff.7.man | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/man/groff_diff.7.man b/man/groff_diff.7.man
index 199699de4..b7d331a66 100644
--- a/man/groff_diff.7.man
+++ b/man/groff_diff.7.man
@@ -4415,6 +4415,8 @@ for passage to the
 .B ta
 request.
 .
+This is a string-valued register.
+.
 .
 .TP
 .B \[rs]n[.trap]

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 06/21: [grog]: Fix Savannah #66006 (TS/TH/TE -> "-man").

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 6fa8faab78f5a802e87483aae2fdc2834e4130af
Author: G. Branden Robinson 
AuthorDate: Sat Jul 20 14:26:02 2024 -0500

[grog]: Fix Savannah #66006 (TS/TH/TE -> "-man").

* src/utils/grog/grog.pl (interpret_line): Fix logic error; set Boolean
  scalar `have_seen_first_macro_call` _after_ testing it, not before,
  avoiding its tautological truth.  (infer_man_or_ms_package): Drop `TH`
  from list of "unique" man(7) macro names.  It isn't; most full-service
  macro packages use it to manage tbl(1) headings, and we already have
  special logic for handling it as the first call in a page anyway
  (where it is overwhelmingly idiomatic of a man(7) document).

Fixes <https://savannah.gnu.org/bugs/?66006>.  Thanks to Morten Bo
Johansen for the report.
---
 ChangeLog  | 14 ++
 src/utils/grog/grog.pl |  9 ++---
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2d41dea84..69cb577ca 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2024-07-20  G. Branden Robinson 
+
+   * src/utils/grog/grog.pl (interpret_line): Fix logic error; set
+   Boolean scalar `have_seen_first_macro_call` _after_ testing it,
+   not before, avoiding its tautological truth.
+   (infer_man_or_ms_package): Drop `TH` from list of "unique"
+   man(7) macro names.  It isn't; most full-service macro packages
+   use it to manage tbl(1) headings, and we already have special
+   logic for handling it as the first call in a page anyway (where
+   it is overwhelmingly idiomatic of a man(7) document).
+
+   Fixes <https://savannah.gnu.org/bugs/?66006>.  Thanks to Morten
+   Bo Johansen for the report.
+
 2024-07-20  G. Branden Robinson 
 
Regression-test Savannah #66006.
diff --git a/src/utils/grog/grog.pl b/src/utils/grog/grog.pl
index 417c1389f..9a102883e 100644
--- a/src/utils/grog/grog.pl
+++ b/src/utils/grog/grog.pl
@@ -3,7 +3,7 @@
 # Inspired by doctype script in Kernighan & Pike, Unix Programming
 # Environment, pp 306-8.
 
-# Copyright (C) 1993-2021 Free Software Foundation, Inc.
+# Copyright (C) 1993-2024 Free Software Foundation, Inc.
 # Written by James Clark.
 # Rewritten in Perl by Bernd Warken .
 # Hacked up by G. Branden Robinson, 2021.
@@ -346,7 +346,6 @@ sub interpret_line {
   # What remains must be a macro name.
   my $macro = $command;
 
-  $have_seen_first_macro_call = 1;
   $score{$macro}++;
 
 
@@ -363,6 +362,9 @@ sub interpret_line {
 $man_score += 100;
   }
 
+  # Set this here because we start returning early from here on.
+  $have_seen_first_macro_call = 1;
+
   ##
   # mdoc
   if ($macro =~ /^Dd$/) {
@@ -506,13 +508,14 @@ sub infer_man_or_ms_package {
  'XS', 'XE', 'XA', 'TC', 'PX',
  'IX', 'SG');
 
-  my @macro_man = ('BR', 'IB', 'IR', 'RB', 'RI', 'P', 'TH', 'TP', 'SS',
+  my @macro_man = ('BR', 'IB', 'IR', 'RB', 'RI', 'P', 'TP', 'SS',
   'HP', 'PD',
   'AT', 'UC',
   'SB',
   'EE', 'EX',
   'OP',
   'ME', 'SY', 'YS', 'TQ', 'UR', 'UE', 'MR');
+  # TH can be used by ms, mm, me, mdoc, and mom.
   # MT is also used by mm.
 
   my @macro_man_or_ms = ('B', 'I', 'BI',

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 02/21: NEWS: Clarify items.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit adbea3ad4a7534d78361cd7c68c9975f632d0855
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 16:00:35 2024 -0500

NEWS: Clarify items.
---
 NEWS | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index 99cb2757d..90a1646ad 100644
--- a/NEWS
+++ b/NEWS
@@ -163,9 +163,9 @@ o The behavior of the an (man) package's `SY` and `YS` 
macros has been
   initially breaks the output line _only_ if it is encountered
   repeatedly without a preceding `YS` call.  The computed indentation of
   synopsis lines after the first now also includes the width of anything
-  on the line _before_ the synopsis, so that you can precede the `SY`
-  call with, for instance, the C language data type used for the return
-  value in a function prototype.  The `SY` macro now accepts an optional
+  already on the output line, so that you can precede the `SY` call
+  with, for instance, the C language data type used for the return value
+  in a function prototype.  The `SY` macro now accepts an optional
   second argument.  This second argument is typeset in bold, replaces
   the fixed-width space that is appended to the synopsis keyword in
   `SY`'s single-argument form, and is used in computation of the
@@ -294,7 +294,7 @@ o The an (man) macro package's `IP` macro no longer honors 
the formerly
   migrating to `TP`.
 
 o The "an-ext.tmac" macro file no longer defines `DS` and `DE` macros.
-  It had defined them as empty (undocumently) since 2009.
+  It had defined them as empty (undocumentedly) since 2009.
 
 o The doc (mdoc) macro package's `Mt` macro now sets its argument in
   roman, not italics (or whatever the string `doc-Pa-font` was

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


[groff] 16/21: [troff]: Add more tests of arithmetic.

2024-07-25 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit a7687009739feb5592f33de6e6a3573bae7fc349
Author: G. Branden Robinson 
AuthorDate: Thu Jul 25 08:22:33 2024 -0500

[troff]: Add more tests of arithmetic.

* src/roff/groff/tests/arithmetic-works.sh: Add more tests.

Test fails at this commit.
---
 ChangeLog|  4 
 src/roff/groff/tests/arithmetic-works.sh | 33 +---
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 88d6cd3be..a99a5f3fe 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2024-07-25  G. Branden Robinson 
+
+   * src/roff/groff/tests/arithmetic-works.sh: Add more tests.
+
 2024-07-25  G. Branden Robinson 
 
* src/roff/troff/number.cpp (vunits::vunits, hunits::hunits):
diff --git a/src/roff/groff/tests/arithmetic-works.sh 
b/src/roff/groff/tests/arithmetic-works.sh
index 3f0b91701..c188ca867 100755
--- a/src/roff/groff/tests/arithmetic-works.sh
+++ b/src/roff/groff/tests/arithmetic-works.sh
@@ -39,25 +39,44 @@ wail () {
 input='.
 .ec @
 .nf
-.vs +2
-@&.v=@n(.v
+.vs +40u
+1: @&.v=@n(.v
 .ll -2
-@&.l=@n(.l
+2: @&.l=@n(.l
+.ll 2147483647u
+3: @&.l=@n(.l, .H=@n(.H
+.ll
+.pl 2147483647u
+4: @&.p=@n(.p, .V=@n(.V
+.pl
 .'
 
 # Expected:
 #
-# .v=40
-# .l=1512
+# 1: .v=80
+#
+# 2: .l=1512
+#
+# 3: .l=24, .H=24
+#
+# 4: .p=40, .V=40
+#
+# The blank lines are due to the `vs` increase.
 
 output=$(echo "$input" | "$groff" -T ascii)
 echo "$output"
 
 echo "checking that vertical spacing is correctly incremented" >&2
-echo "$output" | grep -Fqx '.l=1512' || wail
+echo "$output" | grep -Fqx '1: .v=80' || wail
 
 echo "checking that line length is correctly incremented" >&2
-echo "$output" | grep -Fqx '.l=1512' || wail
+echo "$output" | grep -Fqx '2: .l=1512' || wail
+
+echo "checking that setting huge line length does not overflow" >&2
+echo "$output" | grep -Fqx '3: .l=24, .H=24' || wail
+
+echo "checking that setting huge page length does not overflow" >&2
+echo "$output" | grep -Fqx '4: .p=40, .V=40' || wail
 
 # Exercise boundary values.
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit


Re: vim :hardcopy equivalent

2024-07-24 Thread G. Branden Robinson
Hi Tadziu,

At 2024-07-24T22:27:31+0200, Tadziu Hoffmann wrote:
> > > a "margin" measures an extent of whitespace (or "negative space"),
> > > whereas the `sp` request positions the _text baseline_,
> 
> The first is correct and the second incorrect for [g]troff.

I will defend my formulation.  `sp` _does_ position the text baseline,
period.

Where, exactly, it puts it sometimes overturns the user's intuition.

> In troff (and nroff), if you say
> 
>   .sp |0
> 
> then this does not mean "put the baseline at the top of the page"
> but rather "leave zero space above the text", and correspondingly

Agreed.

>   .sp |50p
> 
> means "leave 50 pt of space above the text", as you would expect
> for margins.  Thus, troff's model somewhat follows the concepts
> of metal typesetting.

Yes.  Equally `.sp 1v` (which is really the same as `.sp`) leaves 1v of
space above the next output line.

$ nroff < Of course, troff simplifies this a bit, in the first case by putting
> the baseline at 1 vee below the top of the page, and in the second
> case at 50 pt + 1 vee.

Yes.  To Peter Schaffter's grief.  https://savannah.gnu.org/bugs/?61507

[snip]

I have no gripe with your example; I simply think you inferred something
different from my claim than I was intending.

Collectively, our best efforts at explanation are in the groff Texinfo
manual, groff(7), and roff(7).  If those could use improvement, I'm
listening.

Regards,
Branden


signature.asc
Description: PGP signature


Re: vim :hardcopy equivalent

2024-07-24 Thread G. Branden Robinson
[self-follow-up]

At 2024-07-24T13:28:04-0500, G. Branden Robinson wrote:
> I notice now that those claims about the margin sizes might be off by
> one vee; in my experience, a "margin" measures an extent of whitespace
> (or "negative space"), whereas the `sp` request positions the _text
> baseline_, and since glyphs are nearly always drawn at least in part
> _above_ the text baseline, text formatted at a vertical position of
> 0.5i from the top of the page actually encroaches into a "top margin"
> of one half-inch.
> 
> Often that's a fairly subtle point, but when trying to format a
> document to a national standard, it's important to use precise
> measurements, lest ruler-wielding enforcers come around to rap one's
> knuckles.
> 
> So I will review this material for correctness.

Sure enough, there were problems.  I've fixed them in my working copy
and you can expect them in my next push.  In the meantime, I am
attaching the corrected "hdfo.roff" example and a document that uses it.

Regards,
Branden
.\" hdfo.roff
.de hd  \" page header
'  sp .5i
.  tl '\\*(Ti''\\*(Da'  \" title and date strings
'  sp |1i
..
.de fo  \" page footer
'  sp .5i-1v
.  tl ''%''
'  bp
..
.wh 0   hd  \" trap at top of the page
.wh -1i fo  \" trap 1 inch from bottom
.so hdfo.roff
.ds Ti Final Report\"
.ds Da 21 May 2023\"
.ti
On 5 August of last year,
this committee tasked me with the investigation of the
CFIT (controlled flight into terrain) incident of XX Mon .
.
.de Tx
Sed unde omnis iste natus error sit voluptatem accusantium doloremque
laudantium,
totam rem aperiam eaque ipsa,
quae ab illo inventore veritatis et quasi architecto beatae vitae dicta
sunt,
explicabo.
..
.while \n%=1 .Tx
.\" ...and so on...


signature.asc
Description: PGP signature


Re: vim :hardcopy equivalent

2024-07-24 Thread G. Branden Robinson
At 2024-07-24T10:15:47+0200, me.gr...@mro.name wrote:
> to keep it simple I went without macros and figured out the commands
> from https://www.gnu.org/software/groff/manual/groff.html without
> further help.

I'm glad the manual proved adequate here!  I've spent several years
attempting to improve it for our users.

> For now I may go with https://mro.name/2024/brief-dina4.roff
> 
> Having an automatic header line on subsequent pages would be a plus,
> but isn't worth to RTFM e2e.

groff's Texinfo manual covers that too.

The subsection/node "Page Location Traps" discusses how to do this and
offers a simple example of the setup and use of header and footer traps.

I'll reproduce the material (in "info" format) from my working copy
here.  I think it's pretty close to what's in groff 1.23.0's manual (and
therefore what's on the GNU website), but there may be improvements or
corrections here--I can't remember, since there have been over 1,300
commits to groff Git since 1.23.0 was released.


5.28.1.1 Page Location Traps


A "page location trap" is a vertical position trap that applies to the
page; that is, to undiverted output.  Many can be present; manage them
with the 'wh' and 'ch' requests.

 -- Request: .wh dist [name]
 Plant macro NAME as page location trap at DIST.  The default
 scaling unit is 'v'.  Non-negative values for DIST set the trap
 relative to the top of the page; negative values set the trap
 relative to the bottom of the page.  It is not possible to plant a
 trap less than one basic unit from the page bottom: a DIST of '-0'
 is interpreted as '0', the top of the page.(1)  (*note Page
 Location Traps-Footnote-1::) An existing _visible_ trap (see below)
 at DIST is removed; this is 'wh''s sole function if NAME is
 missing.

 A trap is sprung only if it is "visible", meaning that its location
 is reachable on the page(2) (*note Page Location
 Traps-Footnote-2::) and it is not hidden by another trap at the
 same location already planted there.

 A macro package might set headers and footers as follows; this
 example configures vertical margins of one inch to the body text,
 and one half-inch to the titles.  Observe the use of the no-break
 control character with 'sp' request to position our text baselines,
 and the page number character '%' used with the 'tl' request.

  .\" hdfo.roff
  .de hd  \" page header
  '  sp .5i
  '  tl '\\*(Ti''\\*(Da'  \" title and date strings
  '  sp .5i
  ..
  .de fo  \" page footer
  '  sp .5i
  .  tl ''%''
  .  bp
  ..
  .wh 0   hd \" trap at top of the page
  .wh -1i fo \" trap 1 inch from bottom

 To use these traps, copy the above (or load it from a file with the
 'so' or 'mso' requests), then set up the strings it uses.

  .so hdfo.roff
  .ds Ti Final Report\"
  .ds Da 21 May 2023\"
  .ti
  On 5 August of last year,
  this committee tasked me with the investigation of the
  CFIT (controlled flight into terrain) incident of
  .\" ...and so on...

I notice now that those claims about the margin sizes might be off by
one vee; in my experience, a "margin" measures an extent of whitespace
(or "negative space"), whereas the `sp` request positions the _text
baseline_, and since glyphs are nearly always drawn at least in part
_above_ the text baseline, text formatted at a vertical position of 0.5i
from the top of the page actually encroaches into a "top margin" of one
half-inch.

Often that's a fairly subtle point, but when trying to format a document
to a national standard, it's important to use precise measurements, lest
ruler-wielding enforcers come around to rap one's knuckles.

So I will review this material for correctness.

Let me know if this was of assistance, and if I can offer more.

Regards,
Branden


signature.asc
Description: PGP signature


Re: What is the preferred way for contributing to groff

2024-07-24 Thread G. Branden Robinson
Hi Lukas,

Are you subscribed to groff@gnu?  I prefer not to mail both lists and
people unless they express a preference for that (ideally via mail
headers that communicate this, and if my MUA is clueful enough to
interpret such indications).

At 2024-07-24T11:04:04+0200, Lukas Javorsky wrote:
> I found multiple defects in Groff's source code,

I'm sorry to hear that...

> and I would like to help with fixing them by contributing several
> commits.

...but this is happy news!

> I didn't find much information about the contribution process on the
> website [1],

It sounds like you have bugs to report, so the "Bug Reports" section of
the page you cited would describe an appropriate course to follow.

>>  Bug Reports
>>
>> Please report bugs using the bug tracker linked from the groff
>> project page. Alternatively, but less preferably, you can use the
>> form in the text file BUG-REPORT distributed with the groff source
>> code; its purpose is to make sure that we have all the information we
>> need to fix the bug. At the very least, read BUG-REPORT and make sure
>> that you supply all the information that it asks for. Even if you are
>> not sure that something is a bug, report it using BUG-REPORT: this
>> will help us determine whether it really is a bug or not.

> so I decided to ask here for more information. Could you please help
> me figure out what is the preferred way for the contributions?

I recommend you visit this link:

https://savannah.gnu.org/bugs/?group=groff

If you change the "query form" list box control from "Basic" to
"Backlog" (which is what I use 99% of the time), you can perform a
search based on several criteria, including keywords that appear in the
bug summary.

That will help you determine if the problem has already been reported
(and, one hopes, fixed).

If a search is unavailing, you can file a new report by clicking on the
"Bugs" pop-up menu and selecting "Submit item", or by visiting this
link:

https://savannah.gnu.org/bugs/?group=groff=additem

> Thank you so much for your help.

I look forward to studying your reports!

Regards,
Branden


signature.asc
Description: PGP signature


[bug #66016] Document groff deviation(s) from historical .hw handling

2024-07-24 Thread G. Branden Robinson
Update of bug #66016 (group groff):

  Status:None => Confirmed  

___

Follow-up Comment #1:

[comment #0 original submission:]
> In http://lists.gnu.org/r/groff/2024-04/msg7.html Branden quoted CSTR
#54 (1992):

> .hw word
>Specify hyphenation points in words with embedded minus signs.
>Versions of a word with a terminal s are implied; i.e., dig-it
>implies dig-its.  This list is examined initially and after each
>suffix stripping.


> He then conjectured, "I expect the second and third sentences don't apply to
GNU troff..., but our documentation says nothing about this.  Guess I'll have
to check."

I promptly forgot to do so, of course.

> 
> In fact, the second sentence doesn't apply to groff (but does to Heirloom
troff), as illustrated by using .hw to assign hyphenation points to a made-up
word.

> .de op
> One brevallamarkol, two brevallamarkols.
> .sp
> ..
> .warn 0
> .ll 1n
> .op
> .hw brev-all-a-mar-kol
> .op


> The third sentence still needs to be checked.

Yeah, I suspect neither sentence applies to GNU _troff_, as it contemplated
application to languages other than English from the outset (or very early at
least).

This would be something to note in the "Implementation Differences" part of
out Texinfo manual and of _groff_diff_(7).


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65861] add macro set to support German national standard DIN 5008

2024-07-23 Thread G. Branden Robinson
Follow-up Comment #2, bug #65861 (group groff):

I have no objection in principle to incorporating support for DIN 5008-format
letters, either as a standalone macro package or as _groff_mmde_(7) (say), but
I don't plan to drive [https://lists.gnu.org/r/groff/2024-01/msg00025.html the
process] myself.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #63825] [man pages] insufficient escaping in fallback MR definition

2024-07-22 Thread G. Branden Robinson
Update of bug #63825 (group groff):

Severity: 5 - Blocker => 4 - Important  

___

Follow-up Comment #2:

Adjusting severity; using the "blocker" severity to mark release goals was an
experiment for 1.23.0 that not everyone liked.

(Savannah now has a ticket dependency system, so for 1.24.0 we simply have a
"release goals" ticket; see bug #65099.)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #63824] revert recent change to skip tests at configuration time

2024-07-22 Thread G. Branden Robinson
Update of bug #63824 (group groff):

Severity: 5 - Blocker => 4 - Important  

___

Follow-up Comment #5:

Adjusting severity; using the "blocker" severity to mark release goals was an
experiment for 1.23.0 that not everyone liked.

(Savannah now has a ticket dependency system, so for 1.24.0 we simply have a
"release goals" ticket; see bug #65099.)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #57218] groff implicitly embeds time zone offset in generated files (SOURCE_DATE_EPOCH, TZ)

2024-07-22 Thread G. Branden Robinson
Update of bug #57218 (group groff):

Severity: 5 - Blocker => 3 - Normal 

___

Follow-up Comment #19:

Adjusting severity; using the "blocker" severity to mark release goals was an
experiment for 1.23.0 that not everyone liked.

(Savannah now has a ticket dependency system, so for 1.24.0 we simply have a
"release goals" ticket; see bug #65099.)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65138] [troff] `device` request silently fails before first page begins

2024-07-21 Thread G. Branden Robinson
Update of bug #65138 (group groff):

 Planned Release:  1.23.0 => None   


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >