Hi Alex,
At 2022-11-23T14:48:27+0100, Alejandro Colomar wrote:
> This adds consistency across other manual pages, and with POSIX.1.
>
> Signed-off-by: Alejandro Colomar <alx@xxxxxxxxxx>
> ---
> zic.8 | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
[...]
> -A time zone abbreviation uses a
> +A timezone abbreviation uses a
[and so on similarly]
I mildly object to this on English style grounds. Like "filename" or
"filesystem", it seems like a corruption of an English compound noun by
programmers accustomed to writing identifiers in programming
languages.[1] Such people might also write "icecream", which is widely
recognized as a solecism, if ice cream were to ever be discussed in the
context of an API. The space is semantically significant: a
"greenhouse" is not the same thing as a "green house".
I believe there are a few advantages to preferring spaces in compounds
except where _general_ English usage (as opposed to that of Unix nerds)
has beaten a track the other way.
1. They may be easier to parse for non-native English speakers. I was
going to say that this point would not apply to a German speaker,
who can morphologically analyze a 100-letter compound without
reducing the blood glucose level in their brain an iota, but on
second thought that may not be true. English is notorious for
borrowing from any language in the world, and a triple compound
combining Germanic, Latinate, and Mi'kmaq roots is conceivable.
This process may challenge even a native German's world-class
ability to detect morpheme boundaries.
2. When divided, spaceful compounds don't need to be added to anyone's
spell checking dictionary if their roots are already present (as
they certainly will be here).
3. When divided, spaceful compounds are at less risk of incorrect
hyphenation when typeset. (We speak of TeX and troff and other
systems as having hyphenation "algorithms", and while this is
literally true, they are algorithms with huge lists of rules and
exceptions, and they are applied to large and ever-growing open
classes of inputs. They therefore _behave_ heuristically [albeit
deterministically], I submit, and can produce incorrect hyphenation
break points through no fault of the algorithm itself.)
4. Compounds that retain their spaces will fill and break lines more
evenly, reducing the risk of large gaps between words when
adjustment is performed, especially on terminal devices that can
only adjust lines coarsely (an entire character cell at a time).
If, in context, one fears that a line break within a compound used
in a man page will damage the comprehensibility of a sentence, then
one should probably recast the sentence, but in a pinch one can use
a non-breaking space to avoid the problem, as with "time\~zone".
I acknowledge that any of the above can be of little concern to some.
So if it were me I would start driving man pages toward consistency in
the other direction (spoiler alert: I've already done this for many
groff man pages) and not worry about consistency with POSIX.1 here.
Regards,
Branden
[1] _Most_ programming languages, that is. Some are lexically analyzed
such that spaces are permissible in identifiers. In Fortran's old
fixed-source form, this was the case because spaces were completely
ignored in input (outside of string literals, maybe). There is a
famous, albeit semi-apocryphal, bug story arising from this.[2]
Fortran implementations, like those of C and Perl after them, spent
many years being quite liberal in what they accepted.
[2] The bug was real but legend often hyped it up into causing loss of a
spacecraft (cf. "space craft" ;-) ).
https://www-users.cs.york.ac.uk/susan/cyc/p/fbug.htm
Attachment:
signature.asc
Description: PGP signature
