python minor-mode

python minor-mode

[Andreas Röhler]

Hi,

Currently, both python.el and python-mode.el define a minor-mode called 
"python-mode". Which may create some confusion. Wouldn't it be more 
natural if both files provide modes according to their filename? I.e. 
python.el should establish "python" as minor-mode, python-mode.el sends 
"python-mode".

Best,

Andreas

Re: python minor-mode

[Eli Zaretskii]

> Date: Mon, 21 Mar 2022 09:19:29 +0100
> From: Andreas Röhler <andreas.roehler@online.de>
> Cc: Barry Warsaw <barry@python.org>
> 
> Currently, both python.el and python-mode.el define a minor-mode called 
> "python-mode". Which may create some confusion. Wouldn't it be more 
> natural if both files provide modes according to their filename? I.e. 
> python.el should establish "python" as minor-mode, python-mode.el sends 
> "python-mode".

The names of our mode symbols usually end in "-mode", so I think it
would be confusing to have a mode called "python".

Re: python minor-mode

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 927 bytes --]

Andreas R0‹2hler <andreas.roehler@online.de> writes:


The bigger question:

There were clearly reasons for the existence of these two in the past
--- python.el and python-mode.el -- do those reasons still exist. They
each have almost similar functionality -- and it may be worthwhile for
some wise heads to come together and create a single, consolidated
python package for emacs.

I can vouch from my own use that this split causes massive confusion.

> Hi,
>
> Currently, both python.el and python-mode.el define a minor-mode
> called "python-mode". Which may create some confusion. Wouldn't it be
> more natural if both files provide modes according to their filename?
> I.e. python.el should establish "python" as minor-mode, python-mode.el
> sends "python-mode".
>
> Best,
>
> Andreas
>
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: python minor-mode

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

I haven’t looked at python.el in a long while but last time I did, it was not PEP 8 compliant.

-Barry

> On Mar 21, 2022, at 06:37, T.V Raman <raman@google.com> wrote:
> 
> Andreas Röhler <andreas.roehler@online.de> writes:
> 
> 
> The bigger question:
> 
> There were clearly reasons for the existence of these two in the past
> --- python.el and python-mode.el -- do those reasons still exist. They
> each have almost similar functionality -- and it may be worthwhile for
> some wise heads to come together and create a single, consolidated
> python package for emacs.
> 
> I can vouch from my own use that this split causes massive confusion.
> 
>> Hi,
>> 
>> Currently, both python.el and python-mode.el define a minor-mode
>> called "python-mode". Which may create some confusion. Wouldn't it be
>> more natural if both files provide modes according to their filename?
>> I.e. python.el should establish "python" as minor-mode, python-mode.el
>> sends "python-mode".
>> 
>> Best,
>> 
>> Andreas
>> 
>> 
> 
> --
> 
> Thanks,
> 
> --Raman(I Search, I Find, I Misplace, I Research)
> ♈ Id: kg:/m/0285kf1  🦮


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: python minor-mode

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2394 bytes --]

Barry Warsaw <barry@python.org> writes:


Hi Barry,

Good to hear from you after a long time.

I recall that at one time, there was a similar split between emacs'
built-in C-mode vs the much-enhanced cc-mode  that you and others had
developed; eventually cc-mode and its goodness landed in Emacs.I'm
optimistically hoping for the same for Python:-)


I'm sure there are still differences between python.el and
python-mode.el though in the last 10 years or so, python.el has grown
significantly in size.

I mostly use elpy to pull together all the various emacs/python goodies
and after getting very confused between python.el and python-mode.el
eventually uninstalled python-mode.el so that I could avoid getting
tripped up; for better or worse, I've not noticed too much difference
and it's actually nice to have one less thing to worry about when being
surprized by some unexpected behavior.

With respect to code formatting etc, I now achieve that via external
tools like yapf that elpy wrappers, and have the formatting operation
happen on each save.


