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

[Lyndon Brown]

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