GNU bug report logs - #56997
[PATCH] Analogue of project-shell for Python

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56997 in the body.
You can then email your comments to 56997 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: [PATCH] Analogue of project-shell for Python
Date: Fri, 05 Aug 2022 09:31:02 +0200

[Message part 1 (text/plain, inline)]

The Python shell already allows a shell to be "dedicated" to a buffer.
This patch adds the option to create a shell dedicated to a project, as
well as the option to make all Python shells dedicated by default.

Stefan: you mentioned python.el could use project.el without a hard
dependency, so it remains compatible with old Emacsen.  Is this a good
approach?  (Also: the added seq dependency is kinda superfluous now, but
it's nice to have it available for future developments as well.)

Philip: I'm working around the possible absence of
'read-multiple-choice' here.  Not sure it's a popular/useful enough
function to include in compat, but I thought I would bring this up.

[0001-Python-shells-dedicated-to-a-project.patch (text/x-patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [PATCH] Analogue of project-shell for Python
Date: Fri, 05 Aug 2022 09:22:21 +0000

Augusto Stoffel <arstoffel <at> gmail.com> writes:

> Philip: I'm working around the possible absence of
> 'read-multiple-choice' here.  Not sure it's a popular/useful enough
> function to include in compat, but I thought I would bring this up.

I have considered it, but the code in rmc.el is about 230 lines of code,
that I didn't want to copy verbatim.  If you think it is worthwhile, I
can try to add `read-multiple-choice' in some form or another.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: bug-gnu-emacs <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [PATCH] Analogue of project-shell for Python
Date: Fri, 05 Aug 2022 11:52:55 +0200

On Fri,  5 Aug 2022 at 09:22, Philip Kaludercic <philipk <at> posteo.net> wrote:

> Augusto Stoffel <arstoffel <at> gmail.com> writes:
>
>> Philip: I'm working around the possible absence of
>> 'read-multiple-choice' here.  Not sure it's a popular/useful enough
>> function to include in compat, but I thought I would bring this up.
>
> I have considered it, but the code in rmc.el is about 230 lines of code,
> that I didn't want to copy verbatim.  If you think it is worthwhile, I
> can try to add `read-multiple-choice' in some form or another.

A bare-bones version that ignores the optional arguments could be much
smaller, but I think it's at best borderline worth implementing it.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [PATCH] Analogue of project-shell for Python
Date: Fri, 05 Aug 2022 11:00:28 +0000

Augusto Stoffel <arstoffel <at> gmail.com> writes:

> On Fri,  5 Aug 2022 at 09:22, Philip Kaludercic <philipk <at> posteo.net> wrote:
>
>> Augusto Stoffel <arstoffel <at> gmail.com> writes:
>>
>>> Philip: I'm working around the possible absence of
>>> 'read-multiple-choice' here.  Not sure it's a popular/useful enough
>>> function to include in compat, but I thought I would bring this up.
>>
>> I have considered it, but the code in rmc.el is about 230 lines of code,
>> that I didn't want to copy verbatim.  If you think it is worthwhile, I
>> can try to add `read-multiple-choice' in some form or another.
>
> A bare-bones version that ignores the optional arguments could be much
> smaller, but I think it's at best borderline worth implementing it.

Would this be enough: https://git.sr.ht/~pkal/compat/commit/1250ea050737db8ba07c44eaeab7be2e4faefe0a?

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: bug-gnu-emacs <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [PATCH] Analogue of project-shell for Python
Date: Fri, 05 Aug 2022 13:43:20 +0200

On Fri,  5 Aug 2022 at 11:00, Philip Kaludercic <philipk <at> posteo.net> wrote:

> Would this be enough: https://git.sr.ht/~pkal/compat/commit/1250ea050737db8ba07c44eaeab7be2e4faefe0a?

Definitely!

Message #22 received at 56997 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 56997 <at> debbugs.gnu.org
Subject: Re: bug#56997: [PATCH] Analogue of project-shell for Python
Date: Tue, 23 Aug 2022 12:40:30 -0400

> The Python shell already allows a shell to be "dedicated" to a buffer.
> This patch adds the option to create a shell dedicated to a project, as
> well as the option to make all Python shells dedicated by default.
>
> Stefan: you mentioned python.el could use project.el without a hard
> dependency, so it remains compatible with old Emacsen.  Is this a good
> approach?  (Also: the added seq dependency is kinda superfluous now, but
> it's nice to have it available for future developments as well.)

I must admit that I don't really know how important is the ability to
install python.el in older Emacsen.  I know the maintainers of python.el
want it to be possible, but that doesn't preclude depending on `seq.el`
and `project.el` since those are also available on GNU ELPA.  But it
does make it less convenient for the end user, so whether that matters
depends on its importance.

I suggested a "soft" dependency as a possible choice, without implying
it's necessarily better or worse, sorry :-(

But, FWIW the patch looks good to me.

> -;; Package-Requires: ((emacs "24.4") (cl-lib "1.0"))

BTW, Emacs-24.3 already provides cl-lib-1.0 so we can drop `cl-lib` from
this line.


        Stefan

Message #25 received at 56997 <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 56997 <at> debbugs.gnu.org
Subject: Re: bug#56997: [PATCH] Analogue of project-shell for Python
Date: Wed, 24 Aug 2022 18:55:33 +0200

[Message part 1 (text/plain, inline)]

On Tue, 23 Aug 2022 at 12:40, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

>
>> The Python shell already allows a shell to be "dedicated" to a buffer.
>> This patch adds the option to create a shell dedicated to a project, as
>> well as the option to make all Python shells dedicated by default.
>>
>> Stefan: you mentioned python.el could use project.el without a hard
>> dependency, so it remains compatible with old Emacsen.  Is this a good
>> approach?  (Also: the added seq dependency is kinda superfluous now, but
>> it's nice to have it available for future developments as well.)
>
> I must admit that I don't really know how important is the ability to
> install python.el in older Emacsen.  I know the maintainers of python.el
> want it to be possible, but that doesn't preclude depending on `seq.el`
> and `project.el` since those are also available on GNU ELPA.  But it
> does make it less convenient for the end user, so whether that matters
> depends on its importance.

I see the point of remaining compatible going back one or two versions,
not so much with even older versions; it's not like a Python major mode
is unavailable in Emacs 24 and 25.

> I suggested a "soft" dependency as a possible choice, without implying
> it's necessarily better or worse, sorry :-(

In any case I don't see any other practical way to proceed...

> But, FWIW the patch looks good to me.
>
>> -;; Package-Requires: ((emacs "24.4") (cl-lib "1.0"))
>
> BTW, Emacs-24.3 already provides cl-lib-1.0 so we can drop `cl-lib` from
> this line.
>
>
>         Stefan

I've attached a new patch with a requirement on compat, so we can use
read-multiple-choice unconditionally (I also removed the unnecessary
cl-lib from the Package-Requires header).

[0001-Python-shells-dedicated-to-a-project.patch (text/x-patch, attachment)]

Message #28 received at 56997 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 56997 <at> debbugs.gnu.org
Subject: Re: bug#56997: [PATCH] Analogue of project-shell for Python
Date: Sun, 04 Sep 2022 13:14:12 +0200

Augusto Stoffel <arstoffel <at> gmail.com> writes:

> I've attached a new patch with a requirement on compat, so we can use
> read-multiple-choice unconditionally (I also removed the unnecessary
> cl-lib from the Package-Requires header).

Thanks; now pushed to Emacs 29.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.