> I haven¡¯t looked at python.el in a long while but last time I did, it was not PEP 8 compliant.
>
> -Barry
>
>> On Mar 21, 2022, at 06:37, T.V Raman <raman@google.com> wrote:
>> 
>> Andreas R0‹2hler <andreas.roehler@online.de> writes:
>> 
>> 
>> The bigger question:
>> 
>> There were clearly reasons for the existence of these two in the past
>> --- python.el and python-mode.el -- do those reasons still exist. They
>> each have almost similar functionality -- and it may be worthwhile for
>> some wise heads to come together and create a single, consolidated
>> python package for emacs.
>> 
>> I can vouch from my own use that this split causes massive confusion.
>> 
>>> Hi,
>>> 
>>> Currently, both python.el and python-mode.el define a minor-mode
>>> called "python-mode". Which may create some confusion. Wouldn't it be
>>> more natural if both files provide modes according to their filename?
>>> I.e. python.el should establish "python" as minor-mode, python-mode.el
>>> sends "python-mode".
>>> 
>>> Best,
>>> 
>>> Andreas
>>> 
>>> 
>> 
>> --
>> 
>> Thanks,
>> 
>> --Raman(I Search, I Find, I Misplace, I Research)
>> 7©3 Id: kg:/m/0285kf1  •0Ü8
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: python minor-mode

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]

Hi TV, good to hear from you too.  Hi also to Stefan and Andreas.

I agree it would be good to find a way to merge the functionality of the two modes, but of course it’s more than that because the variables and settings would also have to merge.  It would be a huge bit of work, and definitely not something that I would have any bandwidth for.  python-mode.el’s been around for 30 years now, almost as long as Python itself.  It’s sad that these two modes have existed independently for so long.

Cheers,
-Barry

> On Mar 21, 2022, at 09:09, T.V Raman <raman@google.com> wrote:
> 
> Barry Warsaw <barry@python.org> writes:
> 
> 
> Hi Barry,
> 
> Good to hear from you after a long time.
> 
> I recall that at one time, there was a similar split between emacs'
> built-in C-mode vs the much-enhanced cc-mode  that you and others had
> developed; eventually cc-mode and its goodness landed in Emacs.I'm
> optimistically hoping for the same for Python:-)
> 
> 
> I'm sure there are still differences between python.el and
> python-mode.el though in the last 10 years or so, python.el has grown
> significantly in size.
> 
> I mostly use elpy to pull together all the various emacs/python goodies
> and after getting very confused between python.el and python-mode.el
> eventually uninstalled python-mode.el so that I could avoid getting
> tripped up; for better or worse, I've not noticed too much difference
> and it's actually nice to have one less thing to worry about when being
> surprized by some unexpected behavior.
> 
> With respect to code formatting etc, I now achieve that via external
> tools like yapf that elpy wrappers, and have the formatting operation
> happen on each save.
> 
> 
>> I haven’t looked at python.el in a long while but last time I did, it was not PEP 8 compliant.
>> 
>> -Barry
>> 
>>> On Mar 21, 2022, at 06:37, T.V Raman <raman@google.com> wrote:
>>> 
>>> Andreas Röhler <andreas.roehler@online.de> writes:
>>> 
>>> 
>>> The bigger question:
>>> 
>>> There were clearly reasons for the existence of these two in the past
>>> --- python.el and python-mode.el -- do those reasons still exist. They
>>> each have almost similar functionality -- and it may be worthwhile for
>>> some wise heads to come together and create a single, consolidated
>>> python package for emacs.
>>> 
>>> I can vouch from my own use that this split causes massive confusion.
>>> 
>>>> Hi,
>>>> 
>>>> Currently, both python.el and python-mode.el define a minor-mode
>>>> called "python-mode". Which may create some confusion. Wouldn't it be
>>>> more natural if both files provide modes according to their filename?
>>>> I.e. python.el should establish "python" as minor-mode, python-mode.el
>>>> sends "python-mode".
>>>> 
>>>> Best,
>>>> 
>>>> Andreas
>>>> 
>>>> 
>>> 
>>> --
>>> 
>>> Thanks,
>>> 
>>> --Raman(I Search, I Find, I Misplace, I Research)
>>> ♇ Id: kg:/m/0285kf1  🦮
>> 
> 
> --
> 
> Thanks,
> 
> --Raman(I Search, I Find, I Misplace, I Research)
> ♈ Id: kg:/m/0285kf1  🦮


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: python minor-mode

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 4242 bytes --]

