[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Dave]

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

On the email list, Deri made a case
(http://lists.gnu.org/r/groff/2023-06/msg00073.html) for leaving this behavior
as-is.  This post has thus far garnered no reply.

To me, the behavior seems oddball enough that it likely was a bug which then
got documented, making it technically no longer a bug but still oddball
behavior.

While I sympathize with Deri's concern for users who rely on this behavior, I
bet it's a pretty small number, and there may be just as many who find that
the fix corrects problems in their documents.  The ones most likely to be
affected are those who coded workarounds to the undesired movement, which may,
after this fix, introduce new undesired movement.  (This would be the case
with code generated by both the grn and pic preprocessors; the attached patch
is obliged to remove their workarounds.)  But even that depends on how their
workaround was done: for -mom, Peter mentioned
(http://lists.gnu.org/r/groff/2023-06/msg00093.html) he would wrap \D't'
escapes in \Z, rendering moot whether or not \D't' moves the drawing
position.

In general, I share Branden's preference for making minor sacrifices to strict
back compatibility when the historical behavior is wildly counterintuitive
(see also bug #64275).  It is highly useful to allow groff to correctly render
roff source prepared 20, 30, 40 years ago.  However, for attracting and
retaining new users, it's also important to reduce the number of inexplicable
quirks: there comes a point when users trying to learn the system will grow
tired of dodging all the quicksand pits and move on to something else.  A
groff that caters only to the past and not to the future is a groff with a
baked-in shelf life.

The change proposed here seems rather less intrusive--and affecting less
entrenched behavior--than the early-2020 change to \s's semantics
([http://git.savannah.gnu.org/cgit/groff.git/commit/?id=0b9aaca0 commit
0b9aaca0]).  And that was a change to deliberate behavior (albeit behavior
tied to a historical device no one uses anymore) rather than an arguable bug
fix.  Of course, there's yet to be a released groff with the \s change, so we
don't yet know what gnashing of teeth it might engender.

cc:ing Deri so he can rebut any of the above points.


    _______________________________________________________

Reply to this item at:

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

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