On 2023-01-29 07:38, Alejandro Colomar wrote:
On 1/28/23 21:40, Brian Inglis wrote:
Seeing the recent tv_nsec patches drop the standard locale digit grouping
characters "," from the member range [0-999,999,999] made me regret the loss
of the punctuation which provides better and quicker comprehension of long
strings of digits.
Nice! Didn't remember about that separator. It makes a lot of sense to use it
in comments and the likes in the pages. Maybe we should be a bit more cautious
in source code examples, but definitely for big numbers outside of running code
should have them.
The major compilers support them from draft C23, and the code is in examples,
not source that has to compile on older compilers, so not much to be concerned
about there, although some more opinions would be helpful.
наб, would you please update your patches with that? I also have a few
comments that I'll write in a moment in answers to your patches.
It may be time to consider using the locale independent C23 digit
separator characters "'" wherever more than a handful of digits occur,
possibly convert grouping character uses in existing man pages as they are
changed, and specify a future standard policy approach to provide better
and quicker comprehension of long strings of digits: perhaps using a new
digit separator register and glyph escape sequence \*ds \*[ds] \[ds] \(ds
if not in use by base groff?
The sequence for the unslanted single quote is \(aq.
Granted, but would it not be better to consider using a semantic digit separator
groff man escape sequence, especially in text, whose rendering could be tweaked,
rather than a generic literal apostrophe quote used everywhere?
If nothing else is proposed and accepted, I will use the generic \(aq, and if
future changes are required, they can be targeted by digit context.
We could add somewhere in man-pages(7) that decimal numbers should use a
separator every 3 digits, and hex and binary should use it every 4 digits.
As well as the 3 decimal, 4 binary/hex, we could use yyyy'mm['dd]L for POSIX and
similar date digit strings, and 0x10'ffff for Unicode code points,
distinguishing between the Basic and Supplementary Multilingual Plane indices
and codes, just as examples from what I've seen so far.
I've also noticed a lot of apparently random decimal digit strings that are
binary powers or close deltas: those would be more comprehensible if rendered in
text as Ki/Mi/Gi[+/-n], so would that be preferable, using the IEC i suffix to
avoid ambiguity?
As well as the recently modified pages:
>> clock_getres.2
>> timer_settime.2
>> timerfd_create.2
>> utimensat.2
there appear to be obvious occurrences in only the following pages:
>> futex.2
>> read.2
>> sendfile.2
>> write.2
>> mallopt.3
>> keyrings.7
>> mq_overview.7
>> sched.7
>> time_namespaces.7
but there appear to be about 400 pages with more than 6 decimal digit
strings (some spurious glibc hex commits and address outputs) where it
could perhaps help, such as in POSIX version dates e.g. 2001'12L, and
undoubtedly more with long digit strings in other radixes.
Would you mind preparing a patch for all of those? If you'll do it, better
wait until we merge наб's patches, to avoid conflicts.
I'll start anyway, need to review over 300 files with over 900 digit strings,
having cut a bunch more pages with output examples.
Any particular subdivision of files patched into git logged patches, by section,
by type of edit, separate logged patches for files with many edits, or...?
FYI although many hits are likely output, the top candidates so far are:
80 man5/proc.5
55 man2/statfs.2
34 man7/feature_test_macros.7
32 man3/dl_iterate_phdr.3
30 man7/units.7
30 man5/rpc.5
23 man3/termios.3
20 man3/malloc_info.3
17 man2/userfaultfd.2
16 man7/keyrings.7
15 man7/time_namespaces.7
14 man7/posixoptions.7
14 man3/mallopt.3
13 man7/utf-8.7
12 man2/reboot.2
12 man2/keyctl.2
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
