I think most of the points here are academic now, but I do want to respond to a few.
On Tue, Dec 2, 2025 at 12:45 AM G. Branden Robinson <[email protected]> wrote: > Not at all. To set a new character flag on an arbitrary character x, > one just does it. If one really means for `\[em]` to both end a > sentence (if followed by appropriate whitespace) and for the line to be > eligible for breaking after it, one says so. Sloppy wording on my part; I should have said "set a new flag without clobbering existing ones." OR-ing, mathematically. > Also, if one wants to know what flags a character possesses, one can ask > with the new `pchar` request. Not programmatically, no--there's no > mechanism for returning a character's assigned flags in a register, > say--but this is a more easily obtained insight than has been available > heretofore. Granted, but not being able to do it programmatically still puts needless burden on the document author. (This point I think is academic because we now seem to agree that character classes are designed to OR in new flags without affecting existing ones.) > Do people really not know some of the "character flag" properties they > desire for a special character, but not others? I think most groff > users don't mess with character flags at all. (I presume one of those "not"s was a typo.) I think the roff language should be designed, as far as is practical, with power users in mind as much as ordinary ones. "Most users don't do this" should not imply "therefore we can make it needlessly difficult for those who do." > All of these save two entail breaking or sentence termination > properties. I assert that these are mutually entailing because breaking > implies (potential) hyphenation, and hyphenation is never applicable > after the end of a sentence. Breaking does not necessarily imply hyphenation. Consider the standard example I've been using, the em dash. In American English, it often appears between words without surrounding space—like this—and can traditionally have a break point after it (character flag 4) where a hyphen is never added. However, a character, especially a mark of punctuation, can have different requirements in different contexts. Using em dashes in a text as above does not preclude also using them in sentence-ending contexts (character flag 1), for example— Well, I can't think of an example right now. But you get the idea. So flags 1 and 4 defy your assertion of mutual entailiness. > > Two years later, when he needs to include a new macro package, he has > > to, first, remember that he used a .cflags request in this document > > two years ago, and second, audit the new macro package for any .cflags > > usage affecting character x. > > ...and this differs from anything else we might announce in the "NEWS" > file how, exactly? My point has nothing to do with a new release of groff, which is the only time a NEWS file comes into play. The situation can arise even for a user who installs groff 1.24 the day of release and will never upgrade. It has to do with maintenance of that user's own documents, not of adapting to a potentially changing groff. I'm not sure there's much point to clarifying what I meant here, though, since there is no longer a proposal to change groff 1.24 from its predecessors in this regard. > $ git grep -w cflags contrib tmac > contrib/mom/ChangeLog: o Added .cflags 4 /\(en -- was driving me nuts that > lines wouldn't > contrib/mom/NEWS:Added .cflags 4 /\(em to om.tmac. By default, mom now > obligingly > contrib/mom/om.tmac:.cflags 4 /\[en] \" So slash and en-dashes get broken This does highlight a typo in mom's NEWS file ("em" where it should say "en"). > So our churn rate for cflags changes for a given macro package is 1-3 > per somewhere between 10 years and never.[6] We should avoid the hubris of assuming macro packages distributed with groff are the only macro packages in the world.
