Re: Compilation warnings in mouse.el

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Wed, 13 Jul 2016 11:12:35 -0400
> 
> >> The way I see it, defcustoms should pretty much never have :group, and
> >> the group to which they belong is simply determined by the file in which
> >> they occur.
> > But as long as such a system isn't installed, we shouldn't behave as
> > if it were.  (And what you propose is not without downsides, I think.)
> 
> Such a system has been installed ever since
> 
>     commit d3b80e9b70eaa0edb4cfc0d91543c41929fa70c0
>     Author: Stefan Monnier <address@hidden>
>     Date:   Sun Nov 18 01:35:12 2001 +0000
> 
>         (custom-current-group-alist): New var.
>         (custom-declare-group): Set it.
>         (custom-current-group): New fun.
>         (custom-declare-variable, custom-handle-all-keywords):
>         Use it as a default if no :group argument is specified.

No, I meant a system where one doesn't have to do anything to have a
group for a defcustom.  Nothing at all.

If they must first check if there's a defgroup in the same file, and
then if there's more than one defgroup, make sure the defcustom is
after the right one, then this is an error-prone system which cannot
be trusted.

> >> I don't see how removing/adding defcustoms in the same file
> >> would introduce problems.
> > We just saw such a problem, no?
> 
> I must have missed something.  All I saw was that someone added
> a defcustom in mouse.el and did not put a :group while there is no
> defgroup in that file (and all other defcustoms in there have a :group).
> 
> That seems pretty far from "removing/adding defcustoms in the same file".

OK, s/defcustom/defgroup/.

> But I'm opposed to having it be mandatory in the obvious case of
> a single-file single-group package, where the :group args are just
> redundant.  My above 2001 commit was designed to solve that case and
> it's proved to work fine since.

IME, solving part of a problem doesn't really solve it.