Barry Warsaw <barry@python.org> writes:


Agreed on all counts Barry!

The straw that broke my python-mode-camel's back was when I ran into
unexplainable bugs that I couldn't explain to myself because of lack of
documentation in the melpa install of python-mode, and gitlab's
insistence that I needed a gitlab account before I could even checkout
the code; at that point I just moved on. Now both of these assertions
could be a consequnce of my not having looked hard enough, and perhaps
if one visits Gitlab with an all-dancing JS-powered browser it might be
a different experience ... 

With Github I've developed workflows where I entirely avoid the need to
use a JS-powered browser and perhaps the same is possible with gitlab if
one makes the investment ... but again, it was sufficiently hard to not
make it over the line given the now somewhat minor feature gaps between
python.el and python-mode.el.

> Hi TV, good to hear from you too.  Hi also to Stefan and Andreas.
>
> I agree it would be good to find a way to merge the functionality of
> the two modes, but of course it¡¯s more than that because the variables
> and settings would also have to merge.  It would be a huge bit of
> work, and definitely not something that I would have any bandwidth
> for.  python-mode.el¡¯s been around for 30 years now, almost as long as
> Python itself.  It¡¯s sad that these two modes have existed
> independently for so long.
>
> Cheers,
> -Barry
>
>> On Mar 21, 2022, at 09:09, T.V Raman <raman@google.com> wrote:
>> 
>> Barry Warsaw <barry@python.org> writes:
>> 
>> 
>> Hi Barry,
>> 
>> Good to hear from you after a long time.
>> 
>> I recall that at one time, there was a similar split between emacs'
>> built-in C-mode vs the much-enhanced cc-mode  that you and others had
>> developed; eventually cc-mode and its goodness landed in Emacs.I'm
>> optimistically hoping for the same for Python:-)
>> 
>> 
>> I'm sure there are still differences between python.el and
>> python-mode.el though in the last 10 years or so, python.el has grown
>> significantly in size.
>> 
>> I mostly use elpy to pull together all the various emacs/python goodies
>> and after getting very confused between python.el and python-mode.el
>> eventually uninstalled python-mode.el so that I could avoid getting
>> tripped up; for better or worse, I've not noticed too much difference
>> and it's actually nice to have one less thing to worry about when being
>> surprized by some unexpected behavior.
>> 
>> With respect to code formatting etc, I now achieve that via external
>> tools like yapf that elpy wrappers, and have the formatting operation
>> happen on each save.
>> 
>> 
>>> I haven¡¯t looked at python.el in a long while but last time I did, it was not PEP 8 compliant.
>>> 
>>> -Barry
>>> 
>>>> On Mar 21, 2022, at 06:37, T.V Raman <raman@google.com> wrote:
>>>> 
>>>> Andreas R0‹2hler <andreas.roehler@online.de> writes:
>>>> 
>>>> 
>>>> The bigger question:
>>>> 
>>>> There were clearly reasons for the existence of these two in the past
>>>> --- python.el and python-mode.el -- do those reasons still exist. They
>>>> each have almost similar functionality -- and it may be worthwhile for
>>>> some wise heads to come together and create a single, consolidated
>>>> python package for emacs.
>>>> 
>>>> I can vouch from my own use that this split causes massive confusion.
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Currently, both python.el and python-mode.el define a minor-mode
>>>>> called "python-mode". Which may create some confusion. Wouldn't it be
>>>>> more natural if both files provide modes according to their filename?
>>>>> I.e. python.el should establish "python" as minor-mode, python-mode.el
>>>>> sends "python-mode".
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Andreas
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> 
>>>> Thanks,
>>>> 
>>>> --Raman(I Search, I Find, I Misplace, I Research)
>>>> 7©2 Id: kg:/m/0285kf1  •0Ü8
>>> 
>> 
>> --
>> 
>> Thanks,
>> 
>> --Raman(I Search, I Find, I Misplace, I Research)
>> 7©3 Id: kg:/m/0285kf1  •0Ü8
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: python minor-mode

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 4865 bytes --]

