bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Jonas Bernoulli]

It was already possible to specify multiple authors using the "Author"
header, but the same was not possible for maintainers.  Because some
packages have multiple maintainers, which cannot or don't want to be
subsumed under some organisation's name, this adds support for
specifying multiple maintainers as well.

this also adds support for using "Authors" and "Maintainers" as the
names of the header fields instead of just the singular forms.

[These commits were send using git-send-email, so the email subjects
 are also the commit message subjects. I would be happy to apply these
 commits myself once they are approved.]

Jonas Bernoulli (2):
  Support plural forms of Author and Maintainer library headers
  * lisp/emacs-lisp/lisp-mnt.el (lm-crack-address): Right-trim name.

 doc/lispref/tips.texi       | 24 +++++++++++++-----------
 lisp/emacs-lisp/lisp-mnt.el | 32 ++++++++++++++++++++------------
 2 files changed, 33 insertions(+), 23 deletions(-)

-- 
2.30.1

bug#48592: [PATCH 1/2] Support plural forms of Author and Maintainer library headers

[Jonas Bernoulli]

* doc/lispref/tips.texi (Library Headers): Mention that in addition to
the "Author" and "Maintainer" headers, their plural forms are also
supported.
* lisp/emacs-lisp/lisp-mnt.el (lm-authors): Consider "Authors" header
in addition to "Author".
(lm-maintainers): New function.
(lm-maintainer): Make obsolete in favor of lm-maintainer.
(lm-verify): Use lm-maintainers.  Mention plural headers also.
(lm-report-bug): Use lm-maintainers.
---
 doc/lispref/tips.texi       | 24 +++++++++++++-----------
 lisp/emacs-lisp/lisp-mnt.el | 28 ++++++++++++++++++----------
 2 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index 36c68ee5ce..25d43dfcfe 100644
--- a/doc/lispref/tips.texi
+++ b/doc/lispref/tips.texi
@@ -1034,7 +1034,8 @@ Library Headers
 
 @table @samp
 @item Author
-This line states the name and email address of at least the principal
+@itemx Authors
+This header states the name and email address of at least the principal
 author of the library.  If there are multiple authors, list them on
 continuation lines led by @code{;;} and a tab or at least two spaces.
 We recommend including a contact email address, of the form
@@ -1042,22 +1043,23 @@ Library Headers
 
 @smallexample
 @group
-;; Author: Your Name <yourname@@example.com>
+;; Authors: Your Name <yourname@@example.com>
 ;;      Someone Else <someone@@example.com>
 ;;      Another Person <another@@example.com>
 @end group
 @end smallexample
 
 @item Maintainer
-This header has the same format as the Author header.  It lists the
-person(s) who currently maintain(s) the file (respond to bug reports,
-etc.).
-
-If there is no maintainer line, the person(s) in the Author field
-is/are presumed to be the maintainers.  Some files in Emacs use
-@samp{emacs-devel@@gnu.org} for the maintainer, which means the author is
-no longer responsible for the file, and that it is maintained as part
-of Emacs.
+@itemx Maintainers
+This header has the same format as the Author(s) header.  It lists the
+person(s) who currently maintain(s) the file (respond(s) to bug
+reports, etc.).
+
+If there is no Maintainer(s) header, the person(s) in the Author(s)
+header is/are presumed to be the maintainer(s).  Some files in Emacs
+use @samp{emacs-devel@@gnu.org} for the maintainer, which means the
+author is no longer responsible for the file, and that it is
+maintained as part of Emacs.
 
 @item Created
 This optional line gives the original creation date of the file, and
