unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Barry Warsaw <barry@python.org>
To: "T.V Raman" <raman@google.com>
Cc: "Andreas Röhler" <andreas.roehler@online.de>, emacs-devel@gnu.org
Subject: Re: python minor-mode
Date: Fri, 1 Apr 2022 11:09:32 -0700	[thread overview]
Message-ID: <6D3F63A7-DDA6-4ECC-BEA7-72F333307413@python.org> (raw)
In-Reply-To: <p91tubc7vrs.fsf@google.com>

[-- 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 --]

  reply	other threads:[~2022-04-01 18:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  8:19 python minor-mode Andreas Röhler
2022-03-21 12:35 ` Eli Zaretskii
2022-03-21 13:37 ` T.V Raman
2022-03-21 15:20   ` Barry Warsaw
2022-03-21 16:09     ` T.V Raman
2022-04-01  0:31       ` Barry Warsaw
2022-04-01 13:55         ` T.V Raman
2022-04-01 18:09           ` Barry Warsaw [this message]
2022-04-02  1:39             ` T.V Raman
2022-03-22  8:07 ` Stefan Monnier
2022-04-07  7:49   ` Andreas Röhler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6D3F63A7-DDA6-4ECC-BEA7-72F333307413@python.org \
    --to=barry@python.org \
    --cc=andreas.roehler@online.de \
    --cc=emacs-devel@gnu.org \
    --cc=raman@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).