window selection behavior of py-execute-buffer switches focus and does not reuse existing shell buffer if any

Bug #1478122 reported by deuscovrigus@gmail.com
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-mode.el
Fix Committed
Medium
Andreas Roehler

Bug Description

Using the window setup is C-x 2 <RET> C-x 3 <RET>
When i execute python from the top left window , a shell is popped on my top right window, but the focus of my buffer switches to the next window for no reason. I guess this wasn't intended?

Additionally, if the python buffer is present in any of the current windows,(see init_setup_python_shell_visible.png) instead of just re-using that window, executing python will replace an additional window. And, as before, the buffer focus changes to the next window. (see additional_window_is_replaced_instead_of_reusing_bottom_window.png).

Seems to me that the current implementation just picks the window obtained by C-x o (other-window-or-frame) without checking to see whether the python shell is in any of the windows. After that, the current buffer focus is switched to the window obtained by C-u 2 C-x o (i.e., two windows ahead of the window python was executed from).

Again, thanks for looking into this, and , if it's not too much to ask, can the default placement of the chosen window for the shell be like the widest window available?,i.e. the bottom window of my 3-window setup (this would mimic a console-like environment which I'm sure users will like)

Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote :
Revision history for this message
Andreas Roehler (a-roehler) wrote :

Please send attachments again as plain png.

Changed in python-mode:
assignee: nobody → Andreas Roehler (a-roehler)
status: New → Incomplete
importance: Undecided → Medium
Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote : Re: [Bug 1478122] Re: window selection behavior of py-execute-buffer switches focus and does not reuse existing shell buffer if any

I am replying here as I dont think I can attach multiple images without
using multiple comments

On Fri, Jul 24, 2015 at 3:50 PM, Andreas Roehler <email address hidden>
wrote:

> Please send attachments again as plain png.
>
> ** Changed in: python-mode
> Assignee: (unassigned) => Andreas Roehler (a-roehler)
>
> ** Changed in: python-mode
> Status: New => Incomplete
>
> ** Changed in: python-mode
> Importance: Undecided => Medium
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1478122
>
> Title:
> window selection behavior of py-execute-buffer switches focus and does
> not reuse existing shell buffer if any
>
> Status in python-mode.el:
> Incomplete
>
> Bug description:
> Using the window setup is C-x 2 <RET> C-x 3 <RET>
> When i execute python from the top left window , a shell is popped on my
> top right window, but the focus of my buffer switches to the next window
> for no reason. I guess this wasn't intended?
>
> Additionally, if the python buffer is present in any of the current
> windows,(see init_setup_python_shell_visible.png) instead of just re-
> using that window, executing python will replace an additional
> window. And, as before, the buffer focus changes to the next window.
> (see
> additional_window_is_replaced_instead_of_reusing_bottom_window.png).
>
> Seems to me that the current implementation just picks the window
> obtained by C-x o (other-window-or-frame) without checking to see
> whether the python shell is in any of the windows. After that, the
> current buffer focus is switched to the window obtained by C-u 2 C-x o
> (i.e., two windows ahead of the window python was executed from).
>
> Again, thanks for looking into this, and , if it's not too much to
> ask, can the default placement of the chosen window for the shell be
> like the widest window available?,i.e. the bottom window of my
> 3-window setup (this would mimic a console-like environment which I'm
> sure users will like)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/python-mode/+bug/1478122/+subscriptions
>

Revision history for this message
Andreas Roehler (a-roehler) wrote :

Am 24.07.2015 um 23:00 schrieb <email address hidden>:
> I am replying here as I dont think I can attach multiple images without
> using multiple comments

Please proceed as with #33
<https://bugs.launchpad.net/python-mode/+bug/1361535/comments/33> of
https://bugs.launchpad.net/python-mode/+bug/1361535

Revision history for this message
Andreas Roehler (a-roehler) wrote :

Okay, see it. Just to understand your workflow: would setting py-keep-windows-configuration to t solve it for you?

Changed in python-mode:
status: Incomplete → Confirmed
Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote :

py-keep-window-configuration t implies that I have to manually bring the ipython buffer to one of the windows when I execute a script for the first time or after the ipython buffer is killed. While I have been using it like this for a while, I would like the python shell buffer to re-use the bottom window if it's not visible, without switching the window focus of the script that I execute. For this purpose py-keep-windows configuration is set to nil.

While the splitting behavior was fixed by your commit for +bug/1361535, the window selection process seems bugged, according to the description of this bug.
My desire to select the bottom window when executing a script is more of a pull request rather than a bug.
However, the unexpected behavior reported in this bug is that the current window focus changes after executing a script and the fact that an additional window is replaced by the python shell if said shell is already visible in another window. Can you reproduce this according to the screenshots?

Revision history for this message
Andreas Roehler (a-roehler) wrote :