diff --git a/lisp/emacs-lisp/lisp-mnt.el b/lisp/emacs-lisp/lisp-mnt.el
index 73a33a553f..25b5e8c5bd 100644
--- a/lisp/emacs-lisp/lisp-mnt.el
+++ b/lisp/emacs-lisp/lisp-mnt.el
@@ -375,17 +375,25 @@ lm-authors
 Each element of the list is a cons; the car is the full name,
 the cdr is an email address."
   (lm-with-file file
-    (let ((authorlist (lm-header-multiline "author")))
+    (let ((authorlist (lm-header-multiline "authors?")))
       (mapcar #'lm-crack-address authorlist))))
 
+(defun lm-maintainers (&optional file)
+  "Return the maintainer list of file FILE, or current buffer if FILE is nil.
+If the maintainers are unspecified, then return the authors.
+Each element of the list is a cons; the car is the full name,
+the cdr is an email address."
+  (lm-with-file file
+    (mapcar #'lm-crack-address
+            (or (lm-header-multiline "maintainers?")
+                (lm-header-multiline "authors?")))))
+
 (defun lm-maintainer (&optional file)
   "Return the maintainer of file FILE, or current buffer if FILE is nil.
+If the maintainer is unspecified, then return the author.
 The return value has the form (NAME . ADDRESS)."
-  (lm-with-file file
-    (let ((maint (lm-header "maintainer")))
-      (if maint
-	  (lm-crack-address maint)
-	(car (lm-authors))))))
+  (declare (obsolete lm-maintainers "28.1"))
+  (car (lm-maintainers file)))
 
 (defun lm-creation-date (&optional file)
   "Return the created date given in file FILE, or current buffer if FILE is nil."
@@ -544,9 +552,9 @@ lm-verify
 	       ((null name)
 		"Can't find package name")
 	       ((not (lm-authors))
-		"`Author:' tag missing")
-	       ((not (lm-maintainer))
-		"`Maintainer:' tag missing")
+		"`Author:' or `Authors:' tag missing")
+	       ((not (lm-maintainers))
+		"`Maintainer:' or `Maintainers:' tag missing")
 	       ((not (lm-summary))
 		"Can't find the one-line summary description")
 	       ((not (lm-keywords))
@@ -613,7 +621,7 @@ lm-report-bug
   (interactive "sBug Subject: ")
   (require 'emacsbug)
   (let ((package (lm-get-package-name))
-	(addr (lm-maintainer))
+	(addr (car (lm-maintainers)))
 	(version (lm-version)))
     (compose-mail (if addr
 		      (concat (car addr) " <" (cdr addr) ">")
-- 
2.30.1

bug#48592: [PATCH 2/2] * lisp/emacs-lisp/lisp-mnt.el (lm-crack-address): Right-trim name.

[Jonas Bernoulli]

The addresses might be aligned in which case we have to trim the
extra whitespace at the end of the names.
---
 lisp/emacs-lisp/lisp-mnt.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/emacs-lisp/lisp-mnt.el b/lisp/emacs-lisp/lisp-mnt.el
index 25b5e8c5bd..a73c53def4 100644
--- a/lisp/emacs-lisp/lisp-mnt.el
+++ b/lisp/emacs-lisp/lisp-mnt.el
@@ -360,10 +360,10 @@ lm-crack-address
   "Split up an email address X into full name and real email address.
 The value is a cons of the form (FULLNAME . ADDRESS)."
   (cond ((string-match "\\(.+\\) [(<]\\(\\S-+@\\S-+\\)[>)]" x)
-	 (cons (match-string 1 x)
+	 (cons (string-trim-right (match-string 1 x))
 	       (match-string 2 x)))
 	((string-match "\\(\\S-+@\\S-+\\) [(<]\\(.*\\)[>)]" x)
-	 (cons (match-string 2 x)
+	 (cons (string-trim-right (match-string 2 x))
 	       (match-string 1 x)))
 	((string-match "\\S-+@\\S-+" x)
 	 (cons nil x))
-- 
2.30.1

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Date: Sat, 22 May 2021 22:25:19 +0200
> 
> It was already possible to specify multiple authors using the "Author"
> header, but the same was not possible for maintainers.  Because some
> packages have multiple maintainers, which cannot or don't want to be
> subsumed under some organisation's name, this adds support for
> specifying multiple maintainers as well.
> 
> this also adds support for using "Authors" and "Maintainers" as the
> names of the header fields instead of just the singular forms.

Why do we need these additions?  Couldn't we keep using Author and
Maintainer?  Having both variants immediately begs the question which
is preferable and why, arguments about style, and other bikeshedding.
Unless there's a good reason for adding new headings, I'd prefer to
make do with what we already have.

Thanks.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jonas Bernoulli <jonas@bernoul.li>
>> Date: Sat, 22 May 2021 22:25:19 +0200
>> 
>> It was already possible to specify multiple authors using the "Author"
>> header, but the same was not possible for maintainers.  Because some
>> packages have multiple maintainers, which cannot or don't want to be
>> subsumed under some organisation's name, this adds support for
>> specifying multiple maintainers as well.
>> 
>> this also adds support for using "Authors" and "Maintainers" as the
>> names of the header fields instead of just the singular forms.
>
> Why do we need these additions?

OCD and grammar.

> Couldn't we keep using Author and Maintainer?

Of course. But why?

> Having both variants immediately begs the question which is preferable
> and why, arguments about style, and other bikeshedding.

The answer seems obvious to me.  Do it like (nearly?) all natural
languages do it: If n=1 then singular, else (n>1) plural.

> Unless there's a good reason for adding new headings, I'd prefer to
> make do with what we already have.

Grammatical mistakes tend to be distracting, especially if you see the
same one over and over again, year after year.

I was expecting this to be noncontroversial.  ;)

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: 48592@debbugs.gnu.org
> Date: Sun, 23 May 2021 10:43:40 +0200
> 
> >> this also adds support for using "Authors" and "Maintainers" as the
> >> names of the header fields instead of just the singular forms.
> >
> > Why do we need these additions?
> 
> OCD and grammar.
> 
> > Couldn't we keep using Author and Maintainer?
> 
> Of course. But why?

To keep Emacs smaller and less complex.

> > Having both variants immediately begs the question which is preferable
> > and why, arguments about style, and other bikeshedding.
> 
> The answer seems obvious to me.  Do it like (nearly?) all natural
> languages do it: If n=1 then singular, else (n>1) plural.
> 
> > Unless there's a good reason for adding new headings, I'd prefer to
> > make do with what we already have.
> 
> Grammatical mistakes tend to be distracting, especially if you see the
> same one over and over again, year after year.
> 
> I was expecting this to be noncontroversial.  ;)

See above.

But maybe I'm the odd one out here.  Does anyone else have an opinion
on adding these headers?

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Colin Baxter]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

    >> From: Jonas Bernoulli <jonas@bernoul.li> Cc:
    >> 48592@debbugs.gnu.org Date: Sun, 23 May 2021 10:43:40 +0200
    >> 
    >> >> this also adds support for using "Authors" and "Maintainers"
    >> as the >> names of the header fields instead of just the singular
    >> forms.
    >> >
    >> > Why do we need these additions?
    >> 
    >> OCD and grammar.
    >> 
    >> > Couldn't we keep using Author and Maintainer?
    >> 
    >> Of course. But why?

    > To keep Emacs smaller and less complex.

    >> > Having both variants immediately begs the question which is
    >> preferable > and why, arguments about style, and other
    >> bikeshedding.
    >> 
    >> The answer seems obvious to me.  Do it like (nearly?) all natural
    >> languages do it: If n=1 then singular, else (n>1) plural.
    >> 
    >> > Unless there's a good reason for adding new headings, I'd
    >> prefer to > make do with what we already have.
    >> 
    >> Grammatical mistakes tend to be distracting, especially if you
    >> see the same one over and over again, year after year.
    >> 
    >> I was expecting this to be noncontroversial.  ;)

    > See above.

    > But maybe I'm the odd one out here.  Does anyone else have an
    > opinion on adding these headers?

I would argue that in this case, the terms Author, Maintainer includes
the plurals since they name the sets whose elements are various authors,
maintainers. An example would be BibTeX, whose field AUTHOR and include
multiple names separated by the conjunction 'and'.

Best wishes,

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But maybe I'm the odd one out here.  Does anyone else have an opinion
> on adding these headers?

These are "protocol"-ish headers (i.e., for machines to parse), and
should not be changed or extended.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> But maybe I'm the odd one out here.  Does anyone else have an opinion
>> on adding these headers?
>
> These are "protocol"-ish headers (i.e., for machines to parse), and
> should not be changed or extended.

Indeed. Something like (lm-header "Author") wouldn't work for the
keyword "Authors".

Best regards, Michael.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Jonas Bernoulli]

:(

Okay.  This is not the hill I want to die on.

Are you okay with replacing lm-maintainer with lm-maintainers?

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Michael Albinus]

Jonas Bernoulli <jonas@bernoul.li> writes:

Hi Jonas,

> Are you okay with replacing lm-maintainer with lm-maintainers?

Same argument, again. I have no idea, whether there is some code in the
wild which uses (lm-header "Maintainer"). package.el does, implicitly.

It would fail, if new packages arrive with the "Maintainers" keyword,
accessed from an older Emacs.

Best regards, Michael.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Jonas Bernoulli]

Michael Albinus <michael.albinus@gmx.de> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
> Hi Jonas,
>
>> Are you okay with replacing lm-maintainer with lm-maintainers?
>
> Same argument, again. I have no idea, whether there is some code in the
> wild which uses (lm-header "Maintainer"). package.el does, implicitly.
>
> It would fail, if new packages arrive with the "Maintainers" keyword,
> accessed from an older Emacs.
>
> Best regards, Michael.

I see I need to be more verbose.

I made two proposals:

1) Allow writing "Authors" instead of "Author" and "Maintainers" instead
   of "Maintainer".  Everyone else in this thread thinks we shouldn't do
   that and I don't care enough to argue about it.

2) Some packages are being maintained by multiple people and those
   people are not members of some group or organization that could be
   used as a short-hand.  All of those people should be listed because
   they all do important work.  Emacs has a function whose purpose is to
   return the maintainer.  It is called lm-maintainer.  It returns just
   one maintainer, "the" maintainer.  Even if the package has multiple
   maintainers and they are all listed.  I propose that we accept the
   fact that some packages have multiple maintainers, and that we do
   that by adding a new function named lm-maintainers, which returns a
   list of maintainers.  If there is only one maintainer, it returns a
   list of length one.  There is already a function called lm-authors.
   Lets do the same for maintainers.

I have given up on (1) and would still like to do (2).

     Jonas

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Michael Albinus]

Jonas Bernoulli <jonas@bernoul.li> writes:

Hi Jonas,

> 2) Some packages are being maintained by multiple people and those
>    people are not members of some group or organization that could be
>    used as a short-hand.  All of those people should be listed because
>    they all do important work.  Emacs has a function whose purpose is to
>    return the maintainer.  It is called lm-maintainer.  It returns just
>    one maintainer, "the" maintainer.  Even if the package has multiple
>    maintainers and they are all listed.  I propose that we accept the
>    fact that some packages have multiple maintainers, and that we do
>    that by adding a new function named lm-maintainers, which returns a
>    list of maintainers.  If there is only one maintainer, it returns a
>    list of length one.  There is already a function called lm-authors.
>    Lets do the same for maintainers.
>
> I have given up on (1) and would still like to do (2).

Fine by me.

>      Jonas

Best regards, Michael.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Eli Zaretskii]

