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

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sun, 23 Jun 2013 16:39:02 UTC

Severity: wishlist

Tags: wontfix

Found in version 24.3.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14696 in the body.
You can then email your comments to 14696 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#14696; Package emacs. (Sun, 23 Jun 2013 16:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 23 Jun 2013 16:39:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; order of items in `custom-file' (or init file)
Date: Sun, 23 Jun 2013 09:38:09 -0700 (PDT)
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 <at> 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'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14696; Package emacs. (Sat, 25 Dec 2021 06:28:02 GMT) Full text and rfc822 format available.

Message #8 received at 14696 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14696 <at> debbugs.gnu.org
Subject: Re: bug#14696: 24.3.50; order of items in `custom-file' (or init file)
Date: Fri, 24 Dec 2021 22:27:38 -0800
Drew Adams <drew.adams <at> 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.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14696; Package emacs. (Sat, 25 Dec 2021 21:14:01 GMT) Full text and rfc822 format available.

Message #11 received at 14696 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: "14696 <at> debbugs.gnu.org" <14696 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#14696: 24.3.50; order of items in
 `custom-file' (or init file)
Date: Sat, 25 Dec 2021 21:13:42 +0000
> > 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?

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14696; Package emacs. (Sat, 25 Dec 2021 21:54:02 GMT) Full text and rfc822 format available.

Message #14 received at 14696 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "14696 <at> debbugs.gnu.org" <14696 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#14696: 24.3.50; order of items in
 `custom-file' (or init file)
Date: Sat, 25 Dec 2021 13:53:19 -0800
Drew Adams <drew.adams <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14696; Package emacs. (Tue, 10 May 2022 13:41:01 GMT) Full text and rfc822 format available.

Message #17 received at 14696 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 14696 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#14696: 24.3.50; order of items in `custom-file' (or init file)
Date: Tue, 10 May 2022 15:40:43 +0200
Stefan Kangas <stefan <at> 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




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 10 May 2022 13:41:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 14696 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 10 May 2022 13:41:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 08 Jun 2022 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 294 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.