At 2025-02-21T15:22:02+0100, onf wrote: > On Fri Feb 21, 2025 at 3:14 PM CET, onf wrote: > > Well, I have thought about it a bit since yesterday and I think > > making `so` similar to `tm` would be a better idea: > > $ 9 nroff << EOF > > .tm Lorem ipsum dolor \" print to stderr > > EOF > > Lorem ipsum dolor > > Scrap that, I forgot to verify it's not actually adding a space. > It is: > $ 9 nroff << EOF 2>&1 | tr ' ' . > .tm Lorem ipsum dolor \" print to stderr > EOF > Lorem.ipsum.dolor.
Many times I've realized only _after_ sending an email that I didn't double-check one of my claims... In today's push to Savannah Git, I walked back some howlers about character definition requests that I inserted when doing a widely scoped revision to the groff(7) man page to try get coverage of _all_ of our supported request syntax. Fortunately, those howlers did not make it into a release. > Ideally, `so` would behave like `tm` except it would trim spaces > at the end, but I understand that this would be adding yet another > special case. Alternatively, we could make `tm` more consistent with `so` and numerous other requests (as they exist in groff Git's master branch). https://savannah.gnu.org/bugs/?66625 > Honestly, I never liked the fact `ds` doesn't trim trailing spaces. I'm confident this was done to keep nroff's parser as simple as possible. If spaces always "count", you don't have to scan ahead in the input to see if they actually don't. > I never understood why the standard way of adding spaces to the end > of a string is not following them with \&, e.g. > .ds x Lorem \& > .as x ipsum. The dummy character is a substantive thing; apart from its effect on end-of-sentence detection, in GNU troff it contributes to the measured length of a string. $ nroff .length a Lorem\" .length b Lorem \" .length c Lorem \&\" .pnr a b c a 5 0 b 6 0 c 7 0 (If you're not running a recent groff Git, you can use `tm` instead of `pnr` to dump the register values.) Regards, Branden
signature.asc
Description: PGP signature
