Re: :file keyword for Customize

[David Kastrup]

"Drew Adams" <address@hidden> writes:

> How about adding a :file keyword for `defcustom' and `defface'?
>
> (defcustom foo-bar-flag t
>   "Non-nil means toto."
>   :type 'boolean :group 'foo
>   :file (if (eq system-type 'windows-nt)
>             "C:\\foo-stuff\\foo-cus.el"
>           "/toto/foo-stuff/foo-cus.el"))
>
> Its argument would be evaluated to a file name. That particular `defcustom' or
> `defface' setting would be saved in that file, instead of in `custom-file' or
> `init-file'. A nil or "" value for :file would mean the same thing as the
> absence of a :file keyword: as now, use `custom-file' or, if no `custom-file',
> `init-file'.
>
> 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.

> 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
since you can no longer have one options file per platform.

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

> 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.
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.  We _never_ include a file in bug reports but rather
settings.  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.

> 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,
and one can't really delay loading it, anyway.  So all this buys us is
added complication and longer load times.

Don't fix what is not broken.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum