doc: update NEWS/mu4e manual

NEWS.org

@@ -3,20 +3,24 @@
 
 * 1.12 (post 1.12.0 updates)
 
- The 1.12 series has been opened for a fairly long time, and gained some
+ The 1.12 series has been the stable one for a fairly long time, and gained some
- changes, some beyond mere bug-fixing. We decided to put off a new development
+ changes in mean-time. Most of the changes are for big bugs, but some small new
- series (1.13 -> 1.14) until incompatible changes are required; for now working
+ features are available as well. We decided to put off a new development series
- in the 1.12 series seems a good way to get improvements to users more quickly.
+ (1.13 -> 1.14) until incompatible changes are required; for now working in the
+ 1.12 series seems a good way to get improvements to users more quickly.
 
   - man documentation improvements
 
   - message composition has been reworked to avoid a number of problems user
-    reported
+    reported. It is now directly uses the Gnus machinery, but integrate inside
-
+    mu4e.
-  - many small mu4e bugs fixed, usually very old ones
 
   - with 1.12.7, ~mu~ indexing is single-threaded again, to avoid cases of
-    database-corruption that have appeared.
+    database-corruption. This of course means that in *mu4e* you need to _wait_
+    until indexing is ready before you can continue (*mu4e* will warn you). If you
+    see that warning often, perhaps your indexing is too slow, see the section
+    on "Speeding up indexing" in [[info:mu4e#Retrieval and indexing][Retrieval and indexing]] in the mu4e manual.
+
 
 * 1.12 (released on February 24, 2024)
 

mu4e/mu4e.texi

@@ -545,16 +545,16 @@ because you are running your own mail-server, you can leave
 @t{mu4e} won't try to get new mail, but still re-index your messages.
 
 @subsection Speeding up indexing
+@anchor{Speeding up indexing}
 
-If you have a large number of e-mail messages in your store,
+If you have a large number of e-mail messages in your store, (re)indexing might
-(re)indexing might take a while. The defaults for indexing are to
+take a while. The defaults for indexing are to ensure that we always have
-ensure that we always have correct, up-to-date information about your
+correct, up-to-date information about your messages, even if other programs have
-messages, even if other programs have modified the Maildir.
+modified the Maildir.
 
-The downside of this thoroughness (which is the default) is that it is
+The downside of this thoroughness is that it is relatively slow, something that
-relatively slow, something that can be noticeable with large e-mail
+can be especially noticeable with large e-mail corpora on slow file-systems. For
-corpora on slow file-systems. For a faster approach, you can use the
+a faster approach, you can use the following:
-following:
 
 @lisp
 (setq