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

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

[Drew Adams]

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?

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).

#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.)



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-06-20 on ODIEONE
Bzr revision: 113100 eliz@gnu.org-20130620173624-w9v620tog4yacftk
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

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

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> 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.

> 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.

> #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.)

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

[Drew Adams]

> > 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?

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

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> 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).
[snip]
> 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".

Sure, I have no objection to adding such behavior optionally.  If it
wasn't for the limitations of git, I might prefer something like that
myself.

> Indeed.  What of that - no comment?

I only included it for context in this (very old) bug report, so that
subscribers to bug list could easily see the full text.

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Yes, it makes it easier to keep under version control without conflicts.

I don't see a compelling case to make this customiseable -- in my
opinion, very few people would use this.  (The very few who'd like this
can add advice to the relevant functions to do this.)  So I'm closing
this bug report.

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