Follow-up Comment #3, bug #62233 (project groff):
[comment #2 comment #2:] > I do see your point, but I'm not sure I'm sold on the idea that the lack of a formal spec constitutes grounds for considering the various roff implementations as each a separate language unto itself. It's not quite _grounds_, but it is suggestive to me. > They seem more akin to dialects: someone who knows one dialect can pretty easily make sense of a document written in another. (If that "someone" is a person. Computers are less forgiving, but this is inherent in the rigidity of algorithms; C code that uses gcc extensions might fail to compile on other C compilers, but no one seems to be clamoring to call such code a separate language.) C programmers speak even to each other in terms of "C99", "C11", "K&R C", and over on TUHS we sometimes see references to "Typesetter C" (guess what typesetter they mean?). I'll grant, that might reinforce your point as much as it does mine. These languages are all "C" for broad purposes, and people get more specific when they need to. > The sheer amount of effort that most modern troffs put into reproducing even the most absurd aspects of Unix V7 troff seems to argue that they're all seeking to speak a common tongue. Acknowledged. > I appreciate your wanting to be as accurate as possible. But does sticking to strict accuracy here obscure a deeper truth about the basic commonalities of all the roff variants? I should research a point I've been wondering about for a while. As far as I know, roff(1) didn't have escape sequences _at all_. (At the time nroff was written, as I understand it, it didn't have macros, either, but they were retrofitted into it before it was left to...stabilize.) Okay, I'm beginning to budge on the point. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?62233> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/