bug#6935: 24.0.50; doc for `font-lock-maximum-decoration'

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

> > the Emacs manual deals with it only using a `setq' example:
> >   (setq font-lock-maximum-decoration
> >         '((c-mode . 1) (c++-mode . 1)))
> >
> > We should tell users how they can use Customize for customizing it.
> > (No, it is not obvious how to do that.)  We should not be 
> > privileging Lisp code in .emacs this way - especially fairly
> > complex Lisp code.
> 
> For examples of complex variables like this, I find Lisp code a lot
> clearer than convoluted Customize settings.  So this is not a 
> bug, in my opinion.

It's not about your personal opinion of Customize.  It's about Emacs's policy of
privileging Customize in user doc.

AFAIK, Emacs Dev _wants_ users to go first to Customize, in general - especially
new users.  Among other things, Customize provides various safety and sanity
checks.

If you have specific improvements in mind for Customize, feel free to submit
them as enhancement requests.  That's unrelated to this bug report.

But the policy has been, in general, to move old suggestions about using `setq'
etc. in .emacs to suggestions about using Customize.

--

FWIW, I too used to resist Customize and do everything using hand-written Lisp
in .emacs.  And I too still think the Customize UI could use a lot of
improvement (to put it politely).

But I finally switched a few years back to using Customize and a separate
`custom-file' for most, and especially for run-of-the-mill, customizations.  I
use Lisp code for things that Customize cannot do, not just to set an option's
value.