bug#13207: lisp-mnt.el improvements

[Jonas Bernoulli]

>> 3. lm-header, lm-header-multiline: wrap with save-match-data
>
> This one doesn't sound right.  The callers should be fixed instead.

Okay.  On second though: it wouldn't be very useful to use the match
data set by these functions.  Why not save the match-data here once so
that no caller has to ever worry about it?  Is there a general policy
that this kinda thing shouldn't be done?

>> 4. lm-header-multiline: continuation lines now need to be intended more
>>    than the first line.  E.g:
>>    ;; Keyword: value
>>    ;;  more value
>>    This is necessary because some built-in libraries contain things
>>    like:
>>    ;; Author: Kenichi HANDA <handa@etl.go.jp>
>>    ;; (according to ack.texi)
>>    And some third-party libraries contain things like:
>>    ;; Keywords: key words
>>    ;; This file is not part of Emacs
>>    Among the 3500 packages mirrored on the Emacsmirror there are only
>>    three where this change results in lines intended as continuation
>>    lines not to be recognised anymore.  At the same time this change
>>    fixes ~50 errors.
>
> An important measure is how much breakage/improvement does it introduce
> when applied to files that are expected to do thing right (e.g. files in
> emacs/lisp and in elpa/packages).  I'm OK with making lisp-mnt.el more
> forgiving, but it should not come at the cost of those packages that do
> things right.

The 3500 packages from which I extracted metadata include all built-in
and fsf-elpa packages (though I did not process every library, just the
"main library" of each package).  The three packages affected in a
negative way didn't do things right, and they aren't fsf packages.

This should be possible

  ;; Author: Kenichi HANDA <handa@etl.go.jp>
  ;; (according to ack.texi)

and this can be sacrificed

  ;; Author: Kenichi HANDA <handa@etl.go.jp>
  ;; Jonas Bernoulli <jonas@bernoul.li>

-- Jonas