unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* python minor-mode
@ 2022-03-21  8:19 Andreas Röhler
  2022-03-21 12:35 ` Eli Zaretskii
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Andreas Röhler @ 2022-03-21  8:19 UTC (permalink / raw)
  To: emacs-devel; +Cc: Barry Warsaw

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




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  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-22  8:07 ` Stefan Monnier
  2 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2022-03-21 12:35 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: barry, emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  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-22  8:07 ` Stefan Monnier
  2 siblings, 1 reply; 11+ messages in thread
From: T.V Raman @ 2022-03-21 13:37 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: emacs-devel, Barry Warsaw

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  2022-03-21 13:37 ` T.V Raman
@ 2022-03-21 15:20   ` Barry Warsaw
  2022-03-21 16:09     ` T.V Raman
  0 siblings, 1 reply; 11+ messages in thread
From: Barry Warsaw @ 2022-03-21 15:20 UTC (permalink / raw)
  To: T.V Raman; +Cc: Andreas Röhler, emacs-devel

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  2022-03-21 15:20   ` Barry Warsaw
@ 2022-03-21 16:09     ` T.V Raman
  2022-04-01  0:31       ` Barry Warsaw
  0 siblings, 1 reply; 11+ messages in thread
From: T.V Raman @ 2022-03-21 16:09 UTC (permalink / raw)
  To: Barry Warsaw; +Cc: Andreas Röhler, emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  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-22  8:07 ` Stefan Monnier
  2022-04-07  7:49   ` Andreas Röhler
  2 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2022-03-22  8:07 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: emacs-devel, Barry Warsaw

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




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  2022-03-21 16:09     ` T.V Raman
@ 2022-04-01  0:31       ` Barry Warsaw
  2022-04-01 13:55         ` T.V Raman
  0 siblings, 1 reply; 11+ messages in thread
From: Barry Warsaw @ 2022-04-01  0:31 UTC (permalink / raw)
  To: T.V Raman; +Cc: Andreas Röhler, emacs-devel

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  2022-04-01  0:31       ` Barry Warsaw
@ 2022-04-01 13:55         ` T.V Raman
  2022-04-01 18:09           ` Barry Warsaw
  0 siblings, 1 reply; 11+ messages in thread
From: T.V Raman @ 2022-04-01 13:55 UTC (permalink / raw)
  To: Barry Warsaw; +Cc: Andreas Röhler, emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  2022-04-01 13:55         ` T.V Raman
@ 2022-04-01 18:09           ` Barry Warsaw
  2022-04-02  1:39             ` T.V Raman
  0 siblings, 1 reply; 11+ messages in thread
From: Barry Warsaw @ 2022-04-01 18:09 UTC (permalink / raw)
  To: T.V Raman; +Cc: Andreas Röhler, emacs-devel

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  2022-04-01 18:09           ` Barry Warsaw
@ 2022-04-02  1:39             ` T.V Raman
  0 siblings, 0 replies; 11+ messages in thread
From: T.V Raman @ 2022-04-02  1:39 UTC (permalink / raw)
  To: Barry Warsaw; +Cc: Andreas Röhler, emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: python minor-mode
  2022-03-22  8:07 ` Stefan Monnier
@ 2022-04-07  7:49   ` Andreas Röhler
  0 siblings, 0 replies; 11+ messages in thread
From: Andreas Röhler @ 2022-04-07  7:49 UTC (permalink / raw)
  To: emacs-devel; +Cc: Barry Warsaw, Eli Zaretskii, Stefan Monnier

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2022-04-07  7:49 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2022-04-02  1:39             ` T.V Raman
2022-03-22  8:07 ` Stefan Monnier
2022-04-07  7:49   ` Andreas Röhler

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