On Sat Feb 22, 2025 at 4:46 AM CET, onf wrote: > On Sat Feb 22, 2025 at 2:06 AM CET, G. Branden Robinson wrote: > > 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.
I forgot to emphasize the likely largest obstacle, which is the fact that it would break compatibility with documents written for neatroff. Ali seems averse to breaking backwards compatibility with both AT&T troff and past versions of neatroff. I feel like changing ab, hpf, hpfa, nx, so, and tm (the others aren't implemented by neatroff) to allow spaces in the middle of their arguments might have more chance of success. ~ onf
