RE: :file keyword for Customize

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

> > This could provide a little more modularity for packages 
> > (and for any other groupings of options & faces).
> 
> I don't see what scattering the saved options across 
> different files has to do with modularity.

Scattering is not about modularity, but no one suggested scattering. Grouping is
about modularity, and this is about grouping: deciding which options belong
together wrt persistence and loading.

The choice is not a binary one: (1) accept one giant lump or (2) explode and
scatter everything into elementary particles. It's about providing constructs
that let programmers and users decide how to group things for persistence and
loading: which things to save in the same file.

> > It could help deal with things like platform differences (for a
> > package) and initialization order of settings.
> 
> Uh no.  It actually _curbs_ being able to deal with platform 
> differences

How so? 

> since you can no longer have one options file per platform.

Why not? How would that be prevented?

How can adding choices prevent you from doing what you do today?

> > It could allow users a little more flexibility in terms of when some
> > groups of Customize settings are loaded (currently, all Customize
> > settings are loaded at once).
> 
> So what?  What is the problem you are trying to fix here?

I already said that I don't have a particular problem I am trying to fix.

Currently, all user settings are stored persistently in the same sack (modulo
special programming to store data in particular files). That's not very modular,
and it gives both the programmer and the user little choice wrt what is stored
where and when things are loaded - all Customize settings are stored together
and loaded together.

> > It could simplify communication with package authors about bugs
> > (e.g. automatically include the package's Customize 
> > settings in a bug report).
> 
> Nonsense.  report.el already provides a way to report 
> relevant settings.

That report.el exists does not imply that the proposed feature is nonsense. Such
reasoning is, however, nonsense.

> And if you wanted to have a special way to report everything 
> customized for a package, you'd do it by listing the customization
> group rather than some file.

Not necessarily. Customization groups can have many different meanings and
different grouping criteria. Those don't necessarily map directly to appropriate
persistence and loading models.

> We _never_ include a file in bug reports but rather settings.

I'll let you speak for what "we _never_" do, but I, for one, have sometimes been
interested to see what a user's .emacs or `custom-file' looked like in
connection with a bug report. Seeing dynamic settings and seeing persistent
values (and knowing when those are loaded) both can sometimes provide useful
information. They are not exclusive options. You seem to be bent on imposing
non-existent binary choices.

There is, in any case, nothing in what I proposed that requires you ("we") to
use the feature to communicate persistent settings in bug reports.  

> And since people could put their settings anywhere, and since
> variables can be set without customizing them or even 
> overriden, a file would be utterly unreliable, anyway, as a
> source of information.

Again, nothing forces you to "rely" on persistent settings. But there is more
than one request in the help lists to see what might be in a reporting user's
.emacs - sometimes that's useful.

If such information is not useful in some context, or if you think it is
"_never_" interesting to you, then, uh, just don't use it; don't ask for it.

I would like to be able to (be _able_ to, not be forced to) suggest to a user to
load the customizations for package foo after, not before, those for package
bar. That is not possible today, when it comes to Customize settings - they're
simply all lumped together.

> > I don't have a particular use-case in mind; it's just something that
> > occurred to me.  There is nothing special in this, but I think it
> > might help organize things a bit.  A user's `custom-file' or
> > `init-file' can become a monolithic blob, and this could 
> > help cut down on that.
> 
> So what?  It is a "monolithic blob" not intended for human 
> consumption,

It's certainly intended for programmatic use. And ultimately for human use, in
terms of its effects.

Such an argument could be applied to all software engineering (and sometimes
was, about 40 years ago): just throw everything in one sack; it's all internal,
so it doesn't matter how messy it is.

> and one can't really delay loading it, anyway.  So all this buys us is
> added complication and longer load times.

No idea what you mean by that. Users today can decide when to load
`custom-file'. They could do the same with any such files of Customize options,
the same way.

> Don't fix what is not broken.

Not every improvement is a bug fix.