bug#3811: 23.0.96; custom-group-members

bug#3811: 23.0.96; custom-group-members

[Drew Adams]

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)'
 

bug#3811: 23.0.96; custom-group-members

[Stefan Monnier]

> 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

bug#3811: 23.0.96; custom-group-members

[Drew Adams]

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

bug#3811: 23.0.96; custom-group-members

[Drew Adams]

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

bug#3811: marked as done (23.0.96; custom-group-members)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]


Your message dated Wed, 15 Jul 2009 14:39:05 -0400
with message-id <jwvws69er36.fsf-monnier+emacsbugreports@gnu.org>
and subject line Re: bug#3811: 23.0.96; custom-group-members
has caused the Emacs bug report #3811,
regarding 23.0.96; custom-group-members
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
3811: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3811
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3700 bytes --]

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

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)'
 



[-- Attachment #3: Type: message/rfc822, Size: 3765 bytes --]

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

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