Follow-up Comment #9, bug #67711 (group groff): At 2025-11-17T16:33:56-0500, Dave wrote: > Follow-up Comment #6, bug #67711 (group groff): > > [comment #3 comment #3:] >> The foregoing conceptual model is unclear both in documentation > > I agree that, whichever model is correct, it is underdocumented. > >> the purpose of a character class is to avoid major tedium > > Sure, but this purpose isn't at odds with the other purpose I've > cited. Indeed, this tedium-dodge is just as effective no matter which > model underlies it.
Here I must disagree. One model has `cflags` requests logically
"or"-ing the first argument with each character in a (potentially
"rangy", potentially recursively nested, class) in the remaining
arguments.
The other model does not. If you apply `cflags` to character classes
containin any characters with flag values other than zero, these two
models behave materially differently.
> My model (a.k.a. the way it has always worked) just gives it more
> flexibility.
At the cost of making it, I think, more conceptually complex.
>> And I think, though I'm not sure, that your model is not
>> consistent with the behavior you're seeing in bug #67571, which
>> explains why you're surprised by that behavior and I'm not.
>
> I find the #67571 behavior inexplicable no matter what model is used:
> intervening output should not make a .class definition get lost. But
> I feel we're on the same page there now, so the above text is probably
> obsolete.
I'm happy to acknowledge a meeting of the minds on this point. :)
>> I think my interpretation is consistent with Werner's express
>> motivation in _groff_'s corresponding "NEWS" file entry
>
> I'd claim my interpretation is not inconsistent with it. He said
> "This is especially useful to...", not "This is exclusively useful
> to..."
True, but I'm a mean old S.O.B. who feels that if we have a "use(ful)
case" that is not tested and yet operationally distinguishable from one
that we _do_ test, then my feeling is that, by God, we should have an
exhibit thereof so that we _can_ test it.
I also admit to some confusion as to the utility of the case you've
pitched. Of itself, sticking a character (like `:` or `\[em]`) into a
character class _of itself_ should not change any of the contained
characters' properties.
.class [EOS] \[em]
...isn't going to change anything about how GNU _troff_ makes breaking
decisions around `\[em]`. You have to subsequently say...
.cflags 4 \C'[EOS]'
Am I missing some further property of your case?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67711>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
