GNU bug report logs - #3811
23.0.96; custom-group-members

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3811 in the body.
You can then email your comments to 3811 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <emacs-pretest-bug <at> gnu.org>
Subject: 23.0.96; custom-group-members
Date: Fri, 10 Jul 2009 10:53:13 -0700

emacs -Q
 
Dunno if this is just a doc bug or a code bug. `custom-group-members'
seems to give the same result - a list of groups, whether its second
arg GROUPS-ONLY is nil or t. I don't see any difference.
 
Even if there are some cases where there would be a difference, the
doc string is unclear, because it doesn't say what the alternative
is. What should you expect if GROUPS-ONLY is nil, other than groups?
What else might be included in the list?
 
FWIW, I was looking for a function that, given a group, would return a
list of all options and faces in that group (directly, not by
inheritance). From the function name and doc string, I thought perhaps
`custom-group-members' would do the job (with a nil arg). Apparently
not. But I don't know what it is _supposed_ to do when GROUPS-ONLY is
nil.
 

In GNU Emacs 23.0.96.1 (i386-mingw-nt5.1.2600)
 of 2009-07-09 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 3811 <at> debbugs.gnu.org, <emacs-pretest-bug <at> gnu.org>
Subject: Re: bug#3811: 23.0.96; custom-group-members
Date: Wed, 15 Jul 2009 10:46:15 -0400

> emacs -Q
> Dunno if this is just a doc bug or a code bug. `custom-group-members'
> seems to give the same result - a list of groups, whether its second
> arg GROUPS-ONLY is nil or t. I don't see any difference.

Can't reproduce it here:
 
   emacs -Q
   M-x load-library RET cus-edit RET
   M-: (custom-group-members 'custom-faces nil) RET

gives me a list of the members of that group, one of which is itself
a group but the rest isn't:

   ((custom-magic-faces custom-group)
    (custom-button custom-face)
    (custom-button-mouse custom-face)
    (custom-button-unraised custom-face)
    (custom-button-pressed custom-face)
    (custom-button-pressed-unraised custom-face)
    (custom-documentation custom-face)
    (custom-state custom-face)
    (custom-link custom-face)
    (custom-comment custom-face)
    (custom-comment-tag custom-face)
    (custom-variable-tag custom-face)
    (custom-variable-button custom-face)
    (custom-visibility custom-face)
    (custom-face-tag custom-face)
    (custom-group-tag-faces custom-variable)
    (custom-group-tag-1 custom-face)
    (custom-group-tag custom-face))


-- Stefan

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: <3811 <at> debbugs.gnu.org>, <emacs-pretest-bug <at> gnu.org>
Subject: RE: bug#3811: 23.0.96; custom-group-members
Date: Wed, 15 Jul 2009 08:11:20 -0700

You're right; I was wrong. I think I must have tested it only on groups that
have only groups as members - group `editing', for example. Guess I didn't
realize I was doing that.

It might be useful to have another function (or perhaps another optional arg to
this function), which would act recursively to give you all members, indirect or
direct, that belong to the group - IOW, anything that belongs to the group or to
one of its subgroups (recursively).

In any case, what I said about the doc string remains true. There should be some
description of the alternative: "What should you expect if GROUPS-ONLY is nil,
other than groups? What else might be included in the list?"

Other than that, this can be closed.