On May 24, 2021 10:04:37 AM GMT+03:00, Michael Albinus <michael.albinus@gmx.de> wrote:
> Jonas Bernoulli <jonas@bernoul.li> writes:
> 
> Hi Jonas,
> 
> > 2) Some packages are being maintained by multiple people and those
> >    people are not members of some group or organization that could
> be
> >    used as a short-hand.  All of those people should be listed
> because
> >    they all do important work.  Emacs has a function whose purpose
> is to
> >    return the maintainer.  It is called lm-maintainer.  It returns
> just
> >    one maintainer, "the" maintainer.  Even if the package has
> multiple
> >    maintainers and they are all listed.  I propose that we accept
> the
> >    fact that some packages have multiple maintainers, and that we do
> >    that by adding a new function named lm-maintainers, which returns
> a
> >    list of maintainers.  If there is only one maintainer, it returns
> a
> >    list of length one.  There is already a function called
> lm-authors.
> >    Lets do the same for maintainers.
> >
> > I have given up on (1) and would still like to do (2).
> 
> Fine by me.
> 
> >      Jonas
> 
> Best regards, Michael.

Fine by me as well, but:
. I see no reason to deprecate lm-maintainer: there's nothing wrong with wanting to obtain the first name in the list;

 . Please describe in the doc string of lm-maintainer what it does when there's more than one.

