Re: defcustoms in style/*.el

Ralf Angeli <[email protected]> writes:

> * David Kastrup (2005-03-08) writes:
>
>> Ralf Angeli <[email protected]> writes:
>>
>>> * David Kastrup (2005-03-08) writes:
>>>
>>>> Ralf Angeli <[email protected]> writes:
>>>
>>> The thing I don't like about putting the defcustoms into a separate
>>> file is that they are not near the actual code they are used in
>>> anymore.  This may lead to inconveniences during coding and is
>>> somewhat contrary to the rather decentralized approach we have with
>>> the style files.
>>>
>>> I'd rather like to have this solved with autoload.  But as we saw,
>>> Customize is not able to build a buffer with autoloaded defcustoms
>>> as they don't provide information to which group they belong.
>>
>> Well, so what?  Then we'll just place explicit :group tags into every
>> defcustom.  I don't see the problem.
>
> Could you elaborate on that?
>
> I tried
>
> (custom-autoload (quote LaTeX-beamer-item-overlay-flag) "style/beamer")
>
> which did not work[1] despite `LaTeX-beamer-item-overlay-flag' having had
> a ":group 'LaTeX-macro" tag until yesterday.  (It now has a ":group
> 'LaTeX-style" tag.)  And I am not really sure if I am bending the
> definition of `custom-autoload' too much by using something like
> "style/beamer".

Ok, so maybe I misunderstood the process.  Would using any of
(defun custom-add-to-group (group option widget)
  "To existing GROUP add a new OPTION of type WIDGET.
If there already is an entry for OPTION and WIDGET, nothing is done."
...

(defun custom-group-of-mode (mode)
  "Return the custom group corresponding to the major or minor MODE.
If no such group is found, return nil."

be helpful for the task at hand?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum