On Sat Feb 22, 2025 at 12:12 AM CET, G. Branden Robinson wrote: > At 2025-02-21T15:22:02+0100, onf wrote: > [...] > > 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
Personally, I don't like how all of this breaks backwards compatibility (not to mention the already limited interoperability with Heirloom troff and neatroff). > > 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. My hypothesis was that it must be due to \& having consequences for end of sentence recognition, but yours sounds more likely. > > 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. One could use \) to avoid end of sentence detection. (Yes, I know it's a groff invention.) The latter is trickier, but I wonder if anyone relies on `length` for anything other than `substring`? Because if not, `length` and `substring` could simply ignore \), too. ~ onf
