Re: Customize Rogue

[Luc Teirlinck]

David Masterson wrote:
   
   As Per points out, there may *NOT* be
   a legitimate need to have customizations outside of Custom's control
   as the customizations are pretty lightweight.

There is no problem if, in the current situation, you are satisfied
with having all your user options customized inside a single
custom-set-variables form and a single custom-set-faces form.  If
custom-setq would be implemented that requirement would be relaxed to
having them all in custom-setq calls in a single custom-file.

   Also, as demonstrated by initsplit, it seems possible to have
   multiple custom-set-variables sections as long as (*I* *think*)
   they don't conflict on variables and, hence, don't need
   custom-setq.  The big problem is that, with multiple sections of
   custom-set-variables or custom-setq that exist in multiple .emacs
   or related files, it would be impossible for Custom to find them
   and update them when the user wishes to do his own customizations.

That is indeed the big problem.  By an option being "under Custom's
control", I mean that changing the saved value of an option using the
Customize interface will work reliably.  This happens if and only if
the conditions mentioned above are satisfied.

   If, though, customizations cannot really be put into any place other
   than custom-file and still be "customizable" by Custom, does it really
   matter if there is a custom-setq function?

If you are willing to put all your customizations in one single file,
custom-setq is the end to your problems.  (Note however that
custom-setq is not implemented at present and requires a rewrite of
custom-save-variables.)  I believe however that the purpose of
initsplit is to put them in different files.  In that case, when
somebody wants to use a customization buffer to change a saved value
and it is not going to work, that person should be alerted to that
fact by having the state line say:

State: this option has been changed outside the customize buffer

instead of:

State:  this option has been set and saved.

which tells you that saving it through the customization buffer is
safe and will work.

custom-setq makes Custom believe that the option is under its control
and act on that belief, for instance by displaying the latter "State: "
line. Using set-activate produces essentially the same effect as
custom-setq (in a slightly more efficient way), keeps it out of
Custom's control and, unlike an incorrectly used custom-setq, does not
trick Custom into believing that the option is in fact under its
control.

That is why you need set-activate (or some alternative to it), even
after custom-setq would be implemented, *if* you are going to keep
customizations in multiple files, especially if are going to use an
automated tool, like initsplit to help you do that.  The intended
custom-setq should not be used outside the custom-file, except by the
user himself, as a deliberate way to fool Custom.  (Which would serve
no objective purpose, but the user is free to do whatever he wants in
his customizations, whether it makes sense or not.)

Sincerely,

Luc.