Follow-up Comment #13, bug #67817 (group groff): [comment #12 comment #12:] > Do you feel this issue should gate _groff_ 1.24.0?
I would've said yes an hour ago. But I'm apparently still being fickle.
This time, it's due to doing what I should have done long ago, which is to
simplify to the essentials.
$ echo "What does Fonzie say? \N'65'" | groff -a
<beginning of page>
What does Fonzie say? <--->
_This_ output has not changed, from groff 1.19.2 to the bleeding edge. In
1.23 and earlier, my use of .char was merely hiding how -a output handled \N
escapes.
It turned out to be a useful hiding: I doubt I'm alone in finding that, if one
needs to access some characters via \N, the document source code is a lot more
readable if one aliases those \Ns with meaningful .char definitions than if
ones sprinkles \N escapes across one's text.
But the root issue--that -a output emits the same string for every \N
escape--has been present as far back as I can test.
So, it would be nice if 1.24 fixed this root issue, since I bet I'm not the
only one for whom it will have been heretofore masked. But that may not make
it worth breaking the code freeze to address what is, at core, longstanding
behavior.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67817>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
