[vlc-devel] [PATCH 4/12] playlist: doc typo fixes

[Romain Vimont]

LGTM, thank you.

On Thu, Sep 24, 2020 at 11:30:07PM +0100, Lyndon Brown wrote:
> From: Lyndon Brown <jnqnfe at gmail.com>
> Date: Fri, 22 Mar 2019 19:17:26 +0000
> Subject: playlist: doc typo fixes
> 
> 
> diff --git a/include/vlc_playlist.h b/include/vlc_playlist.h
> index 5b35cf6ac9..ee9c0cf409 100644
> --- a/include/vlc_playlist.h
> +++ b/include/vlc_playlist.h
> @@ -55,7 +55,7 @@ extern "C" {
>   * The API directly exposes what list models require.
>   *
>   * The core playlist may be modified from any thread, so it may not be used as
> - * a direct data source for a list model. In other word, the functions of a
> + * a direct data source for a list model. In other words, the functions of a
>   * list model must not delegate the calls to the playlist. This would require
>   * locking the playlist individually for each call to get the count and
>   * retrieve each item (which is, in itself, not a good idea for UI
> @@ -68,29 +68,29 @@ extern "C" {
>   * out-of-sync view of the core playlist. This implies that the UI needs to
>   * keep a copy of the playlist content.
>   *
> - * Note that the copy must not limited to the list of playlist items (pointers)
> - * themselves, but also to the items content which is displayed and susceptible
> - * to change asynchronously (e.g. media metadata, like title or duration). The
> - * UI should never lock a media (input item) for rendering a playlist item;
> - * otherwise, the content could be changed (and exposed) before the list model
> - * notified the view of this change (which, again, would break the list model
> - * expected behavior).
> + * Note that the copy must not be limited to the list of playlist items
> + * (pointers) themselves, but also to the item's content which is displayed and
> + * susceptible to change asynchronously (e.g. media metadata, like title or
> + * duration). The UI should never lock a media (input item) for rendering a
> + * playlist item; otherwise, the content could be changed (and exposed) before
> + * the list model notified the view of this change (which, again, would break
> + * the list model expected behavior).
>   *
> - * It is very important that the copy hold by the UI is only modified through
> + * It is very important that the copy held by the UI is only modified through
>   * the core playlist callbacks, to guarantee that the indexes notified are
>   * valid in the context of the list model. In other words, from the client, the
>   * playlist copy is a read-only "desynchronized" view of the core playlist.
>   *
>   * Moreover, the events triggered by the playlist must be kept in order until
>   * they are handled. The callbacks may be called from any thread, with lock
> - * held (in practice, the thread from which a change is requested). An UI will
> + * held (in practice, the thread from which a change is requested). A UI will
>   * typically need to handle the events in the UI thread, so it will usually
> - * post the events in an even loop, to handle them from the UI thread. In that
> + * post the events in an event loop, to handle them from the UI thread. In that
>   * case, be careful to always post the events in the event loop, even if the
>   * current thread is already the UI thread, not to break the order of events.
>   *
>   * The playlist also handles the playback order and the repeat mode. It also
> - * manages a cursor to the "current" item, and expose whether a previous and
> + * manages a cursor to the "current" item, and exposes whether previous and
>   * next items (which depend on the playback order and repeat mode) are
>   * available.
>   *
> @@ -98,7 +98,7 @@ extern "C" {
>   * item, before the core playlist lock is successfully acquired, another client
>   * may have changed the list. Therefore, vlc_playlist_Request*() functions are
>   * exposed to resolve potential conflicts and apply the changes. The actual
> - * changes applied are notified through the callbacks
> + * changes applied are notified through the callbacks.
>   *
>   * @{
>   */
> @@ -777,7 +777,7 @@ vlc_playlist_GoTo(vlc_playlist_t *playlist, ssize_t index);
>   *
>   * If the index is known, use vlc_playlist_GoTo() instead.
>   *
> - * This is an helper to apply a desynchronized "go to" request, i.e. the
> + * This is a helper to apply a desynchronized "go to" request, i.e. the
>   * playlist content may have changed since the request had been submitted.
>   * This is typically the case for user requests (e.g. from UI), because the
>   * playlist lock has to be acquired *after* the user requested the change.
> diff --git a/src/playlist/randomizer.c b/src/playlist/randomizer.c
> index 5c22a55486..18bbd035fe 100644
> --- a/src/playlist/randomizer.c
> +++ b/src/playlist/randomizer.c
> @@ -186,7 +186,7 @@
>   *               <------------------------>
>   *                     history range
>   *
> - * Secondly, to avoid to select A twice in a row (as the last item of the
> + * Secondly, to avoid selecting A twice in a row (as the last item of the
>   * previous cycle and the first item of the new one), the randomizer will
>   * immediately determine another item in the vector (say C) to be the first of
>   * the new cycle. The items that belong to the history are kept in order.
> @@ -226,7 +226,7 @@
>   *
>   * The playlist calls _Next(), the randomizer randomly selects E. E
>   * "disappears" from the history of the last cycle. This is a general property:
> - * each item may not appear more than one in the "history" (both from the last
> + * each item may not appear more than once in the "history" (both from the last
>   * and the new cycle). The history order is preserved.
>   *
>   *                                history
> @@ -238,7 +238,7 @@
>   *              determinated     history range
>   *                 range
>   *
> - * The playlist then calls _Prev() 3 times, that yield C, then A, then B.
> + * The playlist then calls _Prev() 3 times, that yields C, then A, then B.
>   * 'next' is decremented (modulo size) on each call.
>   *
>   *                                history
> @@ -251,7 +251,7 @@
>   *                 range
>   */
>  
> -/* On auto-reshuffle, avoid to select the same item before at least
> +/* On auto-reshuffle, avoid selecting the same item before at least
>   * NOT_SAME_BEFORE other items have been selected (between the end of the
>   * previous shuffle and the start of the new shuffle). */
>  #define NOT_SAME_BEFORE 1
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel