Re: [PATCH-v2] Documentation: remove duplicated words

[Adam Kropelin <akropel1@rochester.rr.com>]

Paolo Ornati <ornati@fastwebnet.it> wrote:
> 
> Remove every (hopefully) duplicated word under Documentation/ and do
> other small cleanups.
> 
> Examples:
> 	"and and" --> "and"
> 	"in in" --> "in"
> 	...

When the duplicatation was due to a typo, removing the duplicate is the
not the correct fix. Additionally, there are cases where the text
actually reads better (or no worse) with the duplication in place.

> -                        matches the field we filled in in the struct
> +                        matches the field we filled in the struct

Should probably be left as is: "matches the field we (filled in) in
the struct"

> -device. Individual PCI device drivers that have been converted the the current
> +device. Individual PCI device drivers that have been converted the current

First "the" is actually a typo for "to".

> -  a directory entry.  The directory entry requested carries name name
> +  a directory entry.  The directory entry requested carries name
>    and Venus will search the directory identified by cfs_lookup_in.VFid.

Suspect first "name" should be "the".

> -       The CPU to SPU communation mailbox. It is write-only can can be written
> +       The CPU to SPU communation mailbox. It is write-only can be written 

First "can" should be "and".

>  This doesn't seem important in the one button case, but is quite important
> -for for example mouse movement, where you don't want the X and Y values
> +for example mouse movement, where you don't want the X and Y values
>  to be interpreted separately, because that'd result in a different movement.

Probably should be rephrased in general. Author probably intended it to
be parsed as "...but is quite important for, for example, mouse
movement...".

> -a trailing = on the name of any parameter states that that parameter will
> +a trailing = on the name of any parameter states that parameter will

Again, "states that (that parameter)" while not great English is
probably exactly what the author intended.

>  Life isn't quite as simple as it may appear above, however: for while the
> -caches are expected to be coherent, there's no guarantee that that coherency
> +caches are expected to be coherent, there's no guarantee that coherency
>  will be ordered.  This means that whilst changes made on one CPU will

And again: "...no guarantee that (that coherency) will be...".

...possibly more; this is as far as I got.

--Adam