> From: Stefan Monnier Sent: Wednesday, July 15, 2009 7:46 AM
> > emacs -Q
> > Dunno if this is just a doc bug or a code bug. 
> > `custom-group-members' seems to give the same result -
> > a list of groups, whether its second arg GROUPS-ONLY is nil
> > or t. I don't see any difference.
> 
> Can't reproduce it here:
>  
>    emacs -Q
>    M-x load-library RET cus-edit RET
>    M-: (custom-group-members 'custom-faces nil) RET
> 
> gives me a list of the members of that group, one of which is itself
> a group but the rest isn't:
> 
>    ((custom-magic-faces custom-group)
>     (custom-button custom-face)
>     (custom-button-mouse custom-face)
>     (custom-button-unraised custom-face)
>     (custom-button-pressed custom-face)
>     (custom-button-pressed-unraised custom-face)
>     (custom-documentation custom-face)
>     (custom-state custom-face)
>     (custom-link custom-face)
>     (custom-comment custom-face)
>     (custom-comment-tag custom-face)
>     (custom-variable-tag custom-face)
>     (custom-variable-button custom-face)
>     (custom-visibility custom-face)
>     (custom-face-tag custom-face)
>     (custom-group-tag-faces custom-variable)
>     (custom-group-tag-1 custom-face)
>     (custom-group-tag custom-face))

Message #30 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: <3811 <at> debbugs.gnu.org>, <emacs-pretest-bug <at> gnu.org>
Subject: RE: bug#3811: 23.0.96; custom-group-members
Date: Wed, 15 Jul 2009 10:13:32 -0700

> It might be useful to have another function (or perhaps 
> another optional arg to this function), which would act 
> recursively to give you all members, indirect or direct, that 
> belong to the group - IOW, anything that belongs to the group 
> or to one of its subgroups (recursively).

To be clear what I meant, something like this:

(defun custom-group-members (symbol groups-only
                             &optional recursivep)
  "Return members of the custom group for SYMBOL.
If GROUPS-ONLY is non-nil, return only those direct members
 that are groups.
If RECURSIVEP is non-nil and GROUPS-ONLY is nil, return
 non-group direct and indirect members."
  (let ((members  ()))
    (cond (groups-only
           (dolist (entry  (get symbol 'custom-group))
             (when (eq (cadr entry) 'custom-group)
               (push entry members)))
           (nreverse members))
          (recursivep
           (let ((direct-members  (custom-group-members symbol nil)))
             (dolist (dm  direct-members)
               (if (eq (cadr dm) 'custom-group)
                   (setq members
                         (nconc (custom-group-members (car dm) nil t)
                                members))
                 (push dm members)))
             (nreverse members)))
          (t
           (get symbol 'custom-group)))))

It would be even better to combine args GROUPS-ONLY and RECURSIVEP, but that
might mean problems for backward incompatibility. But perhaps something like
this would be OK?

(defun custom-group-members (symbol arg)
  "Return members of the custom group for SYMBOL.
ARG nil means return all direct group members: groups and non-groups.
ARG `nongroups' means return all nongroup members, recursively.
ARG anything else means return all direct group members."
  (let ((members  ()))
    (case arg
      ((nil) (get symbol 'custom-group))
      (nongroups
       (let ((direct-members  (custom-group-members symbol nil)))
         (dolist (dm  direct-members)
           (if (eq (cadr dm) 'custom-group)
               (setq members
                     (nconc (custom-group-members
                             (car dm) 'nongroups)
                            members))
             (push dm members)))
         (nreverse members)))
      (t (dolist (entry  (get symbol 'custom-group))
           (when (eq (cadr entry) 'custom-group)
             (push entry members)))
         (nreverse members)))))

That would still work for any existing code that used a value other than
`nongroups' as the second arg, which probably means there would be no problems
in practice.

We might also consider making this a command. Users could use it to print out a
list of the options and faces for a group.

Note that one use of the proposed recursive behavior is for a user to create a
custom group that represents a collection of personal settings (across other
custom groups), and then to share those settings with others. (See the
emacs-devel discussion of "skins" as custom groups.)

A user Jane could, for example, use `custom-add-to-group' with group `jane', and
then she could publish the `jane' settings for others, retrieving them using
`custom-group-members'. The only other piece missing would then be a way for
non-Lisp users to do the equivalent of `custom-add-to-group' using only the
Customize UI. That is, we would provide easy ways to specify that certain
options and faces should be added to group `jane'.

Message #40 received at 3811-close <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: <3811-close <at> debbugs.gnu.org>
Subject: Re: bug#3811: 23.0.96; custom-group-members
Date: Wed, 15 Jul 2009 14:39:05 -0400

>            (let ((direct-members  (custom-group-members symbol nil)))
>              (dolist (dm  direct-members)
>                (if (eq (cadr dm) 'custom-group)
>                    (setq members
>                          (nconc (custom-group-members (car dm) nil t)
>                                 members))

Beware of infinite-recursion since the groups aren't guaranteed to form
a DAG.

> It would be even better to combine args GROUPS-ONLY and RECURSIVEP, but that
> might mean problems for backward incompatibility. But perhaps something like
> this would be OK?

Don't know.  Depends if you want to be able to get "all groups,
recursively" or not.

> We might also consider making this a command. Users could use it to
> print out a list of the options and faces for a group.

> Note that one use of the proposed recursive behavior is for a user to
> create a custom group that represents a collection of personal
> settings (across other custom groups), and then to share those
> settings with others. (See the emacs-devel discussion of "skins" as
> custom groups.)

> A user Jane could, for example, use `custom-add-to-group' with group
> `jane', and then she could publish the `jane' settings for others,
> retrieving them using `custom-group-members'. The only other piece
> missing would then be a way for non-Lisp users to do the equivalent of
> `custom-add-to-group' using only the Customize UI. That is, we would
> provide easy ways to specify that certain options and faces should be
> added to group `jane'.

Isn't that going in the same direction as Custom themes?
In any case, it's way out of the scope of this bug report, which
I hence close.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.