Follow-up Comment #4, bug #67711 (group groff): [comment #3 comment #3:] > What evidence do you have to support this interpretation?
Er, well, primarily the fact that it works that way, but also the fact that
it's a logical design feature, given (1) the lack of a way for the language to
query a character's flags and (2) the .cflags request overwriting rather than
augmenting existing flags. And now also the fact that pchar reports results
in line with this interpretation.
> Specifically, where in existing _groff_ macrology do you see
> this property leveraged?
I don't look at a lot of groff macrology written by others, but the initial
exhibit of bug #67570 was drawn from my own use. A big part of the reason to
use the class for \[em] (as the indirect.roff snippet does) is that specifying
".cflags 1 \[em]" (as in the direct.roff example) clobbers the character's
default 4 flag. Using the class has effectively given the character both
flags since the .class request was introduced in groff 1.21. (I can trace my
first use of ".class [EOS] \[em]" to December 2011.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67711>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
