bug#13583: 24.3.50; Error when activating auto-revert-mode

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

Dani said:

> But for the record: IIUC, I that approach isn't flawless either,
> because doing face customization is pretty hard without the customize
> facility, and using customize will imply:
> 1. Do the customization in a custom buffer.
> 2. Save the customization (for getting the elisp code).
> 3. Look for the appropriate sentence in the generated custom file, and
> move it to my init file.
> 
> That is not very convenient, but fortunately I don't do face
> customization every day.

and

> A workaround is to fool the customize facility by marking the relevant
> customizations as "saved" just after the call to custom-set-variables,
> but that is an ugly hack, IMO.

That workaround is an ugly hack, OK.  But it is no more an ugly hack than the
other workarounds (yes, they are just that) that you all have been discussing,
IMO.

Michael H. is right that (a) the custom* arsenal has the tools one needs but (b)
interactive Customize itself should be expanded to provide general users with
them directly (i.e., no Lisp needed).

I do some of that in my ugly-little-hack library cus-edit+.el [*], but no doubt
someone knowing the custom* code well could do better.  There has been little
interest so far, unfortunately.  One reason is perhaps that the cus* code is
difficult to fathom.

Given the current state of what's available, I still do recommend the ugly
little hack Dani mentioned: telling customize that there has been no change to
the option (i.e., lying).

That's what the custom* code itself does.  That the names of the things involved
make it look like you are claiming that the option has been _saved_, instead of
telling customize to ignore any changes, is only a name problem - for us people.

But yes, there is room for improvement.

[*]
http://www.emacswiki.org/emacs-en/download/cus-edit%2b.el
http://www.emacswiki.org/emacs/CustomizingAndSaving#CustomizePlus