bug#14696: [External] : Re: bug#14696: 24.3.50; order of items in `custom-file' (or init file)

[Drew Adams <drew.adams@oracle.com>]

> > Enhancement request.
> >
> > Currently, options and faces are sorted using `string<' when written to
> > your `custom-file'.  That can make it easy to find something in the
> > file, I suppose, but (a) you can alternatively and easily find an entry
> > using Isearch, and (b) you can always split a list in the file into
> > lines and sort the lines, if you really want to see such a sort order.
> >
> > Is there some other reason to sort entries this way?
> 
> Yes, it makes it easier to keep under version control without conflicts.

Thanks.  That's a reasonable advantage.

I'd propose that users be able to control the order,
with a user option.  The current sort order, which
provides the advantage you cite, could be one of the
predefined option-value choices.  What I suggested
could be another predefined choice.  And providing
a sort function could be another (a catch-all that
let's you sort any way you like).

> > Alternatively, it could be more useful to put new and updated entries at
> > the head of the option and face lists.  That way, the lists would record
> > the update order (at least in some common cases, if not in all cases).
> >
> > And that can help when you want to find something that you changed
> > recently.
> >
> > The enhancement request would be to either:
> >
> > 1. (Preferably) timestamp each update or new entry, e.g., as part of the
> > entry itself or via a separate alist for all entries.
> >
> > 2. If not, do not sort entries using `string<', but just add then at the
> > head of each list (options, faces).
> 
> This would create more conflicts when keeping your configuration under
> version control, so I don't think it's a good idea.

It's a good idea for those who don't put that file
under vc, or those who have an easy way to resolve
such "conflicts".

There can be conflicting "good ideas", depending
on use cases and user preferences.  A user option
to choose among competing "good ideas" is itself
a "good idea".

> > #1 would be more involved, but would be better (precise).  It would help
> > us create a command, for instance, that would let you find changes made
> > during any given time period etc.
> >
> > (In effect, this would be a bit like providing automatic version control
> > for your custom file.)

Indeed.  What of that - no comment?