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/