Re: Getting more info on a variable in Customize buffers

[Stefan]

>>> I probably don't fully understand, although I think I follow you. Sounds
>>> like an implementation problem to me - or perhaps a design problem?
>> 
>> The designer might call it a feature rather than a problem.
>> 
>> I do tend to think that it was a mistake to design something that looks like
>> an elisp variable and which happens to be an elisp variable in 99% of the
>> cases but which may be something else.

> I kind of agree, I always thought there instead would be many more
> "defsomething".  

> The :get, :set and :init were, if I remember right, introduced by
> XEmacs people for use with specifiers.  And since I didn't really care
> about XEmacs (and certainly didn't understood specifiers to write a
> defspecifier) I let them have their way.

Interesting.  And good to hear.

> And when it was there, it also got (ab)used in Emacs for minor modes.
> It should have been part of a define-minor-mode instead, but as I
> remember there already is was one of those.

We now have a proper `define-minor-mode' (which internally uses :set but
I guess that's OK).

> There also is a patch floating around here to overload defcustom for
> keymaps as well.  Again, I can't come up with a good API for a
> "defkeymap", and wouldn't find the time to implement it anyway.

I remember trying to introduce `defkeymap' but there wasn't much support for
it (it was a long time ago, way before the keymap-custom hack appeared).
Most/all keymaps are defined as something similar to:

  (defvar foo-map
      (let ((map (make-sparse-keymap)))
        (define-key map X1 Y1)
        (define-key map X2 Y2)
        (define-key map X3 Y3)
        (substitute-key-definition X4 Y4 map global-map)
        map))

so I suggested

  (defkeymap foo-map
     '((X1 Y1)
       (X2 Y2)
       (X3 Y3)
       (X4 Y4)))

with some additional options like :inherit and :suppress.  What it does
w.r.t Custom can then be adjusted as you please and improved over time.


        Stefan