Re: :file keyword for Customize

[David Kastrup]

"Drew Adams" <address@hidden> writes:

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

Then let's leave this alone until there is a problem.

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

Yes.  And the whole "Emacs" executable is stored together and loaded
together.  There are even files preloaded into it in order to make it
load faster.  What is bad about that?  Why give the user "choice" about
something which is utterly irrelevant?  So that there are more things
that can go wrong or be misconfigured without any advantage?

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

C-h f defcustom RET

[...]

:set-after VARIABLES
        Specifies that symbol should be set after the list of variables
        VARIABLES when both have been customized.

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

But splitting it causes no different effect whatsoever except making the
whole less transparent.

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

Lisp mostly works with a single obarray.  This makes things more
transparent rather than more opaque.  All one sack.  There is nothing
messy about that.

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

Why?

>> Don't fix what is not broken.
>
> Not every improvement is a bug fix.

Not every complication is an improvement.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum