library-specific customization files?

library-specific customization files?

[Drew Adams]

If this is not the right list for this, please point me to the right one. If
this is the right list, and I've misunderstood or missed something basic,
please correct me - I'm not very used to using customize.

(This is for after the release, BTW.)

1. First, I don't see `custom-file' mentioned in the Emacs (Info) manual,
but perhaps my version of the manual is not up to date.

2. When you save settings made through customize, they are saved in
`custom-file' or `user-init-file' (if `custom-file' is nil). I don't see any
other option for saving customizations. Is this correct?

3. Saving all customizations in the same file can lead to a loss of
structure - a user can end up with a huge, unordered `custom-file' or
`user-init-file'. This is the usual case, I think.

4. It would be good for a user to be able to (optionally) save
customizations to separate files that he can easily associate with their
corresponding standard library files. For instance, ps-print customizations
might be saved to custom-ps-print.el, while dired customizations might be
saved to custom-dired.el. All of these user customizations could be placed
in the same directory. They could all be loaded by default.

5. We might also consider automatically creating a single byte-compiled
version of the collection of custom-*.el files (rather than multiple
compiled files - to save load time).


I think that multiple customization files, each associated with a standard
library file, could make it easier for users to keep track of things, and
easier for them to adapt to new Emacs versions. Making this optional would
be important, because for some users this might be more confusing than
helpful.

Any interest in doing something along these lines (letting users structure
customizations to reflect standard-library structure)? Has this been
discussed before? Other ideas on how to achieve this?

 - Drew

P.S. To be honest, this is essentially what I do now by hand, anyway: I have
a custom file per library file, where I keep my customizations (not
necessarily created by "customize"). I'm a bit loathe to use customize
itself sometimes, because I want to be able to keep on top of what is
modified where. This may not be the best way to go about things -
suggestions welcome.

Re: library-specific customization files?

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

...
: I think that multiple customization files, each associated with a standard
: library file, could make it easier for users to keep track of things, and
: easier for them to adapt to new Emacs versions. Making this optional would
: be important, because for some users this might be more confusing than
: helpful.

I agree, this would be a nice feature. I did not give it a thourogh thought
but would it not be possible to use the :group attribute for this? Maybe the
group names could be tied to file names for saving? It no such association
then the main customization file could maybe be used?

Some people might perhaps be confused by the group "hierarchy" here. Is not
this more a network than a hierarchy? Could the feature suggested above be
kept outside of this?

- Lennart

Re: library-specific customization files?

[Stefan]

> 4. It would be good for a user to be able to (optionally) save
> customizations to separate files that he can easily associate with their
> corresponding standard library files. For instance, ps-print customizations
> might be saved to custom-ps-print.el, while dired customizations might be
> saved to custom-dired.el. All of these user customizations could be placed
> in the same directory. They could all be loaded by default.

Usually the namespace prefix and the sorting end up separating the various
packages in the custom-file already (which is admittedly not the same as
a separation into various files, but already shows some amount of
structure).  I think it would be better to extand the custom-theme support
so the user can use some other grouping than just "one per package".

In any case I strongly suspect that 99% of those people who might care about
the structure of their custom-file can and do write their .emacs by
hand instead.

> 5. We might also consider automatically creating a single byte-compiled
> version of the collection of custom-*.el files (rather than multiple
> compiled files - to save load time).

Compiling config files is at best pointless.


        Stefan

Re: library-specific customization files?

[Luc Teirlinck]

Are the people who are discussing this thread familiar with
initsplit.el by John Wiegley, available from:

http://www.newartisans.com/johnw/emacs.html

It seems to implement a functionality similar to the one being
discussed.  I do not use it and hence have no opinion on it.  But
interested people could try it out.

Sincerely,

Luc.

RE: library-specific customization files?

[Drew Adams]

Thanks. I'll take a look at it.

-----Original Message-----
Are the people who are discussing this thread familiar with initsplit.el by
John Wiegley, available from: http://www.newartisans.com/johnw/emacs.html.
It seems to implement a functionality similar to the one being discussed.

RE: library-specific customization files?

[Drew Adams]

Thanks for this reference. I took a quick look at it.

John's code tries to match against variable names. I think it would be good
to build on what he has done, integrating it within Customize.

Name matching is not 100% failsafe, since not all variable names in all Lisp
packages use prefixes, and some name parts could also, I imagine, result in
false hits to the wrong library.

Instead of relying on name matching, Customize should use positive knowledge
of which variables belong to which Lisp files to create a failsafe mapping.
A library census a la TAGS could be used, if Customize does not already have
an explicit mapping of variables to their libraries.

-----Original Message-----
Are the people who are discussing this thread familiar with initsplit.el by
John Wiegley, available from: http://www.newartisans.com/johnw/emacs.html.
It seems to implement a functionality similar to the one being discussed.

Re: library-specific customization files?

[David Kastrup]

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

> Thanks for this reference. I took a quick look at it.
>
> John's code tries to match against variable names. I think it would be good
> to build on what he has done, integrating it within Customize.
>
> Name matching is not 100% failsafe, since not all variable names in all Lisp
> packages use prefixes, and some name parts could also, I imagine, result in
> false hits to the wrong library.
>
> Instead of relying on name matching, Customize should use positive
> knowledge of which variables belong to which Lisp files to create a
> failsafe mapping.  A library census a la TAGS could be used, if
> Customize does not already have an explicit mapping of variables to
> their libraries.

Customization variables already have groups.  But I don't see how
splitting them makes any sense: the stuff that customize writes is not
supposed to be user-accessible anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: library-specific customization files?

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>

: Customization variables already have groups.  But I don't see how
: splitting them makes any sense: the stuff that customize writes is not
: supposed to be user-accessible anyway.

It could be used for sharing parts of settings for example. Between users
and maybe also different computers.

- Lennart

Re: library-specific customization files?

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> ----- Original Message ----- 
> From: "David Kastrup" <dak@gnu.org>
>
> : Customization variables already have groups.  But I don't see how
> : splitting them makes any sense: the stuff that customize writes is not
> : supposed to be user-accessible anyway.
>
> It could be used for sharing parts of settings for example. Between users
> and maybe also different computers.

In which case it would appear to make more sense to create commands
for exporting grouped settings, rather than for maintaining them in
separated form.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: library-specific customization files?

[Stefan]

> It could be used for sharing parts of settings for example. Between users
> and maybe also different computers.

That's what custom-themes are for.


        Stefan

Re: library-specific customization files?

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>

: > It could be used for sharing parts of settings for example. Between
users
: > and maybe also different computers.
:
: In which case it would appear to make more sense to create commands
: for exporting grouped settings, rather than for maintaining them in
: separated form.

It sounds good to have, but the exporting command could maybe just as well
be the command that splits of a part of the settings.

There are more benefits with split settings. It could maybe makes it more
easy to test different configs for example.

I believe this is a kind of issue that comes up when a graphic user
interface is introduced. It is complicated and I guess that this issue have
to be around for a while to get "ripe".

- Lennart

Re: library-specific customization files?

[Richard Stallman]

    : I think that multiple customization files, each associated with a standard
    : library file, could make it easier for users to keep track of things, and
    : easier for them to adapt to new Emacs versions. Making this optional would
    : be important, because for some users this might be more confusing than
    : helpful.

I don't find this idea appealing.  Moreover, it is distracting
attention from what we really need now, which is to debug the many bug
reports that have recently been reported.

Would people please postpone this discussion until after the next
release, and turn attention to debugging some of these bugs?