RE: byte-compile-nogroup-warn effectively disabled

[Drew Adams]

>  > However the group is chosen from among those groups
>  > defined in the file, there is no reason to assume that it
>  > is the appropriate one for defcustoms that have no :group.
> ...
> I just gave you two: at least one natural style has that property,
> and most files will have only one defgroup.

I already agreed that it would be OK if restricted to that subset (I said, "if
there is only one group definition in the file").

That is not the general case, however. You've described and argued to support a
particular case where you find it useful and where I agreed there is no great
problem. Why not restrict the proposed behavior to that case? Especially if
"most files will have only one defgroup", that should satisfy you.

> In fact, except for the fact that a lot of my tools currently don't
> handle def-forms as I would want when they're not at toplevel, I'd be
> perfectly happy with an extended defgroup syntax:
> 
> (defgroup a   ; docstring, parent group, etc go here
>   (defcustom a-1)
>   (defface a-2))

That's a horse of a different color. I have no problem with adding something
like that.

I would also have no problem with a form that doesn't define a new group but
just declares the group for multiple options and faces:

(custom-group a   ; or some other function name
  (defcustom a-1)
  (defface a-2))

Or even allowing multiple groups:

(custom-group (convenience hypermedia)
  (defcustom a-1)
  (defface a-2))

> your practice of explicitly selecting the
> group(s) for each object at the time of writing the defface or
> defcustom is far more error-prone in maintenance, and at least
> somewhat error-prone at write-time.

Different strokes for different folks. There is not only one use case or only
one right or reasonable approach to coding and code maintenance.