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

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

[Howard Melman]

The defcustom for python-forward-sexp-function in python.el is in the
python-flymake defgroup. I believe it should be in the python defgroup.

It should probably be moved to the ;;; Navigation section of the file,
but certainly before the defgroup for python-flymake

Howard


In GNU Emacs 28.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95))
of 2022-04-04 built on builder10-14.lan
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.6.5

Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

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

[Eli Zaretskii]

> From: Howard Melman <hmelman@gmail.com>
> Date: Tue, 19 Apr 2022 17:27:42 -0400
> 
> The defcustom for python-forward-sexp-function in python.el is in the
> python-flymake defgroup. I believe it should be in the python defgroup.

We could make it be in both groups, if that makes sense.

> It should probably be moved to the ;;; Navigation section of the file,
> but certainly before the defgroup for python-flymake

Why does its exact position in the source file matter?

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

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Howard Melman <hmelman@gmail.com>
>> Date: Tue, 19 Apr 2022 17:27:42 -0400
>> 
>> The defcustom for python-forward-sexp-function in python.el is in the
>> python-flymake defgroup. I believe it should be in the python defgroup.
>
> We could make it be in both groups, if that makes sense.
>
>> It should probably be moved to the ;;; Navigation section of the file,
>> but certainly before the defgroup for python-flymake
>
> Why does its exact position in the source file matter?

FWIW, this has been fixed on the master branch, in bug#51807.  IIRC the
issue (and the reason for Howard's suggestion) is that python.el has two
`defgroup' clauses (python and python-flymake), and the new option was
declared after the latter, which makes the Custom machinery think it
belongs in the latter.

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

[Howard Melman]

On Apr 20, 2022, at 2:31 AM, Kévin Le Gouguec <kevin.legouguec@gmail.com> wrote:
> 
> FWIW, this has been fixed on the master branch, in bug#51807.  IIRC the
> issue (and the reason for Howard's suggestion) is that python.el has two
> `defgroup' clauses (python and python-flymake), and the new option was
> declared after the latter, which makes the Custom machinery think it
> belongs in the latter.

Thanks.

Howard

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

[Kévin Le Gouguec]

Howard Melman <hmelman@gmail.com> writes:

> On Apr 20, 2022, at 2:31 AM, Kévin Le Gouguec <kevin.legouguec@gmail.com> wrote:
>> 
>> FWIW, this has been fixed on the master branch, in bug#51807.  IIRC the
>> issue (and the reason for Howard's suggestion) is that python.el has two
>> `defgroup' clauses (python and python-flymake), and the new option was
>> declared after the latter, which makes the Custom machinery think it
>> belongs in the latter.

Also FWIW, I think that the fix[1] should be safe to backport for 28.2.

I'm saying this just in case the weather on emacs-28 has thawed a bit
now that 28.1 is out.  My impression is that the "safety threshold" had
risen exceptionally high by the time I submitted the fix, due to the
release edging closer; if that's not the case, please disregard.


[1] 2021-11-14 "Fix customization group of python-forward-sexp-function"
    (48ffbcf7eb)

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

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Howard Melman <hmelman@gmail.com>,  55027@debbugs.gnu.org
> Date: Wed, 20 Apr 2022 21:55:58 +0200
> 
> Howard Melman <hmelman@gmail.com> writes:
> 
> > On Apr 20, 2022, at 2:31 AM, Kévin Le Gouguec <kevin.legouguec@gmail.com> wrote:
> >> 
> >> FWIW, this has been fixed on the master branch, in bug#51807.  IIRC the
> >> issue (and the reason for Howard's suggestion) is that python.el has two
> >> `defgroup' clauses (python and python-flymake), and the new option was
> >> declared after the latter, which makes the Custom machinery think it
> >> belongs in the latter.
> 
> Also FWIW, I think that the fix[1] should be safe to backport for 28.2.

I fixed it in a safer way on the release branch, thanks.

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

[Howard Melman]

On Apr 21, 2022, at 2:07 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> I fixed it in a safer way on the release branch, thanks.

Why did you keep it in the python-flymake group in addition to the
python group?  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.

Howard

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 08:06:14 -0400
> Cc: Kévin Le Gouguec <kevin.legouguec@gmail.com>,
>  55027@debbugs.gnu.org
> 
> On Apr 21, 2022, at 2:07 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > I fixed it in a safer way on the release branch, thanks.
> 
> 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.

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

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

[Howard Melman]

On Apr 21, 2022, at 8:44 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Howard Melman <hmelman@gmail.com>
>> Date: Thu, 21 Apr 2022 08:06:14 -0400
>> Cc: Kévin Le Gouguec <kevin.legouguec@gmail.com>,
>> 55027@debbugs.gnu.org
>> 
>> On Apr 21, 2022, at 2:07 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>> I fixed it in a safer way on the release branch, thanks.
>> 
>> 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.

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

It was a mistake for it to be in that group in the first place, why prolong it?  
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.

Howard

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.

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

[Howard Melman]

On Apr 21, 2022, at 11:37 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 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.

That's fine, but no I don't agree this is incompatible let alone
radically so. (It seems to get more incompatible with each email :)

But so be it.

Howard

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

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

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

FWIW: we already have two users (Howard and myself) who raised an
eyebrow seeing this option in python-flymake, and took the time to write
a bug report about it.

It's not entirely unlikely that more Emacs 28 users will happen to see
this option in that group while perusing the python-flymake group, raise
an eyebrow, and write a report.  Even assuming they use 28.2, they might
not think to check that it is also present in the "python" group, and
might do as we did and assume it's a mistake.

And even if they see that the option is also in the "python" group, they
might not look further than "well that's silly, it shouldn't belong in
python-flymake, let's report this".  I wouldn't fault them for that.


I don't mind your solution and don't want to waste anyone's time with
this; I just saw your question and took the bait, since those
hypothetical scenarios I describe sound more likely to me than the one
you have in mind (IIUC: a user being {accustomed to,fine with,not
confused by} this new option being in the python-flymake group).

Please dismiss if you're not convinced.

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

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Howard Melman <hmelman@gmail.com>,  55027@debbugs.gnu.org
> Date: Thu, 21 Apr 2022 20:09:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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?
> 
> FWIW: we already have two users (Howard and myself) who raised an
> eyebrow seeing this option in python-flymake, and took the time to write
> a bug report about it.
> 
> It's not entirely unlikely that more Emacs 28 users will happen to see
> this option in that group while perusing the python-flymake group, raise
> an eyebrow, and write a report.  Even assuming they use 28.2, they might
> not think to check that it is also present in the "python" group, and
> might do as we did and assume it's a mistake.
> 
> And even if they see that the option is also in the "python" group, they
> might not look further than "well that's silly, it shouldn't belong in
> python-flymake, let's report this".  I wouldn't fault them for that.

I raise a brow about something in Emacs almost every day.  That
doesn't mean all those things are problems.  Let's not make a mountain
out of a molehill.

Also, let's not behave as if another opinion that's against mine will
change anything in a decision I made after careful consideration of
the possible alternatives.  Contrary to popular belief, I don't make
such decisions easily, and would appreciate some minimal credit here.

> I don't mind your solution and don't want to waste anyone's time with
> this; I just saw your question and took the bait, since those
> hypothetical scenarios I describe sound more likely to me than the one
> you have in mind (IIUC: a user being {accustomed to,fine with,not
> confused by} this new option being in the python-flymake group).
> 
> Please dismiss if you're not convinced.

I'm not convinced, because I considered these effects before I decided
to make that change.