Thanks.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

>> [Add lm-maintainers and make lm-maintainer obsolete.]

> Fine by me as well, but:

> . I see no reason to deprecate lm-maintainer: there's nothing wrong
>   with wanting to obtain the first name in the list;
>
> . Please describe in the doc string of lm-maintainer what it does when
>   there's more than one.

The reason why I want to deprecate lm-maintainer is that this informs
users of that function that some packages may have more than one
maintainer and that it is now possible and (I dare say) encouraged to
acknowledge them all.

Sure adding a note to lm-maintainer technically accomplishes the same,
but once one has started using lm-maintainer, then one doesn't
periodically go back to see whether a new notes have been added to its
doc-string.  But something like this would do the trick of guiding the
attention towards the extended functionality and its updated
documentation:

  In package-build--desc-from-library:
  lib/package-build/package-build.el:516:26: Warning: ‘lm-maintainer’ is an
      obsolete function (as of 28.1); use ‘lm-maintainers’ instead.

Yes, there is nothing wrong with ignoring all but the first maintainer
(except of course, not properly attributing the contributions of the
others as they choose to present it), but it seems to me that having to:

  - (lm-maintainer)
  + (car (lm-maintainers))

is perfectly acceptable in cases where only "the" maintainer can be
mentioned because there is not enough room to display the names of all
maintainers.  (So it is still a good idea to list the primus inter pares
maintainer first.)

     Cheers,
     Jonas

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Christopher Dimech]

