RE: byte-compile-nogroup-warn effectively disabled

["Drew Adams" <drew.adams@oracle.com>]

> > effectively defeats the point of that warning, which is to
> > make sure that every defcustom and defface specifies the group.
> 
> I know it's your opinion, and I disagree.  Even without an
> explicit :group, the defcustom will have a proper group 
> attributed to it
> because it will use the last group defined in the file.  So, in my
> opinion it fixes the warning so that it only occurs in cases where the
> lack of the :group really leads to the variable being associated to no
> group at all.

Sorry, I haven't followed this. But IIUYC, I think it would be a mistake to
automatically assign an option or face the group that was last specified before
it in the same file.

What for? What is gained? Sounds like an invitation for user errors that won't
necessarily be noticed right away. It might not be an important error to assign
the wrong group, but why encourage that possibility?

What do you do when more than one :group is used in the previous defcustom? Do
you use the last one in that defcustom? Until now, :group order within a
defcustom has had no importance. Or do you use all of the :groups of that
defcustom?

In Icicles, for instance, I have several groups of options - for minibuffer
highlighting, completion behavior, *Completions* display, buffer treatment, key
bindings, key completion, matching, and so on. In some csaes, an option belongs
to more than one such group. I generally present the options in alphabetic order
in the file. There is no reason at all to assume that the next option in the
file should have the same group(s) as the previous one. If I forget to add a
:group, I would rather see a warning and have no group assigned than to have
some inappropriate group (not "a proper group") assigned. 

I don't see the point of this. Personally, I don't care much one way or the
other about the warnings - they are just an extra aid. But automatically
assigning groups sounds like asking for (minor) trouble.