I’m sorry that GitLab gave you so much trouble, TV.  It really shouldn’t have been that painful!  I use both GL and GH for various projects, but I tend to prefer GL.  That said, Andreas has been the real maintainer of python-mode.el for the last many years, so I support whatever he prefers to do.

I may give python.el another look and keep notes on where I find differences or frictions.

-Barry

> On Apr 1, 2022, at 06:55, T.V Raman <raman@google.com> wrote:
> 
> Barry Warsaw <barry@python.org> writes:
> 
> 
> Agreed on all counts Barry!
> 
> The straw that broke my python-mode-camel's back was when I ran into
> unexplainable bugs that I couldn't explain to myself because of lack of
> documentation in the melpa install of python-mode, and gitlab's
> insistence that I needed a gitlab account before I could even checkout
> the code; at that point I just moved on. Now both of these assertions
> could be a consequnce of my not having looked hard enough, and perhaps
> if one visits Gitlab with an all-dancing JS-powered browser it might be
> a different experience ...
> 
> With Github I've developed workflows where I entirely avoid the need to
> use a JS-powered browser and perhaps the same is possible with gitlab if
> one makes the investment ... but again, it was sufficiently hard to not
> make it over the line given the now somewhat minor feature gaps between
> python.el and python-mode.el.
> 
>> Hi TV, good to hear from you too.  Hi also to Stefan and Andreas.
>> 
>> I agree it would be good to find a way to merge the functionality of
>> the two modes, but of course it’s more than that because the variables
>> and settings would also have to merge.  It would be a huge bit of
>> work, and definitely not something that I would have any bandwidth
>> for.  python-mode.el’s been around for 30 years now, almost as long as
>> Python itself.  It’s sad that these two modes have existed
>> independently for so long.
>> 
>> Cheers,
>> -Barry
>> 
>>> On Mar 21, 2022, at 09:09, T.V Raman <raman@google.com> wrote:
>>> 
>>> Barry Warsaw <barry@python.org> writes:
>>> 
>>> 
>>> Hi Barry,
>>> 
>>> Good to hear from you after a long time.
>>> 
>>> I recall that at one time, there was a similar split between emacs'
>>> built-in C-mode vs the much-enhanced cc-mode  that you and others had
>>> developed; eventually cc-mode and its goodness landed in Emacs.I'm
>>> optimistically hoping for the same for Python:-)
>>> 
>>> 
>>> I'm sure there are still differences between python.el and
>>> python-mode.el though in the last 10 years or so, python.el has grown
>>> significantly in size.
>>> 
>>> I mostly use elpy to pull together all the various emacs/python goodies
>>> and after getting very confused between python.el and python-mode.el
>>> eventually uninstalled python-mode.el so that I could avoid getting
>>> tripped up; for better or worse, I've not noticed too much difference
>>> and it's actually nice to have one less thing to worry about when being
>>> surprized by some unexpected behavior.
>>> 
>>> With respect to code formatting etc, I now achieve that via external
>>> tools like yapf that elpy wrappers, and have the formatting operation
>>> happen on each save.
>>> 
>>> 
>>>> I haven’t looked at python.el in a long while but last time I did, it was not PEP 8 compliant.
>>>> 
>>>> -Barry
>>>> 
>>>>> On Mar 21, 2022, at 06:37, T.V Raman <raman@google.com> wrote:
>>>>> 
>>>>> Andreas Röhler <andreas.roehler@online.de> writes:
>>>>> 
>>>>> 
>>>>> The bigger question:
>>>>> 
>>>>> There were clearly reasons for the existence of these two in the past
>>>>> --- python.el and python-mode.el -- do those reasons still exist. They
>>>>> each have almost similar functionality -- and it may be worthwhile for
>>>>> some wise heads to come together and create a single, consolidated
>>>>> python package for emacs.
>>>>> 
>>>>> I can vouch from my own use that this split causes massive confusion.
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Currently, both python.el and python-mode.el define a minor-mode
>>>>>> called "python-mode". Which may create some confusion. Wouldn't it be
>>>>>> more natural if both files provide modes according to their filename?
>>>>>> I.e. python.el should establish "python" as minor-mode, python-mode.el
>>>>>> sends "python-mode".
>>>>>> 
>>>>>> Best,
>>>>>> 
>>>>>> Andreas
>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> --Raman(I Search, I Find, I Misplace, I Research)
>>>>> ♆ Id: kg:/m/0285kf1  🦮
>>>> 
>>> 
>>> --
>>> 
>>> Thanks,
>>> 
>>> --Raman(I Search, I Find, I Misplace, I Research)
>>> ♇ Id: kg:/m/0285kf1  🦮
>> 
> 
> --
> 
> Thanks,
> 
> --Raman(I Search, I Find, I Misplace, I Research)
> ♈ Id: kg:/m/0285kf1  🦮


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: python minor-mode

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 665 bytes --]

