Am 19.02.2017 um 00:16 schrieb Brendan Cully: > changeset: 6941:e4a5d1913e42 > user: Kevin McCarthy <ke...@8t8.us> > date: Sat Feb 18 15:15:01 2017 -0800 > link: http://dev.mutt.org/hg/mutt/rev/e4a5d1913e42 > > Add 1.8.0 entries to the UPDATING file. > > diffs (52 lines): > > diff -r 943b281abfbb -r e4a5d1913e42 UPDATING > --- a/UPDATING Sat Feb 18 21:30:27 2017 +0000 > +++ b/UPDATING Sat Feb 18 15:15:01 2017 -0800 > @@ -4,6 +4,48 @@ > The keys used are: > !: modified feature, -: deleted feature, +: new feature > > +1.8.0 (2017-02-24): > > + ! The user's muttrc will additionally be searched for in > + $XDG_CONFIG_HOME/mutt/.
Can I propose a few changes to make this file more understandable? The last one I've quoted above looks complicated to me with its passive voice and its weasling around the subject. How about "Mutt will look for the user's muttrc additionally in $XDG_CONFIG_HOME/mutt/."? > + ! OpenSSL certificate verification has been reworked to suppport > alternative > + chains. I do not mean to offend anyone, but I've always been scratching my head over this description. The "reworked" is a less important part because we're not using magic; but even if the line read "OpenSSL certificate verification now supports alternative certificate chains." I'd probably scratch my head over it unless I were acquainted with how X.509 certificate signing chains work. Are we solving a practical problem with it? Then a summarized version of the problem we are solving might help the user understand what good this change is up to. > + + <subjectrx> allows replacing matching subjects with something else. > + This can be used to declutter subject lines in the index. Is this to cure "Re: AW: Re: AW: Rép: AW: Re: WG: Re: Fw: Re^2: RE:" and boil it down to "Re: Fw:"? Or would that be too hard to do? Or does it serve a different purpose? The UPDATING note appears rather abstract to me. > + + <edit-label> can be used to add, change, or delete a message's X-Label. > + ! Pattern expressions with ~y support label tab completion. > + + LMDB backend support for the header cache. > + + Kyoto Cabinet backend support for the header cache. The final two seem rather very technically worded and also introduce the new before picking up the reader with what he is likely familiar with already. How about this instead: "The header cache now also supports Kyoto Cabinet and LMDB as backend databases." Thanks for your consideration. Cheers, Matthias