Am 27.07.2015 um 15:26 schrieb <email address hidden>:
> py-keep-window-configuration t implies that I have to manually bring the
> ipython buffer to one of the windows when I execute a script for the
> first time or after the ipython buffer is killed. While I have been
> using it like this for a while, I would like the python shell buffer to
> re-use the bottom window if it's not visible, without switching the
> window focus of the script that I execute. For this purpose py-keep-
> windows configuration is set to nil.
>
> While the splitting behavior was fixed by your commit for +bug/1361535, the window selection process seems bugged, according to the description of this bug.
> My desire to select the bottom window when executing a script is more of a pull request rather than a bug.
> However, the unexpected behavior reported in this bug is that the current window focus changes after executing a script and the fact that an additional window is replaced by the python shell if said shell is already visible in another window. Can you reproduce this according to the screenshots?
>

Yes, the bug is confirmed. Thanks reporting BTW.

Revision history for this message
Andreas Roehler (a-roehler) wrote :

Made some changes, please try again.

Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote :

Ok I merged to your commit. Right now the focus of the buffer does not change so that's good.
However, if the python shell is not visible in any of the windows or doesn't exist, it will stay hidden/ in the background instead of being brought forward to the bottom window (or any). So again, I have to manually bring it up.
Can you confirm? Preferably the shell buffer should take the location of the bottom window, if it's not visible or doesn't exist yet.
If the shell is visible in any of the windows it should re-use that window
I did double check and py-keep-window-configuration is nil and py-split-window-on-execute is t.

Revision history for this message
Andreas Roehler (a-roehler) wrote :

Am 27.07.2015 um 19:12 schrieb <email address hidden>:
> Ok I merged to your commit. Right now the focus of the buffer does not change so that's good.
> However, if the python shell is not visible in any of the windows or doesn't exist, it will stay hidden/ in the background instead of being brought forward to the bottom window (or any). So again, I have to manually bring it up.
> Can you confirm?

Expect that from implementation.

> Preferably the shell buffer should take the location of the bottom window, if it's not visible or doesn't exist yet.

Sounds reasonable.

> If the shell is visible in any of the windows it should re-use that window
> I did double check and py-keep-window-configuration is nil and py-split-window-on-execute is t.
>

Will look for ASAP.

Revision history for this message
Andreas Roehler (a-roehler) wrote :

For the moment, when starting a session, provide the wished layout first. Then

M-x window-configuration-to-register ...

That stores wished window-configuration, so you can restore it later at any time.

When closing Emacs, use desktop-save.

Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote :

So far I have a method too of dealing with this bug. Looking forward to your commit.
Thanks!

Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote :

so far my temporary solution that has the correct window-selection behavior is by keeping py-keep-windows-configuration t and running this function:

(defun run-ipython ()
  "Use compile to run python programs"
  (interactive)
  (py-execute-buffer)
  (display-buffer "*IPython*" t)
)

essentially, display buffer will re-use a window if Ipython shell is present in it, OR bring it forward into one of the windows if Ipython is not visible, without chaning the focus of the buffer where run-ipython is run.

I think this should be the desireable behavior of py-execute-buffer. Obviously this is a hack since here display-buffer looks for the IPython buffer but so far it's good as a temporary kludge.

Revision history for this message
Andreas Roehler (a-roehler) wrote :

Am 30.07.2015 um 19:45 schrieb <email address hidden>:
> so far my temporary solution that has the correct window-selection
> behavior is by keeping py-keep-windows-configuration t and running this
> function:
>
> (defun run-ipython ()
> "Use compile to run python programs"
> (interactive)
> (py-execute-buffer)
> (display-buffer "*IPython*" t)
> )
>
> essentially, display buffer will re-use a window if Ipython shell is
> present in it, OR bring it forward into one of the windows if Ipython
> is not visible, without chaning the focus of the buffer where run-
> ipython is run.
>
> I think this should be the desireable behavior of py-execute-buffer.
> Obviously this is a hack since here display-buffer looks for the IPython
> buffer but so far it's good as a temporary kludge.
>

Is the option `t' correct WRT display-buffer?

Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote :

the option t is necessary in order to display the buffer in a window that is different from the one where display-buffer is called from.
Not providing it will replace the current focused window with the IPython buffer.

Revision history for this message
Andreas Roehler (a-roehler) wrote :

Am 30.07.2015 um 21:15 schrieb <email address hidden>:
> the option t is necessary in order to display the buffer in a window that is different from the one where display-buffer is called from.
> Not providing it will replace the current focused window with the IPython buffer.
>

See it now, thanks, it's mentioned at the end of display-buffer's docu.
Will try this when back at py--shell-manage-windows again.

Revision history for this message
Andreas Roehler (a-roehler) wrote :

Please try again.

Changed in python-mode:
status: Confirmed → Incomplete
Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote :

Looks good on my mac! Will try on my linux machine today! Thanks a lot!

Revision history for this message
deuscovrigus@gmail.com (deuscovrigus) wrote :

Works great on my linux end too! Sweet.

Changed in python-mode:
status: Incomplete → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.