RE: byte-compile-nogroup-warn effectively disabled

[Stephen J. Turnbull]

Drew Adams writes:

 > Then I misunderstood that part; sorry. But it's irrelevant to the
 > points I raised. 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.

Please don't be unnecessarily contentious.  I just gave you two: at
least one natural style has that property, and most files will have
only one defgroup.  (After this I will refer to "the 'natural' style"
in quotes, to remind the reader that it's not the only reasonable
style.)

 > (I assume nothing happens if no group is defined in the file, even
 > if there are some :groups used in some defcustoms.)

In that case with Stefan's code a warning is issued.  I'm not sure if
that qualifies as "nothing"?

 > Wrt to the rest of what you write, it seems you are arguing that it
 > might be convenient for some people who follow certain coding
 > practices, since it would mean they could skip the burden of adding
 > :group to each definition, with the side benefit of less verbose
 > code.

I'm arguing that it eliminates redundancy, is less verbose, and
encourages appropriate modularity.  The "burden of adding :group" is
not an issue, as that can easily be automated.

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

and a warning for def-forms without :group at toplevel.  That may not
be very Lisp-y, though.

 > That doesn't sound convincing, to me. This convenience for some in
 > some use cases will open the door to errors by all.

"Opening the door to errors" is FUD.  The question is how error-prone
is it?  I would argue that 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.

Should you refactor the groups, you'll have to collect them all and
examine each member to be sure that it ends up in the right group.
Using the "natural" organization, you have all the relevant forms in
one place, separated by defgroups that make the current rationale
clear.  When writing the def-forms, you have to keep an accurate model
of the group structure in your head.  But what if you go back and
refactor halfway?  Will you remember all of the relevant def-forms to
change?  Again, in this case under the "natural" organization all will
be in one place, and most will be in the same few groups.