Follow-up Comment #3, bug #67570 (group groff):

At 2025-10-04T11:48:14-0400, Dave wrote:
> Follow-up Comment #2, bug #67570 (group groff):
>
> [comment #1 comment #1:]
>> I notice I forgot something in the new `pchar` request:
>>
>> It should try to resolve the argument as a character class first.
>
> I don't see why.  The .class request doesn't define a character, so
> one wouldn't expect .pchar to analyze it as a character.

You might, because (special) characters and character class occupy a
shared name space.

So we have an opportunity to help the user troubleshoot an issue where
they accidently masked a special character name with a character class.

> And as the manual says, "Currently, only the 'cflags' request can
> handle references to character classes."  So even if .pchar did return
> something for it, the only data points it could return are the
> characters in the class and its set of flags, as that's the only data
> a character class can hold.

I was thinking of having `.pchar [class]` list the members of the class.

> This might be marginally useful, but it'd be a surprising use for
> .pchar rather than a separate request, say, .pclass (although the two
> sharing a namespace does muddy this some).

Your parenthetical is exactly my thought.

>> $ printf '.class [EOS] \\[em]\n.pchar [EOS]\n'
>
> Because the class name contains the ] character (as recommended in the
> manual to avoid namespace collisions), it has to be dereferenced with
> the \C escape, so the above .pchar syntax doesn't access the class
> anyway.

Yes, but if someone fails to follow this advice, they could step on a
special character name.

In any case, _something_ has to be done:


$ printf '.pchar \\C#[CJKprepunct]#\n' | ./build/test-groff -mja
/home/branden/src/GIT/groff/build/../tmac/ja.tmac: warning: font TR may lack
coverage of Japanese script
special character "[CJKprepunct]"
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 0
  flags: 128 (prohibits break before)
  Unicode mapping: none (-1)
  ASCII code: 0
  ASCII code: 0
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal


That's misleading.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?67570>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to