bug#55027: 28.1; User option python-forward-sexp-function in wrong group

[Eli Zaretskii]

> From: Howard Melman <hmelman@gmail.com>
> Date: Thu, 21 Apr 2022 10:33:57 -0400
> Cc: Kévin Le Gouguec <kevin.legouguec@gmail.com>,
>  55027@debbugs.gnu.org
> 
> >> Why did you keep it in the python-flymake group in addition to the
> >> python group?
> > 
> > Because it was there in Emacs 28.1.  I didn't want to make
> > incompatible changes on the release branch.
> 
> I wouldn't call a change in what group an option appears in
> in an interactive customize session an incompatibility.  The change
> in group has nothing to do with how it's set or used.

If someone got used to its being in a certain group in Emacs 28.1,
removing it from that group would be an incompatible change for that
someone.

> >> It has nothing to do with flymake.  
> >> 
> >> Since it's a new option, you're just extending the amount of time
> >> for people to get confused by it.
> > 
> > Confused in what way?  How can the fact that an option appears in an
> > additional customization group confuse someone?
> 
> Because it will still appear in the python-flymake group and it has
> nothing to do with flymake.  Anyone looking at the python-flymake
> group will be confused as to why it's there. 

Customization groups exist to let users conveniently find options
related to some subject.  Having an option in a group where it doesn't
belong doesn't do any harm, as long as the option is also in a group
where it does belong.  So even if you are right, and the variable
really has nothing to do with the python-flymake group, there's will
be harm done, because being part of a group doesn't mean anything
except that we considered it to be useful to be part of that group.
There's no other meaning to this, and thus no confusion is or can be
involved.

I think you are just interpreting being part of a group incorrectly,
if you think it has some significance beyond convenience.

> It was a mistake for it to be in that group in the first place, why prolong 
> it?  

We didn't prolong it.  That option is now in the group to which it
belongs, so the mistake is fixed.  That it is also in another group
lets users who may look for it there more time to adapt and smoother
transition to its future disappearance from the python-flymake group.

> I don't see why a change in which group an option appears in can
> only happen in a major release.  Fixing it sooner means fewer people
> will be affected by any incompatibility.

My opinion is different, sorry.  I consider radical incompatible
changes something to avoid as much as possible.  Please trust me that
I didn't arrive at those opinions without a good reason.