RE: :file keyword for Customize

[Drew Adams]

> >> FWIW, I would make custom-file accept an alist of 
> >> defgroup/defcustom symbol name regex, associated with
> >> a file name or a function. 
> 
> DA> I don't think that's the place to specify such organization, 
> 
> We disagree then.

Nothing wrong with that. ;-)

> DA> and I don't think a regexp offers the right kind of flexibility.
> 
> That may be, the selection mechanism is not important.  It 
> can be a cond form.  The point is to put the choice in the user's hands.

The ultimate choice must be the user's. But the programmer can write code that
decides _how_ users make the choices and _which_ choices they can make. The
programmer knows about code dependencies and other internal needs, and can DTRT
wrt both the code and the user (UI design) - giving the user the choices s?he
needs but guiding how those choices are made.

> >> That puts the power in the user's hands, yet allows package authors
> >> to add to the alist.  The big win is that no special :file 
> >> keyword is needed, and all existing packages will work with or
> >> without this special settings.
> 
> DA> I don't see any such big win. It's no big deal to add a :file
> DA> keyword. And all existing packages would continue to work with no
> DA> changes - :file would be optional, of course.
> 
> All existing packages can work with the new mechanism I 
> proposed without modifications, whereas your proposal requires
> special *new* code everywhere a different custom file is desired,
> and leaves the choice up to whoever writes the source code.
> Thus the win is that less code is written all around, users have
> more choice, and everything works as it did before.
> 
> DA> This is about letting an individual option or face (or perhaps
> DA> group) decide where it is stored (and consequently let 
> DA> users decide when it is loaded). The place to do that is in
> DA> `defcustom' and `defface' (and perhaps `defgroup').
> 
> I think I understand your proposal, and I think it puts the option in
> the place where it's hardest to change it if the package author or the
> user should need to do it.  It also makes it hard to organize
> configurations in a way that the *user* likes.  Perhaps I 
> misunderstand your proposal.  Will the user be able to change the
> :file parameter on their own without modifying code, for example?

What I was thinking was that library writers would typically provide one or more
user options or functions as the :file sexps - it is those sexps that would then
let users, in effect, determine the :file values used. IOW, end users would not
directly determine the sexps used for :file, but they would ultimately determine
the values of those sexps in some way (defined by the programmer). 

There would be nothing in the nature of :file itself that would force
programmers to do that, but they would do it naturally - it would make no sense,
for instance, for a programmer to hard-code an absolute file name as a :file
sexp or it's value. (In that, the example I gave was misleading, but I wanted to
get the general idea across, showing that arbitrary code could be used for
:file.)

The idea would be to let programmers define the choices that an end user has,
just as they do with `defcustom' in general (not every variable is a user
option). For instance, the code used for several :file args could be made to
return the same value in some context if that is appropriate, effectively
ensuring that those options would all be stored in the same file. That's
different from letting users specify the files to use for individual options
arbitrarily.

(Of course, any user can always resort to changing the code, as well, but that's
not your point nor mine.)

> What happens if the file name changes with a new package?  Do you add
> extra code to handle the possible values of :file?

Again, :file would not have a literal absolute file name as argument - no one
would code that way. 

> What if the user wants to save the configuration for two 
> packages in one custom file, but all other packages in the
> default place?

That would certainly be possible if each package provided the user a choice wrt
the location, as I imagine. The question is how to provide the user with such
choices - where to do that. 

In what I imagine, programmers can do that as they like, using whatever code
they think is appropriate as the various :file sexps. They can choose to make
these 4 options use the same sexp and those 3 options use a different sexp
(regardless of the whether the sexp values differ). They can choose to specify
:file at the `defgroup' level and define :group's that fit the persistencs and
loading needs. They can do just about anything they think is appropriate for
their users.

In designing this, the choice is not programmer vs user. The idea is to come up
with something for programmers that helps them help their users. Each has some
say in defining the persistence and load behavior. It's `and', not
`either...or'.

> This really is not an unusual need.  I like to keep my Gnus and BBDB
> variables separate from the rest of Emacs but in one file, for example.
> 
> The default path the package author picks may not be appropriate.
> For example, in Gnus a lot of work had to be done to remove 
> dependencies on ~/News and ~/Mail that were put in place over time.
> Many users needed those paths relocated to somewhere that made sense
> to them.

I don't disagree at all about any of that. The question is which tools to
provide programmers so they can meet user needs flexibly.