Follow-up Comment #5, bug #67837 (group groff): At 2026-01-09T17:17:37-0500, Dave wrote: > Update of bug #67837 (group groff): > > Status: Need Info => None > Assigned to: barx => None > > _______________________________________________________ > > Follow-up Comment #3: > > I remain uncertain how the resolution of bug #67571 affects this bug. > It's fine to document how software _ought_ to work even if there are > known bugs in it. > > And I believe we know now the intent of Colin Watson and Daiki Ueno's > design: putting a character into a class does not change the > character's own flags directly, but causes (or should cause, modulo > #67571) the formatter to OR the class's flags with the individual > character's.
But _at what time_? When the `class` request is invoked, or later?
And if later, again, _at what time_?
That's how bug #67571 is involved--at least that's my suspicion, and why
I asked you to use this request to instrument your exhibit there.
That's the info I'm requesting of you.
> This is what .pchar now reports, but it is not mentioned in
> documentation.
A. It's a debugging request. We don't enumerate everything `pev`
reports, either, and never have. And that's not a defect.
B. These facts are mentioned as much they need to be, IMO; you inquire
about a character, you get its info. You inquire about a class, you
get its info.
.pchar c ...
Report, to the standard error stream, information about
each character (be it ordinary, special, or indexed) or
character class c. A character defined by a request (char,
fchar, fschar, or schar) reports its contents as a JSON‐
encoded string, but the output is not otherwise in JSON
format.
Why do I need to call out character flags here? They're a property, and
the request reports them.
$ echo '.pchar ,' | nroff
character ','
is not translated
does not have a macro
special translation: 0
hyphenation code: 0
inherent flags: 0 (none)
asciify code: 0
ASCII code: 44
Unicode mapping: U+002C
is found
is transparently translatable
is not translatable as input
mode: normal
$ echo '.pchar ,' | nroff -mja
character ','
is not translated
does not have a macro
special translation: 0
hyphenation code: 0
inherent flags: 0 (none)
effective flags: 128 (prohibits break before)
asciify code: 0
ASCII code: 44
Unicode mapping: U+002C
is found
is transparently translatable
is not translatable as input
mode: normal
> So taking this ticket out of Need Info, at least until Branden
> clarifies what info he still seeks, if any.
I need to know what it is you expect me to say about the "flag
interaction of character class and individual character".
What do _you_ think their relationship is? Please make a statement.
If I can understand it, and I can verify it as accurate by poking the
formatter appropriately (to the best of my limited skill), I'm happy to
add your claim to the manual.
Don't sweat the wordsmithing; I'll take care of that.
> <https://savannah.gnu.org/bugs/?67837>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67837>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
