Re: custom: how do I augment an option?

Re: custom: how do I augment an option?

[Sam Steingold]

This was originally discussed on gnu-emacs-help, but it appears that the
further discussion should take place on emacs-devel.

I said:

If I want to _modify_ a 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---
which will break if `message-syntax-checks' ever acquires a setter
or
--8<---------------cut here---------------start------------->8---
(custom-set-variables
 '(message-syntax-checks
   (cl-adjoin '(long-lines . disabled)
    (eval (car (get 'message-syntax-checks 'standard-value)))
    :test 'equal)))
--8<---------------cut here---------------end--------------->8---
which uses a CL function _and_ also eval.

> * Stefan Monnier <zbaavre@veb.hzbagerny.pn> [2012-09-06 09:14:55 -0400]:
>
>> So, what is the official method?
>
> 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.

this sucks as it ignores the changes in the default value, as discussed
on gnu-emacs-help.

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

this sucks in case the custom variable in question ever acquires a
setter, as mentioned above.

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

How about changing `custom-set-variables' to accept

(SYMBOL EXP [NOW [REQUEST [COMMENT [SETTER]]]])

instead of

(SYMBOL EXP [NOW [REQUEST [COMMENT]]])

where SETTER would be a function acceptable as the :set argument to
defcustom.

(Actually, I would prefer to replace the positional optional arguments
with keywords, like in `defcustom', but that would be an incompatible
change)

Also, semi-independently, I propose a function

(defun custom-standard-value (symbol)
  "Return the standard value of the customizable option."
  (eval (car (get symbol 'standard-value))))

A cheap ad-hoc fix for `message-syntax-checks' (and other set variables)
would be to give it a setter which would accept lists like (add ...) or
(delete ...).

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://dhimmi.com http://honestreporting.com
http://jihadwatch.org http://www.PetitionOnline.com/tap12009/
When you talk to God, it's prayer; when He talks to you, it's schizophrenia.

Re: custom: how do I augment an option?

[Stefan Monnier]

> If I want to _modify_ a custom variable, I have to resort to something like
> --8<---------------cut here---------------start------------->8---
> (custom-set-variables
>  '(message-syntax-checks
>    (cl-adjoin '(long-lines . disabled)
>     (eval (car (get 'message-syntax-checks 'standard-value)))
>     :test 'equal)))
> --8<---------------cut here---------------end--------------->8---
> which uses a CL function _and_ also eval.

While `adjoin' is frowned upon, using `cl-adjoin' is accepted.

> How about changing `custom-set-variables' to accept
> (SYMBOL EXP [NOW [REQUEST [COMMENT [SETTER]]]])
> instead of
> (SYMBOL EXP [NOW [REQUEST [COMMENT]]])
> where SETTER would be a function acceptable as the :set argument to
> defcustom.

That doesn't sound good to me.  A `setter' is the function that takes
the value of EXP and "puts it at the right place" (possibly changing it
to another representation along the way).  That sounds quite different
from what you want.

> Also, semi-independently, I propose a function
> (defun custom-standard-value (symbol)
>   "Return the standard value of the customizable option."
>   (eval (car (get symbol 'standard-value))))

That sounds OK.  Tho, since Custom also manages faces, it would make
sense to give it a name that includes "variable".  Sadly,
custom-variable-standard-value is already taken for "the same thing but
without `eval' and `car'".
OTOH, there's only one use of custom-variable-standard-value currently,
and we can hope that it's not used outside, so it might be OK to
change that use and hijack the name for your above function (post 24.3,
obviously).


        Stefan