bug#44597: 26.3; bibtex should allow reverse sorting

["Francesco Potortì" <pot@gnu.org>]

>> 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.
>
>My point is that only rarely users will have "day" fields in their
>database.  Then it can happen easily that multiple entries have the
>same "year" and "month" field, but no other criterion to sort these
>entries.

In my use case, I needed to sort about 100 bibtex entries in reversed
date order, without any more criterion, and I had to resort to an
external tool.  The reason was that i had to participate to a career
selection where people was asked to provide a list of their own papers
listed in reverse chronological order.

I had no need for a secondary sort key, so if I could just do that with
bibtex.el it would have saved my day.

In fact, I had thought about writing a more generic patch, but with
limited time on my hands, I preferred improving the current situation
rather than trying to do the best.

>To resolve this ambiguity, if *I* was using such a scheme, I would
>want to use other fields like "author" or "title".

Certainly a more general scheme which allows arbitrary sort keys would
be best.

>						     That's when
>individual preferences enter the stage.  As we are talking about a
>scheme that (I am pretty confident) will attract only a few users in
>the first place, I believe it is better to let users define their
>own functions for this.

Sure.  But in any case, having a set of predefined sorting methods would
improve a lot over the current situation.  I assume that most users are
not able or willing to write their own function.

>> As far as I can tell, "date" and "day" are sometimes used even if not
>> standard.
>
>The "date" field is used by biblatex, which is a largely
>backward-compatible successor of BibTeX.  Its "date" field is
>supposed to follow iso-8601, and that's also assumed by the code
>example below.  (In BibTeX mode, you can switch from old-fashioned
>BibTeX to biblatex, see `bibtex-dialect'.)

Yes, that's what I have found looking around.  It is supported in my
patch, though I have never used biblatex.  I see now that biblatex has a
successor called biber.  Maybe one day I'll try it.

>I have never seen a "day" field nor any code that supports it
>(nor have I seen iso-8601 "date" fields that actually included a day).
>
>> I personally use "day" to keep track of the dates of congresses
>> (for @inproceedings).
>
>Sure, that makes a date-based sorting more straightforward and
>meaningful.

Again, that depends on the use case.  I am sure my patch can be useful
even without a secondary sorting key and without a day being specified.

>> >How about instead a new customizable sorting scheme, where the
>> >value of bibtex-maintain-sorted-entries is a cons pair
>> >
>> >  (INDEX-FUN . PREDICATE)
>> >
>> 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.
>
>The patch below implements such a scheme (not based on a cons pair
>but a list that may include a third element INIT-FUN).
>
>To test the code, I also hacked a function `my-bibtex-index-date'
>that provides an example for INDEX-FUN, see below.  It may well be
>that it does not exactly match your taste, but it should be
>straightforward to adapt the code.  The PREDICATE is then standard
>`string-lessp' (or `string-greaterp' for reversed sorting).
>
>Can you please test this?  Thanks.

I will, but please be patient.  I do this in my spare time, which is
highly variable.

Thanks, will come back to you as soon as I can