On Mon, Nov 17, 2025 at 4:34 PM G. Branden Robinson <[email protected]> wrote: > I won't attempt to completely characterize Dave's position, but it > differs. I think it's fair to say that he envisions classes as having > additional properties compared to my view.
I don't really envision anything. I note that the behavior I've observed since first using classes in 2011 differs from the model you've presented, and in a way that makes the language more useful than how you seem to want it to work. I'd use a simpler example than the one you presented to make my point. Suppose you want the em dash to have the end-of-sentence property (in character flags parlance, having flag 1 set). You might be tempted to say: .cflags 1 \[em] And this would work to set its end-of-sentence property--but it would have the side effect of overwriting the flag (4) that \[em] already had set. So instead you might do this: .class [EOS] \[em] .cflags 1 \C'[EOS]' This has, since the first groff release where .class was introduced, had the observable effect of making the em dash recognized as ending a sentence (flag 1) while retaining its breaking behavior (as encoded in flag 4). Why is this significant? Because if you want to add a flag to a character's existing flags, there is no other way to do it. The .cflags request only overwrites all existing flags; it does not have a syntax to preserve flags while adding a new one. And the language has no mechanism for returning a character's current flags. (Recent, post-1.23 groff builds include a request that lets you dump the flags, along with much other info about a character, to stderr, but groff is still unable to access that value from within a document.) So you can't compute the flag you want to add ANDed with any existing flags. So the current .class behavior provides useful functionality. Thus I presumed the behavior was intended; but even if not, I see no benefit to altering it to fit a different model that makes impossible an operation that is currently possible.
