If I want to set a custom variable, I can do
--8<---------------cut here---------------start------------->8---
(custom-set-variables
 '(foo 42))
--8<---------------cut here---------------end--------------->8---
in my .emacs.
However, if I want to modify the custom variable, I have to resort to
something like
--8<---------------cut here---------------start------------->8---
(add-hook 'message-load-hook
  (lambda ()
    (add-to-list 'message-syntax-checks
                 '(long-lines . disabled))))
--8<---------------cut here---------------end--------------->8---
because
--8<---------------cut here---------------start------------->8---
(custom-set-variables
 '(message-syntax-checks (adjoin '(long-lines . disabled)
                                 message-syntax-checks
                                 :key 'equal)))
--8<---------------cut here---------------end--------------->8---
will evaluate `message-syntax-checks' too early:
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (void-variable message-syntax-checks)
  (adjoin (quote (long-lines . disabled)) message-syntax-checks :key (quote equal))
  eval((adjoin (quote (long-lines . disabled)) message-syntax-checks :key (quote equal)))
  custom-initialize-reset(message-syntax-checks (if message-insert-canlock (quote ((sender . disabled))) nil))
  custom-declare-variable(message-syntax-checks...
  byte-code...
  require(message)
  byte-code...
  gnus-msg-mail(nil nil nil nil nil nil nil nil)
  compose-mail(nil nil nil nil)
  call-interactively(compose-mail nil nil)
--8<---------------cut here---------------end--------------->8---
(it also uses a CL function which emacs purists frown upon).

So, how do I use the custom facility to add something to a custom variable?
Thanks!

--
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://americancensorship.org http://jihadwatch.org
http://iris.org.il http://think-israel.org http://ffii.org
Don't use force -- get a bigger hammer.

I think the solution will involve using

    (get 'message-syntax-checks 'saved-value)

See (info "(elisp) Applying Customizations").
--

The "solution" is
--8<---------------cut here---------------start------------->8---
(custom-set-variables
 '(message-syntax-checks
   (adjoin '(long-lines . disabled)
    (eval (car (get 'message-syntax-checks 'standard-value)))
    :test 'equal)))
--8<---------------cut here---------------end--------------->8---
which uses `eval' on top of `adjoin'.

So, what is the official method?

--
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://dhimmi.com http://jihadwatch.org
http://honestreporting.com http://iris.org.il http://thereligionofpeace.com
Save your burned out bulbs for me, I'm building my own dark room.

No, you do not have to resort to doing that.

Sorry, but I don't see what the problem is.  Why not just use Customize?

At the very least you could use Customize to see what it writes out.  If you
start with Emacs -Q and add (long-lines . disabled) to the default value then it
writes this:

'(message-syntax-checks
   (quote ((sender . disabled) (long-lines . disabled))))

`M-x customize-option' lets you not worry about the Lisp form to use.

But if for some reason you prefer to worry about it, the "solution" is to ask
Emacs what Lisp code it uses, i.e., use Customize to see what it does.

I don't like the gui; also see below (sneak preview: customize is broken :-).

Hah, but this is wrong!
The correct value of message-syntax-checks depends on message-insert-canlock:

(get 'message-syntax-checks 'standard-value)
==> ((if message-insert-canlock (quote ((sender . disabled))) nil))

While if I go your way, then message-syntax-checks will not depend on
message-insert-canlock!

--
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://openvotingconsortium.org
http://ffii.org http://thereligionofpeace.com http://honestreporting.com
Beliefs divide, doubts unite.

I don't like the GUI either.  Which is why I've made improvement suggestions,
filed bug reports, and come up some extensions of my own.

But I recognize that the GUI at least _works_, and it can often give you answers
to questions like the one you raised.

And I've seen a fair amount of hand-coded customize-workaround stuff in .emacs
files that does _not_ work or does not provide the type-checking and proper
initialization/setting code that Customize provides.

It is not uncommon for people to underestimate Customize, IMO.  Customize is in
fact surprisingly solid, and it does quite a lot that you or I might never think
to do by hand.

IOW, if you don't want to use the GUI then there is a fair amount that you
become responsible for getting right, if you want the same solid result.  This
is even more true if you write code that others will use, since they will do
things differently from what you might expect.

Please, don't just tell us here.  `M-x report-emacs-bug', if you think Emacs
code is broken.  That's the only real hope (however slim it might be in some
cases) of getting something fixed.

In all likelihood (my guess), if "customize" does not seem to do the right thing
in this particular case it is not because Customize is broken but because the
programmer who coded this particular user option did not do the right thing.
Those are not the same thing.  And the devil is in the details.  So provide the
details to Emacs Dev by reporting a bug.

You would not say "Lisp is broken" just because some programmer wrote some Lisp
code that didn't work, would you?

It is not my way.  I don't even use `message-syntax-checks' or Gnus, at all.
And I have _no_ plans to ever do so.

I do use `defcustom' heavily (more and more so), and I do use the Customize GUI.

FWIW, I didn't used to use Customize.  Like you, I was convinced that my reason
for that was that I didn't like the GUI.  I changed my mind about using it years
ago, though I am still of the opinion that the GUI sucks.  And the underlying
Lisp code is virtually impenetrable, if not a mine field.

What does not suck, however, is what Customize _does_, as opposed to how
ugly/inconvenient it might be to use or how hard its code might be to fathom.

I use a separate `custom-file' (Touches pas a mon .emacs!), and I find that
letting Customize handle my option & face customizations is a lot less
problematic than fiddling with the equivalent Lisp code myself.  YMMV.

I'm not trying to convince you - just telling my own story.  IMHO, Customize is
your friend - ugly and hard to understand, but your friend nonetheless.

BTW, the doc string and source code comments seem to be an admission that there
are some remaining problems.  They suggest that this option is complex and is
not necessarily for most end users to fiddle with.  IOW, this is not your
typical option.

In the doc string:

 Don't touch this variable unless you really know what you're doing.

In the code comments:

 ;; Guess this one shouldn't be easy to customize...
...
 ; Fixme: improve this

There are 3 official methods:
1- forget about flexibility and just set the var to a constant value
   that does not depend on the default value.  That can be done from the GUI.
2- if you want to use actual code (instead of a mere constant), then
   don't use Customize, and use something like the add-hook code you showed.
3- submit a patch for Customize which lets the user specify not just
   a new value but a change (like a "diff") to the default value.
   For lists representing sets, a way for the user to specify elements
   to add and elements to remove would be great.  For lists where order
   matters, the user should additionally have some control over where to
   add elements.
Point 3 would be *really* welcome.

        Stefan

+1

One reason this would be helpful would be simplicity of expression.  But
another, quite important reason IMO, would be some ability to better handle
updates of the default value, e.g. in a new version of the given defcustom.

For example, an option value that is a list of mappings of some kind might have
additional mappings by default in a newer version of the library.  If you have
already customized the option then you might not learn of the added
possibilities.  I see this fairly often.  You've customized based on the old
default value, not the new one.  Given some awareness of the change, you might
now want to customize the option differently.

But this problem of a changed default value is presented even for non-collection
options.  It would be good to have a simple (optional) way for users of a
library to be alerted that the default value of a given option or face that they
have customized has changed.

E.g., if the default value of `foo' was 3, you have customized it to 42, and the
default value is now nil, be able to be alerted to that default change.