Subject: bug#44597: 26.3; bibtex should allow reverse sorting

From: Francesco Potortì <[email-masked]>
Date: Sun, 13 Dec 2020 17:57:32 +0100

>I am not sure the proposed patch is the best way to go.  Suppose a
>BibTeX file contains just several dozen entries per year of
>publication.  Then sorting by date becomes meaningful only if the
>date for each entry includes not only year and month, but also the
>day.

The bibtex-get-date function in my patch does not assume that the "day"
field is present.  When it is missing, it uses the first day of the
month, or day 30 if the LATEST argument is t.

By the way, there is an error in my patch: it shuld be "day", not
"days".

>I assume that's why the proposed patch also uses a `day'
>field.  But such a field is not standard for BibTeX entries, and I
>am not aware of any "default" mechanisms to support it.

As far as I can tell, "date" and "day" are sometimes used even if not
standard.  Anyway, if any of "date" or "day" are present, the patch will
use them, else it will use what's available.

I personally use "day" to keep track of the dates of congresses (for
@inproceedings).

>How about instead a new customizable sorting scheme, where the value
>of bibtex-maintain-sorted-entries is a cons pair
>
>  (INDEX-FUN . PREDICATE)
>
>where INDEX-FUN is a user-defined function that replaces
>bibtex-entry-index, and PREDICATE is a user-defined function that
>replaces the default predicate bibtex-lessp.  Then users can define
>custom sorting schemes to their liking, where PREDICATE sorts the
>entries based on the return values of INDEX-FUN.

That would be certainly more flexible.  However I think it is at least
equally important to provide some precooked solutions.  I myself would
have spared some work some months ago if I had the 'reverse and
'reversedate methods available.