Subject: Re: bug#44155: Print integers as characters

From: Mattias Engdegård <[email-masked]>
Date: Wed, 4 Nov 2020 12:03:32 +0100

3 nov. 2020 kl. 20.36 skrev Eli Zaretskii <[email-masked]>:

> Thanks, but my main question is still not answered.  I asked it from
> the POV of documentation: we should provide a more specific
> description of which characters will be printed as characters, so that
> users are not surprised.  The text in NEWS still says "printable
> characters" without defining that term, and so does the doc string of
> print-integers-as-characters.

'Printable' was used informally, not in an exact technical meaning. Intuitively, it should be the set of characters that make sense to print using the '?X' syntax. I initially thought that 'graphic' was too technical but it is more precise. 'Independently printable graphic character' is descriptive but a mouthful; perhaps 'independent graphic char' would do?

> And now there's another question, which is what caused you to filter
> characters like you did?  E.g., what's wrong with combining classes?
> why not simply use graphicp?

For the ?X syntax to make sense, X must be visible; thus controls are out, and so are formatting chars (language tags etc). Spaces should probably have been excluded as well since it's typically not possible to see what kind of space follows the '?' (SPC is explicitly rendered as ?\s).

Furthermore, X must be independent since it isn't a grapheme cluster but a single code point. Therefore combining chars cannot be included as they would attach to the '?'.

'graphicp' cannot be used because it includes combining, enclosing and nonspacing marks (M) and formats (Cf); otherwise it's fine.

While we could put the exact list of excluded general categories in the documentation, it is not very important because the selection only matters for usability and aesthetics, not (realistically) for code behaviour.

The attached patch excludes spaces (Zs) and revises the terminology.