> Sent: Monday, May 24, 2021 at 8:58 PM
> From: "Jonas Bernoulli" <jonas@bernoul.li>
> To: "Eli Zaretskii" <eliz@gnu.org>, "Michael Albinus" <michael.albinus@gmx.de>
> Cc: "Lars Ingebrigtsen" <larsi@gnus.org>, 48592@debbugs.gnu.org
> Subject: bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers
>
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> [Add lm-maintainers and make lm-maintainer obsolete.]
> 
> > Fine by me as well, but:
> 
> > . I see no reason to deprecate lm-maintainer: there's nothing wrong
> >   with wanting to obtain the first name in the list;
> >
> > . Please describe in the doc string of lm-maintainer what it does when
> >   there's more than one.
> 
> The reason why I want to deprecate lm-maintainer is that this informs
> users of that function that some packages may have more than one
> maintainer and that it is now possible and (I dare say) encouraged to
> acknowledge them all.

One can extract that information from the code if history files are maintained.
In addition, you will find instances where contributors are unknown or their
contribution cannot be verified.  If it is about two or three names, it is not
much of a problem.  One can safely assume that lm-maintainer is one or more.
 
> Sure adding a note to lm-maintainer technically accomplishes the same,
> but once one has started using lm-maintainer, then one doesn't
> periodically go back to see whether a new notes have been added to its
> doc-string.  But something like this would do the trick of guiding the
> attention towards the extended functionality and its updated
> documentation:
> 
>   In package-build--desc-from-library:
>   lib/package-build/package-build.el:516:26: Warning: ‘lm-maintainer’ is an
>       obsolete function (as of 28.1); use ‘lm-maintainers’ instead.
> 
> Yes, there is nothing wrong with ignoring all but the first maintainer
> (except of course, not properly attributing the contributions of the
> others as they choose to present it), but it seems to me that having to:
> 
>   - (lm-maintainer)
>   + (car (lm-maintainers))
> 
> is perfectly acceptable in cases where only "the" maintainer can be
> mentioned because there is not enough room to display the names of all
> maintainers.  (So it is still a good idea to list the primus inter pares
> maintainer first.)

It is not beneficial to have long lists of contributor names in code.  Historical
details should be included in other files intended for that purpose.
 
>      Cheers,
>      Jonas
> 
> 
> 
>

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Eli Zaretskii]

On May 24, 2021 11:58:54 AM GMT+03:00, Jonas Bernoulli <jonas@bernoul.li> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> [Add lm-maintainers and make lm-maintainer obsolete.]
> 
> The reason why I want to deprecate lm-maintainer is that this informs
> users of that function that some packages may have more than one
> maintainer and that it is now possible and (I dare say) encouraged to
> acknowledge them all.

A NEWS entry will do this job nicely, IMO.

> Sure adding a note to lm-maintainer technically accomplishes the same,
> but once one has started using lm-maintainer, then one doesn't
> periodically go back to see whether a new notes have been added to its
> doc-string.  But something like this would do the trick of guiding the
> attention towards the extended functionality and its updated
> documentation:
> 
>   In package-build--desc-from-library:
> lib/package-build/package-build.el:516:26: Warning: ‘lm-maintainer’ is
> an
>       obsolete function (as of 28.1); use ‘lm-maintainers’ instead.
> 
> Yes, there is nothing wrong with ignoring all but the first maintainer
> (except of course, not properly attributing the contributions of the
> others as they choose to present it), but it seems to me that having
> to:
> 
>   - (lm-maintainer)
>   + (car (lm-maintainers))
> 
> is perfectly acceptable in cases where only "the" maintainer can be
> mentioned because there is not enough room to display the names of all
> maintainers.  (So it is still a good idea to list the primus inter
> pares
> maintainer first.)


I think this warning will be a gratuitous annoyance in enough legitimate use cases to make the complaints serious.  If it's okay to take the 'car' of a list, then it should also be okay to call a function which does just that.  It's not like lm-maintainers returns an opaque object.

