[FFmpeg-devel] [PATCH] Fix some typos in avfilter.h

[Måns Rullgård]

The Wanderer <inverseparadox at comcast.net> writes:

> M?ns Rullg?rd wrote:
>
>> Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
>> 
>>>> Index: libavfilter/avfilter.h
>>>> ===================================================================
>>>> --- libavfilter/avfilter.h	(revision 14964)
>>>> +++ libavfilter/avfilter.h	(working copy)
>>>> @@ -125,7 +125,7 @@
>>>>   * list of the formats supported by each input and output pad. The list
>>>>   * given for each pad need not be distinct - they may be references to the
>>>>   * same list of formats, as is often the case when a filter supports multiple
>>>> - * formats, but will always outut the same format as it is given in input.
>>>> + * formats, but will always output the same format as it is given in input.
>>                                                                       ^^
>> "but the output will always be the same format as the input"
>
> This doesn't seem grammatical to me given the context of the phrase (and
> wouldn't really flow well even without that); the entire section after
> the final occurrence of the noun "filter" is in effect an adjective
> modifying that noun. I might paraphrase (not as a suggestion for actual
> use!) as something like "This is often true of a filter which, though it
> supports multiple formats, will always produce output which is in the
> same format as its input".

I disagree.  The word "but" starts a new independent clause, the
subject of which is "the output", implicitly understood to be that of
the filter discussed in the previous clause.  However, upon rereading
it, I agree it doesn't fit well.  In fact, the entire sentence is
unwieldy, but I'm too tired to try to think of a better one.

>>>>   * * In this way, a list of possible input formats and a list of
>>>> possible * output formats are associated with each link. When a set
>>>> of formats is @@ -184,8 +184,8 @@
>>>>  
>>>>  /**
>>>>   * Returns a format list which contains the intersection of the formats of
>>>> - * a and b. And all the references of a and b, and a and b will be
>>>> - * deallocated.
>>>> + * a and b. Also, all the references of a, all the references of b, and
>>>> + * a and b themselves will be deallocated.
>> 
>> "Also, a and b, and all references to either, will be deallocated"
>
> "references to X" and "references of X" do not mean the same thing - the
> former indicates things which refer to X, the latter I would interpret
> as indicating things which are referred to by X.

Reading the original again, I can't quite figure out what it's trying
to say.

> Also, this suggested form has the too-many-commas effect, which the form
> in the patch does not. That could be mostly fixed by dropping the final
> comma, but the state introduced by doing so has other problems which are
> harder to pin down.

Why are people so afraid of commas nowadays?  Commas help, not hinder,
readability.

-- 
M?ns Rullg?rd
mans at mansr.com