[bug #63873] \~ can cause overwritten text

[Dave]

Follow-up Comment #4, bug #63873 (project groff):

The first patch in comment #3 displays in savannah incorrectly because
savannah interprets two asterisks on the same line of code as starting and
ending markers for boldface.  Putting the patch in a +verbatim+ block (see
savannah's markup instructions) avoids this problem, and also visually
distinguishes the patch from the rest of the comment:

diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index 9f00284c6..0ec4e40e3 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -2081,11 +2081,12 @@ static node *node_list_reverse(node *n)
 static void distribute_space(node *n, int nspaces, hunits desired_space,
                             bool force_reverse_node_list = false)
 {
-  if (desired_space.is_zero() || nspaces == 0)
-    return;
   // Positive desired space is the typical case.  Negative desired space
-  // is possible if we have overrun an unbreakable line.  But we should
-  // not get here if there are no adjustable space nodes to adjust.
+  // is possible if we have overrun an unbreakable line.
+  if (desired_space.to_units() <= 0 || nspaces == 0)
+    return;
+  // But we should not get here if there are no adjustable space nodes
+  // to adjust.
   assert(nspaces > 0);
   // Space cannot always be distributed evenly among all of the space
   // nodes in the node list: there are limits to device resolution.  We
@@ -2098,8 +2099,7 @@ static void distribute_space(node *n, int nspaces,
hunits desired_space,
   static bool do_reverse_node_list = false;
   if (force_reverse_node_list || do_reverse_node_list)
     n = node_list_reverse(n);
-  if (!force_reverse_node_list && spread_limit >= 0
-      && desired_space.to_units() > 0) {
+  if (!force_reverse_node_list && spread_limit >= 0) {
     hunits em = curenv->get_size();
     double Ems = (double)desired_space.to_units() / nspaces
                 / (em.is_zero() ? hresolution : em.to_units());

And it's useful to be able to see a patch inline like that...but there's still
the problem that a copy/paste is likely to mangle tab characters (though in
this case, even if it does, the tabs don't appear on any of the changed lines,
and the patch still applies successfully).  So attaching a patch is the safest
route.

For the historical record, a variant of this patch, with the same code change
but that additionally removes a comment (for reasons I'm not sure of, as the
comment still seems relevant to me) was posted to the groff list
(http://lists.gnu.org/r/groff/2023-03/msg00036.html) about 45 minutes after
comment #3.


    _______________________________________________________

Reply to this item at:

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

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