changelog: Copy edit previous entry

CHANGELOG

@@ -12,7 +12,7 @@ improvements, so this changelog entry uses broader strokes than usual.
 
 - Which topics are displayed in the current buffer can now be changed, using
   the new prefix command ~forge-topics-menu~, available on ~N m f~.  This command
-  is available in any buffer that lists topics, including the status buffer.
+  is available in any buffer that lists topics, including Magit status buffers.
 
   Previously topic filtering relied on dedicated commands (which listed a
   hard-coded subset in a separate buffer) and functions (which inserted a
@@ -22,15 +22,15 @@ improvements, so this changelog entry uses broader strokes than usual.
   The default filters can be customized using the new
   ~forge-list-buffer-default-topic-filters~ and
   ~forge-status-buffer-default-topic-filters~ options.  If you really want to
-  insert additional hard-coded sets of topics in dedicated section in the status
-  buffer, you can still define them yourself, with the help of the new helper
-  function ~forge-insert-topics~.
+  insert additional hard-coded sets of topics in dedicated sections in the
+  status buffer, you can still define them yourself, with the help of the new
+  helper function ~forge-insert-topics~.
 
 - Dedicated buffers used to list topics now use a major mode derived from
   ~magit-mode~, instead of from ~tabulated-list-mode~.  This makes it possible to
   remove a lot of duplication (because these buffers now use the same code as
-  the topic list sections displayed in the status buffer), and makes adding new
-  features more feasible.
+  the topic list sections, displayed in the status buffer), and makes adding
+  new features more feasible.
 
 - ~forge-dispatch~ and the newly added menu commands (such as the already
   mentioned ~transient-topics-menu~) now provide bindings to switch to any of the
@@ -39,34 +39,34 @@ improvements, so this changelog entry uses broader strokes than usual.
   This should make it easy to discover the new commands, and reduces the need
   to memorize new key bindings.  It is sufficient to remember that ~N~ invokes
   ~forge-dispach~, and to then browse the other menus from there.  That being
-  said, more efficient but harder to remember, bindings are also available,
+  said, more efficient, but harder to remember, bindings are also available,
   such as:
 
 - The new prefix command ~forge-topic-menu~, now provides the most convenient way
   to edit an existing topic.  When point is on a topic, it can be invoked using
   ~C-<return>~.  As is always the case in Magit, ~RET~ visits the thing at point in
-  a separate buffer.  In the case of topics ~C-u RET~ does both; it displays the
+  a separate buffer.  In the case of topics, ~C-u RET~ does both; it displays the
   buffer and the menu.
 
-- The parts of the Github API that one has to use when syncing the private
-  topic status are truly abysmal.  When I first created Forge, I figured that
-  something so fundamentally broken would surely be fixed within a few months
+- The parts of the Github API, that one has to use when syncing the private
+  topic status, are truly abysmal.  When I first created Forge, I figured that
+  something so fundamentally broken would surely be fixed within a few months,
   and decided to wait until that was done.
 
   I was wrong, five years later nothing has changed, and I had no choice but to
   put in a lot of effort to implement workarounds, to achieve something that is
-  worse than what could be trivially achieved if the API were merely bad.
+  worse than what could be trivially achieved, if the API were merely bad.
 
   Most frustratingly the ternary unread/pending/done is represented in API
   responses using a boolean.  That obviously puts limits on the accuracy one
   can achieve in a third-party client.  While that is the worst defect, it is
   just the tip of the iceberg.
 
 - All the possible values for the public "state" and the private "status" of
-  topics are now fully supported.
+  topics are now supported.
 
   The public state basically answers the question whether a topic has been
-  closed yet, and if so for what reason.  The state can be one of ~open~,
+  closed yet, and if so, for what reason.  The state can be one of ~open~,
   ~completed~ and ~unplanned~ for issues, and ~open~, ~merged~ and ~rejected~ for
   pull-requests.
 
@@ -75,21 +75,21 @@ improvements, so this changelog entry uses broader strokes than usual.
   you have additionally decided that you are "done" with that topic.
 
   Due to the defects of the Github API mentioned above, the distinction between
-  the ~pending~ and ~done~ statuses of a topic cannot be synchronized with Github,
-  so if you use both Forge and the web interface, you will sadly have to perform
+  the ~pending~ and ~done~ statuses of a topic cannot be synchronized with Github.
+  So if you use both Forge and the web interface, you will sadly have to perform
   the "mark as done" action twice.
 
 - By default Forge now lists "active" topics, i.e., topics whose public state is
   ~open~ and/or whose private status is ~unread~ or ~pending~.  In other words ~active~
-  topics are those that might still require your attention.
+  topics are those that likely still require your attention.
 
 - At least Emacs 27.1 is required now.  Several dependencies have bumped their
   respective minimal requirement, so I had no choice in the matter, but to be
   honest, I am not unhappy about it.
 
 - EmacSQL 4.0.0 is required now, which automatically uses the best available SQL
-  backend.  The new backend, which utilizes the built-in support, added in Emacs
-  29.1, is preferred.  When using an older Emacs version, or when Emacs unwisely
+  backend.  The new backend, which utilizes the built-in support (added in Emacs
+  29.1) is preferred.  When using an older Emacs version, or when Emacs unwisely
   was compiled without SQLite support, then a different new backend is used.
   That backend uses the C module provided by the ~sqlite3~ package, which you have
   to install explicitly.  If the module also isn't available, the legacy backend
@@ -159,7 +159,7 @@ improvements, so this changelog entry uses broader strokes than usual.
   ~forge-topic-unmerged~.
 
 - Added new Git variable ~forge.graphqlItemLimit~.  Ghub now fetches fewer items
-  at once by default, but if you repeatedly get ~HTTP Error 502, "Bad gateway"~
+  at once by default, but if you repeatedly get ~HTTP Error 502, "Bad gateway"~,
   when pulling API data for some repository, then limiting this to below 50
   is likely to help (but results in more requests and slows down pulling.)