On Sat Feb 22, 2025 at 2:06 AM CET, G. Branden Robinson wrote: > At 2025-02-22T01:31:28+0100, onf wrote: > > 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
[re-arranging] > Combining your parenthetical with "all of this", I perceive a general > grievance with the direction of groff development. > > If you mean some more narrowly focused form of critique, I would ask you > to be less vague. Sorry for not expressing myself more clearly. By "all of this", I meant the changes being discussed in this thread, i.e. the conversion of ab, hpf, hpfa, mso, nx, so, tm, msoquiet, soquiet, opena, cf, and trf to the syntax used by ds. > I wonder about it a bit myself, which is why the bug is "open" with > status "none". (It could just as well be "postponed", since once I've > detangled myself from the many ramifications of Savannah #66675, I think > it will be about time for a release candidate.) > > But I think it makes sense to reason about backward compatibility in > concrete, not merely abstract terms. > > How many people are putting double quotes at the beginnings of the > terminal messages they write with `tm` and `ab`? Because that's the > only change here. (And it's why GNU troff has `tm1`.) > Maybe some people have done so; As pointed out above, I was responding to the broader changes, and those aren't just about double quotes at the beginning. They will break most instances of those requests that have comments next to them. > > (not to mention the already limited interoperability with Heirloom > > troff and neatroff). > > When Heirloom Doctools troff was undergoing more active development, > this mailing list saw at least occasional participation from Carsten > Kunze, and he has a GNU Savannah account to this day. I think the best > way to manage interoperability concerns is to raise them on this list, > especially with planned changes, but I'm not sure that philosophy has > been shared by developers of non-GNU troffs. Well, that's partly why I was trying to bring attention to the breaking changes. > if I follow through on Savannah #66625, > I mean to preserve traditional AT&T troff behavior of `tm` and `ab` in > compatibility mode, mainly because I can imagine people using `tm`, if > not `ab`, to write out indexing or bibliographic material in a format of > their choice. CSV format, which will surely start with a quotation mark > if the first field on the line has embedded spaces, is not the wildest > possibility, even if not deeply embedded in Unix text-file processing > tradition. > > In compatibility mode, I remind the reader, one can still obtain GNU > troff behavior via the `do` request. That might be all fine for groff, but this fact by itself makes the new behavior unlikely to be adopted by neatroff. The problem is that in neatroff, there are a few generalized routines which parse arguments and hand them to the functions implementing the requests themselves. Which one of these functions gets executed for a given request is not decided dynamically, but is pre-defined in a static array. This means that for neatroff to implement this, it would have to modify these static settings whenever the compatibility mode changes. That's of course doable, but it would complicate the code, and from the few conversations I have had with Ali so far, I feel like he would see the added complexity as not worth it. You can bring up the topic with him if you want so that you won't have to rely on my assumptions, but bear in mind that he often takes over a week to respond and doesn't cope well with long messages full of digressions. I would message him about it myself, but there are already several threads I have open with him to which I have yet to receive a response, so I doubt starting *yet another one* would help. > Mainly, people seem to follow their own muses. > And that's fine, but I don't think it's fair to defend the prerogatives > of other troffs to innovate in whatever ways strike their developers as > expedient while at the same time insisting that GNU troff stand still, > vis à vis interoperability. Fair enough. What I was concerned about is that interoperability between groff and neatroff already leaves a *lot* to be desired, and with these changes it might only get worse. With that said, looking at how neatroff often diverges from groff even in naming its requests (`dv` vs `device`, `cl` vs `gcolor`, etc.), I guess it's fair to conclude that the two projects simply have a different vision for how a modern troff should look like. (Heck, I don't even know if Ali would agree with calling neatroff a modern troff.) > > > > 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`? > > In theory, they might, so we can never change it. Isn't that your > argument against Savannah #66625 and "all of this"? Well, I figured that since you are determined to make breaking changes anyway, it might as well be some "better" breaking change. It was just an idea, though. I realize that the string-handling requests are quite complex, and changing the way the aforementioned requests process their arguments is much easier. > > Because if not, `length` and `substring` could simply ignore \), too. > > There's a nice, big, juicy can of worms implicated here. I can't find > the message right now, but I've written before (recently, even) about > just how ill-defined the interaction of "nodes" with string contents is. I vaguely remember it being a mess. > Even `\)` is not a synonym for "nothing".[1] Observe. > [...] > I can imagine a document author getting pretty frustrated if a string > seemed to interpolate nothing, its length measured zero, and yet upon > being interpolated, it caused a page to be output. Point taken. ~ onf
