[CC list trimmed since this is solely about English and *roff]
At 2022-06-06T15:40:08-0400, Peter Xu wrote:
> > I think the patch below would improve a little bit the wording (and
> > newlines). I still have a bit of trouble understanding "When a
> > kernel-originated fault was triggered on the registered range with
> > this userfaultfd". Did you maybe mean "range registered" instead of
> > "registered range"?
>
> Since I'm not a native speaker I don't immediately see the difference
> between the two.
Short answer: I think your existing wording is acceptable.
As a native speaker (but not a trained linguist) I think I can speak to
the subject: both forms are equivalent in this application. In standard
English, adjectives usually precede the nouns they modify. Exceptions
include noun phrases borrowed from other languages, like "danse
macabre", word order reversals for poetic dramatic effect ("I sing the
body electric"), or clarity in cases where compound adjectives need to
be applied disjunctively instead of conjunctively, as in "this race is
open to runners fast and slow". (Any given runner is fast or slow, not
both simultaneously. In everyday spoken language, this point of clarity
is frequently overlooked, but it's helpful in formal communication.)
In the instant case, "registered range", "registered" is an attributive
adjective modifying "range". When the order is reversed, it is a
shorter form (but still standard) of "range that is registered", where
the "registered" serves as more of a predicate adjective, albeit in a
restrictive clause.[1]
"Registered" is the past participle form of the infinitive verb "[to]
register", and it is extremely common for participles present and
past[2] to be used as adjectives. It is not universally the case,
however.[3]
> It's always challenging for me to grasp how you prefer the newlines
> are made, but anyway below changes looks good to me.
If it helps, here is a snippet of recommendations for *roff input from
the GNU Troff Manual.
* Follow sentence endings in input with newlines to ease their
recognition. It is frequently convenient to break after colons and
semicolons as well, as these typically precede independent clauses.
Consider breaking after commas; they often occur in lists that
become easy to scan when itemized by line, or constitute
supplements to the sentence that are added, deleted, or updated to
clarify it. Parenthetical and quoted phrases are also good
candidates for placement on input lines by themselves. In filled
text, spaces and newlines are interchangeable; place breaks where
it aids your purpose.
* Set your text editor's line length to 72 characters or fewer.
This limit, combined with the previous advice regarding breaking
around punctuation, makes it less common that an input line will
wrap in your text editor, and thus will help you perceive
excessively long constructions in your text. Recall that natural
languages originate in speech, not writing, and that punctuation is
correlated with pauses for breathing and changes in prosody.
* Use '\&' after '!', '?', and '.' if they are followed by space,
tab, or newline characters and don't end a sentence.
* In filled text lines, use '\&' before '.' and ''' if they are
preceded by space, so that reflowing the input doesn't turn them
into control lines.
What Alex terms "semantic newlines" are a venerable practice in
composition of *roff documents, and have been passed down from Brian
Kernighan of Bell Labs and C programming fame. Slightly less famously,
he rewrote the Unix Version 7 troff program to be device-independent.
So we can safely say that it's a 40-year tradition, at least. To some,
however, its age may not recommend it. ;-) Fault-handling in user mode
is certainly arriving none too soon. Thank you for your work on it.
Regards,
Branden
[1] https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html
[2] See what I did there?
[3] https://english.stackexchange.com/questions/264236/can-any-verbs-present-and-past-participles-be-used-as-adjectives
Attachment:
signature.asc
Description: PGP signature
