Follow-up Comment #5, bug #67711 (group groff): At 2025-11-17T14:38:22-0500, Dave wrote: > 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.
We're mismatching our impedances again! I agree with both of these
premises, but...
> And now also the fact that pchar reports results in line with this
> interpretation.
...not with this conclusion. `pchar` reports results **out of line**
with this interpretation.
If the `cflags` request overwrites rather than augmenting (or performing
a union operation on the set of bits in the character's "flags"), then
we would not see this output (groff Git HEAD).
$ ./build/test-groff --version|head -n 1
GNU groff version 1.23.0.4281-20a41b
$ ./build/test-groff -a
.class [EOS] :
.cflags 1 \C'[EOS]'
.pchar :
character ':'
is not translated
does not have a macro
special translation: 0
hyphenation code: 0
flags: 0 (none)
asciify code: 0
ASCII code: 58
Unicode mapping: U+003A
is found
is transparently translatable
is not translatable as input
mode: normal
> 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.
I think that the character's '4' flag _should_ be clobbered. A
character class does layer additional properties or some kind of delta
on top of existing characters. It is simply a shorthand for lists of
characters.
If I wouldn't expect the request sequence:
.cflags 4 :
.cflags 1 :
...to preserve the `:` character's "4" flag, then I shouldn't expect:
.cflags 4
.class [EOS] :
.cflags 1 \C'[EOS]'
...to preserve it either, because, I submit, the two are semantically
identical. (Except that the latter changes the value of the newly
implemented `.class` read-only, Boolean-valued register.)
> 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.)
In that case I regret to say that the correct thing to do is to break
this usage and "NEWS" it. I don't think the rest of the character class
feature is designed consistently with this behavior.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67711>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
