[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44155: Print integers as characters

From: Eli Zaretskii
Subject: bug#44155: Print integers as characters
Date: Wed, 04 Nov 2020 17:38:35 +0200

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 4 Nov 2020 12:03:32 +0100
> Cc: juri@linkov.net, schwab@suse.de, 44155@debbugs.gnu.org
> '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?

I'm not sure.  I think we should use something more familiar, or
explain it in more detail.  We already mention Unicode properties
elsewhere in the manual, so we could define this in those terms, and
send the reader there for the details, for example.

> 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.

I'm not going to argue about this aspect, but just FTR: whether to
include combining characters is a decision that we make here, it is
not a necessity.  Because we are perfectly capable of displaying
combining characters without risking them to become composed with
surrounding characters: we could either precede them with U+25CC
DOTTED CIRCLE, or use the technique describe-char-padded-string in
descr-text.el uses.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]