I wasn't asking for python-mode.el to move from GitLab; I just wish
Gitlab was easier to use. At one point Github was just as painful, but
between Magit and the gh commandline client from Github written in Go, I
almost never need use  a so-called mainstream browser any more -- am
sure Gitlab has an API at the same level; it must since Magit supports
it. But I'm also done with creating accounts on the Web which is why I
didn't go through the pain of creating a Gitlab account; especially that
would also have involved mouse-waving browser dances.


-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: python minor-mode

[Stefan Monnier]

Andreas Röhler [2022-03-21 09:19:29] wrote:
> Currently, both python.el and python-mode.el define a minor-mode called
> "python-mode".

Actually neither of them defines a minor mode.  But yes, they both
define a major mode with the same name.

> Which may create some confusion.

Yes, it's a sad situation.

> Wouldn't it be more natural if both files provide modes according to
> their filename? I.e. python.el should establish "python" as
> minor-mode, python-mode.el sends "python-mode".

As Eli explained, that's not really an option, not only because of the
"-mode" tradition, but also because they should be using distinction
prefixes for their code.

See, for example in the `perl-mode` vs `cperl-mode` or `latex-mode` va
AUCTeX's `LaTeX-mode`.

So one of those two major modes should change their prefix from
`python-` to something else.  Given the number of years they have
existed this seems rather unlikely to take place merrily.

Another option (arguably the best option, at least for the end users) is
to try and merge the two modes.  I.e. push patches from one to the other
so they can share as much code as possible, and when that can't be done
any more, define the leftover code as a new derived mode built on top of
the other.

I don't really know how the two compare in functionality, but based on
size, I'd guess that we'd end up with Emacs's python.el being the "core"
mode and `python-mode.el` being the "derived" mode that provides
extra features.  Depending on how things end up, the derived mode could
be replaced with a minor mode.

In any case, it's a non-trivial job which would require
someone to figure out all the details.


        Stefan

Re: python minor-mode

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]


Am 22.03.22 um 09:07 schrieb Stefan Monnier:
> [...]
> I don't really know how the two compare in functionality, but based on
> size, I'd guess that we'd end up with Emacs's python.el being the "core"
> mode and `python-mode.el` being the "derived" mode that provides
> extra features.  Depending on how things end up, the derived mode could
> be replaced with a minor mode.

An interesting idea, which may reduce the burden of maintenance on  both 
sides.

The point I'm afraid of: For example, if python-mode.el uses python.el's 
setup-code machinery, it might want to modify vars there.

Afterwards it will be not obvious, wherefrom values are set. For now 
there should be no conflict, beside of the name of the major-mode itself.

So, not sure if proceeding in that direction would make sense.

Best,

Andreas

> In any case, it's a non-trivial job which would require
> someone to figure out all the details.
>
>
>          Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 1587 bytes --]