emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Customize Rogue


From: Luc Teirlinck
Subject: Re: Customize Rogue
Date: Thu, 13 Mar 2003 08:44:54 -0600 (CST)

Per Abrahamsen wrote:

   I don't think that is reasonable, the function signature expected by
   :set is slightly different from the the function signature that would
   be most natural from Lisp.  I.e. something like

     (decustom foo-bar-mode nil
       "Foo bar minor mode.
     Must be set with (foo-bar-mode VALUE) or through Customize."
       :type 'boolean
       :set (lambda (symbol value) (foo-bar-mode value)))

   is quite reasonable.  I.e. SYMBOL will often be implicit in the Lisp
   function.

It might be that there are other examples (but not this one, see
below) that show that the requirements I had in mind are unreasonable.
Maybe it might be better to view the proposal not as an absolute
"requirement", but just as a "suggested" semi-standard way to do
things, from which deviations are perfectly OK in cases where Lisp
alternatives to the :set function are obvious.

I am not sure you understand what I meant though, because the example
above supports my proposal, rather than being an argument against it.
(Actually, it even is the kind of example that inspired the
proposal.)  It seems that, in the above:

:set #'funcall

has exactly the same effect as what you wrote:

It gives (funcall symbol value), symbol evaluates to foo-bar-mode, so
we get (foo-bar-mode value), equivalent with your lambda expression.
(Unless I am confused about something.)  The problem with this, but
also with your (equivalent) :set function is that setting the variable
to nil will toggle the mode rather than deactivate it.  That is why
define-minor-mode produces:

:set (lambda (symbol value) (funcall symbol (or value 0)))

If, for technical reasons, the (or value 0) is unnecessary protection,
it would strengthen the argument for my proposal.

The proposal was inspired by statements that :set is needed because
Custom only handles variables, not functions, that certain functions
mimic customization variables and that most examples are minor modes.
If the function and the variable are so closely related, why not give
them the same name, as is the case with minor modes?  This would in
effect treat such a "user option function" as a kind of "non-boolean
minor mode".  The intended purpose is obviously to avoid the need for
the user to check up the name of the function using C-h v.

Sincerely,

Luc.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]