Again, if the others are fine with the deprecation, I will yield.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Sure adding a note to lm-maintainer technically accomplishes the same,
>> but once one has started using lm-maintainer, then one doesn't
>> periodically go back to see whether a new notes have been added to its
>> doc-string.  But something like this would do the trick of guiding the
>> attention towards the extended functionality and its updated
>> documentation:
>> 
>>   In package-build--desc-from-library:
>> lib/package-build/package-build.el:516:26: Warning: ‘lm-maintainer’ is
>> an
>>       obsolete function (as of 28.1); use ‘lm-maintainers’ instead.
>> 
>> Yes, there is nothing wrong with ignoring all but the first maintainer
>> (except of course, not properly attributing the contributions of the
>> others as they choose to present it), but it seems to me that having
>> to:
>> 
>>   - (lm-maintainer)
>>   + (car (lm-maintainers))
>> 
>> is perfectly acceptable in cases where only "the" maintainer can be
>> mentioned because there is not enough room to display the names of all
>> maintainers.  (So it is still a good idea to list the primus inter
>> pares
>> maintainer first.)
>
>
> I think this warning will be a gratuitous annoyance in enough
> legitimate use cases to make the complaints serious.  If it's okay to
> take the 'car' of a list, then it should also be okay to call a
> function which does just that.  It's not like lm-maintainers returns
> an opaque object.
>
> Again, if the others are fine with the deprecation, I will yield.

Still fine by me, with this obsoletion warning. FWIW.

Best regards, Michael.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Michael Albinus]

Christopher Dimech <dimech@gmx.com> writes:

Hi Christopher,

>> The reason why I want to deprecate lm-maintainer is that this informs
>> users of that function that some packages may have more than one
>> maintainer and that it is now possible and (I dare say) encouraged to
>> acknowledge them all.
>
> One can extract that information from the code if history files are maintained.

We must not confound maintainers and contributors. While it's possible
to find the contributors of a package from (vc) history, I don't see how
to determine the maintainers this way.

Best regards, Michael.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think this warning will be a gratuitous annoyance in enough
> legitimate use cases to make the complaints serious.  If it's okay to
> take the 'car' of a list, then it should also be okay to call a
> function which does just that.  It's not like lm-maintainers returns
> an opaque object.
>
> Again, if the others are fine with the deprecation, I will yield.

I don't see any extremely compelling reason to deprecate it, either, but
`lm-maintainers' (paired with `lm-authors') makes sense, so perhaps it's
a better long-term solution to deprecate `lm-maintainer' (to emphasise
that both of these headers can contain lists of people).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Jonas Bernoulli]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I think this warning will be a gratuitous annoyance in enough
>> legitimate use cases to make the complaints serious.  If it's okay to
>> take the 'car' of a list, then it should also be okay to call a
>> function which does just that.  It's not like lm-maintainers returns
>> an opaque object.
>>
>> Again, if the others are fine with the deprecation, I will yield.
>
> I don't see any extremely compelling reason to deprecate it, either, but
> `lm-maintainers' (paired with `lm-authors') makes sense, so perhaps it's
> a better long-term solution to deprecate `lm-maintainer' (to emphasise
> that both of these headers can contain lists of people).

I've just pushed this.  (New function, deprecate old function, do NOT
support use of plurals as header names.)

This can be closed now.

    Cheers,
    Jonas

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Michael Albinus]

Jonas Bernoulli <jonas@bernoul.li> writes:

Hi Jonas,

>> I don't see any extremely compelling reason to deprecate it, either, but
>> `lm-maintainers' (paired with `lm-authors') makes sense, so perhaps it's
>> a better long-term solution to deprecate `lm-maintainer' (to emphasise
>> that both of these headers can contain lists of people).
>
> I've just pushed this.  (New function, deprecate old function, do NOT
> support use of plurals as header names.)

Perhaps it's worth to be mentioned in etc/NEWS?

>     Cheers,
>     Jonas

Best regards, Michael.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Jonas Bernoulli]

Michael Albinus <michael.albinus@gmx.de> writes:
> Perhaps it's worth to be mentioned in etc/NEWS?

I've just done that.

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[Lars Ingebrigtsen]

Jonas Bernoulli <jonas@bernoul.li> writes:

> I've just pushed this.  (New function, deprecate old function, do NOT
> support use of plurals as header names.)
>
> This can be closed now.

Thanks; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48592: [PATCH 0/2] Support plural forms of Author and Maintainer library headers

[J.P.]

Adding a cross-reference to a related bug for posterity:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68660