py-switch-buffers-on-execute-p is broken. It uses/kills other buffers.

Re-wrote some parts. Please try again.

This does not have the desired effect.
What happens is that when I add

(setq py-switch-buffers-on-execute-p t)

to the init.el, then not even the initial splitting of windows takes place upon the Python interpreter with C-c ! and moreover, when I open the Python shell buffer manually, then issuing C-c | commands will *not* jump the cursor into the Python shell buffer.

The python-mode.el has py-version 6.1.4

Conflicts may occur between settings by defcustom and setq.

In order to check if it's a python-mode bug, please remove these setq from your init, use M-x customize-variable RET or menu Python/.../Switches instead.

Thanks,

Andreas

Ok. Did that, but for me, there is no change. My initial init.el had boiled down to

;; load path of most recent python-mode.el from bzr branch lp:python-mode
(add-to-list 'load-path "~/temporary/py/python-mode/")
(require 'python-mode)
(add-to-list 'auto-mode-alist '("\\.py$" . python-mode))

Then - I hopefully understood you correctly - I first checked the value of
py-split-windows-on-execute-p -> was 't' by default
py-switch-buffers-on-execute-p -> was 'nil' by default

Therefore I used M-x customize-variable RET to set py-switch-buffers-on-execute-p to 't', which leads to this usual section in the init.el:
(custom-set-variables '(py-switch-buffers-on-execute-p t))

The behavior remains exactly the same as described before - no change.

(py-version = 6.1.4, revno=1663, emacs = 24.3.1)

Please re-open if not done.

For me, the latest commit does not fix this bug, instead it introduces a new one.

Now, using the init.el described in the initial post, and following the procedure described there, the first call to execute some python code, issuing C-c | , will now kill *all* windows opened, except for the window containing the python file and that containing the python shell

Currently I am using:
C-h v py-version returns 6.1.4
bzr log -l 1 returns revno: 1678
C-h v emacs-version returns 24.3.1

On 20.09.2014 11:15, Zeitlinie wrote:
> For me, the latest commit does not fix this bug, instead it introduces a
> new one.
>
> Now, using the init.el described in the initial post, and following the
> procedure described there, the first call to execute some python code,
> issuing C-c | , will now kill *all* windows opened, except for the
> window containing the python file and that containing the python shell
>
> Currently I am using:
> C-h v py-version returns 6.1.4
> bzr log -l 1 returns revno: 1678
> C-h v emacs-version returns 24.3.1
>

Thanks reporting.

For the moment probably best is to set all three related variables to nil and split the windows manually.

Will fix it ASAP.

Andreas

Well I am at branch 1868 of 6.2.1 and invoking ipython will still kill other buffers allowing just two to exist. py-split-window-on-execute doesn't really work as it reuses and existing window AND splits the current buffer window. So far, as indicated, i use py-keep-windows-configuration t

Isn't there a way to bring the behaviour from 6.1.1? That had perfect window splitting in my experience. Like a common setup that I have is

---------- |-----------
              |

|-------------|-----------|
| | |
| | |
|-------------------------|
| |
| |
|-------------------------|

Right now, with py-splot-window-on execute is just-two , executing a buffer in the top-left window will kill the top right window.
If py-split-window-on execute is set to t, it will split the top left vertically as such:

|-------------|-----------|
| ----------- | |
| | |
|-------------------------|
| |
| |
|-------------------------|
The py-shell buffer will be now both on the bottom wide window and on the newly split window in the top left.

Any chance we can fix this?

Description doesn't make sense for me. Reading:

Right now, with py-splot-window-on execute is just-two , executing a buffer in the top-left window will kill the top right window.

With 'just-two, there is no top-left, there is either top/down or left and right.

So I'll try to be more explicit, this time attaching png screenshots.
Just-two simply kills all windows leaving only one window split vertically OR horizontally, depending on whether the user called C-x 2 or C-x 3 first. That's what I meant by the statement "With 'just-two, there is no top-left, there is either top/down ( equivalent of C-x 2) OR left /right (equivalent of C-x 3)

Now what bothers me is that the t option won't keep the setup obtained by starting with one window and typing :
C-x 2 <RET> C-x 3 <RET>, i.e., see attachment init_setup.png
Executing python once from the top left window will produce the setup shown in after_executing_buffer_t.png.

Two behaviours follow on subsequent execution:
a) ipython buffer is visible in one of the windows: execution happens normally.

b) if the ipython buffer is killed or is not visible in the other windows, the split happens again , as show in after_killing_ipython_and_executing_again.png

So the t option really doesn't like re-using existing buffers.

Let me know is this is explained more clearly.

Thanks going on. Please attach the png -iles as plain png again - no interest in opening zips :)

I think launchpad allowed only one attachment per comment, hence the zips.
Here's the actual contents.

On Wed, Jul 22, 2015 at 2:26 PM, Andreas Roehler <email address hidden>
wrote:

> Thanks going on. Please attach the png -iles as plain png again - no
> interest in opening zips :)
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1472620).
> https://bugs.launchpad.net/bugs/1361535
>
> Title:
> py-switch-buffers-on-execute-p is broken. It uses/kills other buffers.
>
> Status in python-mode.el:
> Incomplete
>
> Bug description:
> According to documentation, when non-nil py-switch-buffers-on-
> execute-p should switch to the Python output buffer.
>
> In practice the switching does *not* occur into the Python output
> buffer already open, but into any *other* buffer currently opened.
> This implies, that with several windows on the emacs pane opened each
> C-c | command issued will 'eat up' one more window and exchange its
> buffers content with the Python shell until emacs's pane is completely
> fill with many Python shells and a single Python code buffer.
>
> This behavior can be reproduced with the following simple init.el file
>
> ;; load path of most recent python-mode.el from bzr branch lp:python-mode
> (add-to-list 'load-path "~/temporary/py/python-mode/")
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-windows-on-execute-p t)
> (setq py-switch-buffers-on-execute-p t)
>
> Once the situation has been reached that emacs's pane is filled with
> many Python shells and a single Python code buffer, issuing the
> command C-c | still leads to a permanent interchange of buffers with
> the Python code file 'wandering' around on emacs's pane.
>
> In the simplest case with only one Python shell and one code buffer
> displayed, there will be a permanent exchange of the buffers location
> on the screen will issuing the command C-c |
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/python-mode/+bug/1361535/+subscriptions
>

Also please note that in "after_killing_ipython_and_executing_again.png", the top-right Window AND the vertically, split top left window contain the IPython buffer.
It seems that one window was reused (top right) but for some reason the top left was split once again

Py-shell is reused here - see attached reuse-py-shell-window.png

To provide an example please start from emacs -Q and python-mode.el

Maybe send a test which triggers the bug.

See at py-ert-split-window-on-execute-1361535-test in test/py-ert-tests-2.el for an example

I tried with emacs -Q and loading just python-mode. As long as the ipython buffer is not visible in any of the windows, the splitting behavior will keep splitting windows. In your example it seems that the Python3 buffer is visible. So it seems to me that this splitting behavior attempts only to re-use existing windows that contain the current python shell. if none are visible, a window is split (instead of reusing one in the current frame OR bring the shell buffer in any of the current windows).

Attached I have a screenshot, assuming the same setup as init_setup.png, just this time with nothing else loaded

About the tests: I tweaked python-mode-ert-tests-2.sh to work on my system and this is the command I adjusted to load the py-split-window-on-execute-lp-136153-test.el

$EMACS -Q --batch --eval "(message (emacs-version))" --eval "(when (featurep 'python)(unload-feature 'python t))" --eval "(when (featurep 'python-mode)(unload-feature 'python-mode t))" --eval "(add-to-list 'load-path \"$PDIR/\")" --eval "(add-to-list 'load-path \"$TESTDIR/\")" --eval "(setq py-install-directory \"$PDIR\"))" --eval "(message \"py-install-directory: %s\" py-install-directory)" --eval "(setq py-load-pymacs-p nil)" -load $BYTECOMP -load $CC_CMDS -load $COMINT -load $ANSICOLOR -load $CLMACS -load $CUSTOM -load $SKELETON -load $SO -load $COLMK -load $HIGHL -load $PYTHONMODE --eval "(message \"py-temp-directory: %s\" py-temp-directory)" -l py-split-window-on-execute-lp-1361531-test.el -f ert-run-tests-batch-and-exit

Is this how you evaluate the tests in the .el files?

this was the result:
$EMACS_DIR: /usr/share/emacs/24.3
$EMACS: emacs
$CC_CMDS: /usr/share/emacs/24.3/lisp/progmodes/cc-cmds.elc
GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7)
 of 2014-03-07 on lamiak, modified by Debian
py-install-directory: /home/octi/.emacs.d/plugins/python-mode-6.2.1
Warning: no abbrev-file found, customize `abbrev-file-name' in order to make mode-specific abbrevs work.
py-temp-directory: /tmp
Running 0 tests (2015-07-23 11:35:29-0400)

Ran 0 tests, 0 results as expected (2015-07-23 11:35:29-0400)

Am 23.07.2015 um 17:45 schrieb <email address hidden>:
> I tried with emacs -Q and loading just python-mode. As long as the
> ipython buffer is not visible in any of the windows, the splitting
> behavior will keep splitting windows. In your example it seems that the
> Python3 buffer is visible.

You mean _was_ visible? No, see inside the test-instruction.

> So it seems to me that this splitting
> behavior attempts only to re-use existing windows that contain the
> current python shell. if none are visible, a window is split (instead of
> reusing one in the current frame OR bring the shell buffer in any of the
> current windows).
>
> Attached I have a screenshot, assuming the same setup as init_setup.png,
> just this time with nothing else loaded
>
>
> About the tests: I tweaked python-mode-ert-tests-2.sh to work on my system and this is the command I adjusted to load the py-split-window-on-execute-lp-136153-test.el
>
> $EMACS -Q --batch --eval "(message (emacs-version))" --eval "(when
> (featurep 'python)(unload-feature 'python t))" --eval "(when (featurep
> 'python-mode)(unload-feature 'python-mode t))" --eval "(add-to-list
> 'load-path \"$PDIR/\")" --eval "(add-to-list 'load-path \"$TESTDIR/\")"
> --eval "(setq py-install-directory \"$PDIR\"))" --eval "(message \"py-
> install-directory: %s\" py-install-directory)" --eval "(setq py-load-
> pymacs-p nil)" -load $BYTECOMP -load $CC_CMDS -load $COMINT -load
> $ANSICOLOR -load $CLMACS -load $CUSTOM -load $SKELETON -load $SO -load
> $COLMK -load $HIGHL -load $PYTHONMODE --eval "(message \"py-temp-
> directory: %s\" py-temp-directory)" -l py-split-window-on-execute-
> lp-1361531-test.el -f ert-run-tests-batch-and-exit
>
> Is this how you evaluate the tests in the .el files?
>
> this was the result:
> $EMACS_DIR: /usr/share/emacs/24.3
> $EMACS: emacs
> $CC_CMDS: /usr/share/emacs/24.3/lisp/progmodes/cc-cmds.elc
> GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7)
> of 2014-03-07 on lamiak, modified by Debian
> py-install-directory: /home/octi/.emacs.d/plugins/python-mode-6.2.1
> Warning: no abbrev-file found, customize `abbrev-file-name' in order to make mode-specific abbrevs work.
> py-temp-directory: /tmp
> Running 0 tests (2015-07-23 11:35:29-0400)
>
> Ran 0 tests, 0 results as expected (2015-07-23 11:35:29-0400)
>
>
> ** Attachment added: "executing_python_once_splits_current_window_instead_of_using_bottom_window.png"
> https://bugs.launchpad.net/python-mode/+bug/1361535/+attachment/4433143/+files/executing_python_once_splits_current_window_instead_of_using_bottom_window.png
>

Do not use batch-mode for a single test. Batch-mode has some quirks and
bugs.

py-ert-split-window-on-execute-1361535-test is in
test/py-ert-interactive-tests.el now for this reason.

All needed beside python-mode.el is

test/setup-ert-tests.el

and the file, which contains the test.

Run the test M-x ert TESTNAME RET

Am 23.07.2015 um 17:45 schrieb <email address hidden>:
> [ ... ] if none are visible, a window is split (instead of
> reusing one in the current frame OR bring the shell buffer in any of the
> current windows).

If some of the displayed windows should be replaced by the now re-used,
how to determine which one?

I would use the same behavior at M-x compile in determining the window in which to put the compilation buffer. I know it 6.1.1 of python-mode the existing windows would be reused properly when the python shell buffer was not visible in any of the windows. Right now, afais, if the python shell buffee is not visible, a new window will be split. Do you not find the same behavior on your end?
Should i continue with trying to run the test?

-Octi

> On Jul 23, 2015, at 12:45 PM, Andreas Roehler <email address hidden> wrote:
>
>> Am 23.07.2015 um 17:45 schrieb <email address hidden>:
>> [ ... ] if none are visible, a window is split (instead of
>> reusing one in the current frame OR bring the shell buffer in any of the
>> current windows).
>
> If some of the displayed windows should be replaced by the now re-used,
> how to determine which one?
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1472620).
> https://bugs.launchpad.net/bugs/1361535
>
> Title:
> py-switch-buffers-on-execute-p is broken. It uses/kills other buffers.
>
> Status in python-mode.el:
> Incomplete
>
> Bug description:
> According to documentation, when non-nil py-switch-buffers-on-
> execute-p should switch to the Python output buffer.
>
> In practice the switching does *not* occur into the Python output
> buffer already open, but into any *other* buffer currently opened.
> This implies, that with several windows on the emacs pane opened each
> C-c | command issued will 'eat up' one more window and exchange its
> buffers content with the Python shell until emacs's pane is completely
> fill with many Python shells and a single Python code buffer.
>
> This behavior can be reproduced with the following simple init.el file
>
> ;; load path of most recent python-mode.el from bzr branch lp:python-mode
> (add-to-list 'load-path "~/temporary/py/python-mode/")
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-windows-on-execute-p t)
> (setq py-switch-buffers-on-execute-p t)
>
> Once the situation has been reached that emacs's pane is filled with
> many Python shells and a single Python code buffer, issuing the
> command C-c | still leads to a permanent interchange of buffers with
> the Python code file 'wandering' around on emacs's pane.
>
> In the simplest case with only one Python shell and one code buffer
> displayed, there will be a permanent exchange of the buffers location
> on the screen will issuing the command C-c |
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/python-mode/+bug/1361535/+subscriptions

Ok I ran the test as suggested and here is the trace in the ert buffer:

Selector: py-ert-split-window-on-execute-1361535-test
Passed: 0
Failed: 1 (1 unexpected)
Total: 1/1

Started at: 2015-07-23 13:37:10-0400
Finished.
Finished at: 2015-07-23 13:37:11-0400

F

F py-ert-split-window-on-execute-1361535-test
    (invalid-function py-test-with-temp-buffer-point-min)

Am 23.07.2015 um 19:12 schrieb <email address hidden>:
> I would use the same behavior at M-x compile in determining the window in which to put the compilation buffer.

Isn't the opening resp. bringing forward of the compilation buffer the
same as with 'just-two?

> I know it 6.1.1 of python-mode the existing windows would be reused properly when the python shell buffer was not visible in any of the windows. Right now, afais, if the python shell buffee is not visible, a new window will be split.

Yes. How to do otherwise? Which window to replace instead?

There is still customizable py-keep-windows-configuration

Maybe give some more info WRT the workflow.

Am 23.07.2015 um 19:39 schrieb <email address hidden>:
> Ok I ran the test as suggested and here is the trace in the ert buffer:
>
> Selector: py-ert-split-window-on-execute-1361535-test
> Passed: 0
> Failed: 1 (1 unexpected)
> Total: 1/1
>
> Started at: 2015-07-23 13:37:10-0400
> Finished.
> Finished at: 2015-07-23 13:37:11-0400
>
> F
>
> F py-ert-split-window-on-execute-1361535-test
> (invalid-function py-test-with-temp-buffer-point-min)
>

Seems you did M-x testname

instead of M-x ert testname

The compile command does not kill all the other windows as 'just-two does.
It simply puts the buffer in the bottom window afais, for 3 or more windows
open. the 'just-two behavior will kill all the other windows if 3 or more
are open.
py-keep-windows configuration is what I've been using but then I have to
manually bring up the Python shell buffer in the window that I want, then
move to the end of the buffer to see the last output, then switch back to
my source buffer. That's when I went to py-split-window-on-execute t, which
has the bad behavior of splitting windows whenever the python shell is not
visible in any of the windows.

Ideally, I would like the behavior of just-two where the python shell
buffer is placed in the bottom window even when it's not visible, BUT not
kill all the remaining windows if 3 or more are open. Is this possible? I
know 6.1.1 had this behavior and was happy with it but completion would not
really work well there.

-Octi

On Thu, Jul 23, 2015 at 2:04 PM, Andreas Roehler <email address hidden>
wrote:

> Am 23.07.2015 um 19:12 schrieb <email address hidden>:
> > I would use the same behavior at M-x compile in determining the window
> in which to put the compilation buffer.
>
> Isn't the opening resp. bringing forward of the compilation buffer the
> same as with 'just-two?
>
>
> > I know it 6.1.1 of python-mode the existing windows would be reused
> properly when the python shell buffer was not visible in any of the
> windows. Right now, afais, if the python shell buffee is not visible, a new
> window will be split.
>
> Yes. How to do otherwise? Which window to replace instead?
>
> There is still customizable py-keep-windows-configuration
>
>
> Maybe give some more info WRT the workflow.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1472620).
> https://bugs.launchpad.net/bugs/1361535
>
> Title:
> py-switch-buffers-on-execute-p is broken. It uses/kills other buffers.
>
> Status in python-mode.el:
> Incomplete
>
> Bug description:
> According to documentation, when non-nil py-switch-buffers-on-
> execute-p should switch to the Python output buffer.
>
> In practice the switching does *not* occur into the Python output
> buffer already open, but into any *other* buffer currently opened.
> This implies, that with several windows on the emacs pane opened each
> C-c | command issued will 'eat up' one more window and exchange its
> buffers content with the Python shell until emacs's pane is completely
> fill with many Python shells and a single Python code buffer.
>
> This behavior can be reproduced with the following simple init.el file
>
> ;; load path of most recent python-mode.el from bzr branch lp:python-mode
> (add-to-list 'load-path "~/temporary/py/python-mode/")
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-windows-on-execute-p t)
> (setq py-switch-buffers-on-execute-p t)
>
> Once the situation has been reached that emacs's pane is filled with
> many Python shells and a single Python code buffer, issuing the
> command C-c | still leads to a permanent interchan...

I did M-x ert <RET> py-ert-split-window-on-execute-1361535-test <RET>
I can't do M-x ert py-ert-split-window-on-execute-1361535-test

Am 23.07.2015 um 20:27 schrieb <email address hidden>:
> The compile command does not kill all the other windows as 'just-two does.
> It simply puts the buffer in the bottom window afais, for 3 or more windows
> open. the 'just-two behavior will kill all the other windows if 3 or more
> are open.
> py-keep-windows configuration is what I've been using but then I have to
> manually bring up the Python shell buffer in the window that I want, then
> move to the end of the buffer to see the last output, then switch back to
> my source buffer. That's when I went to py-split-window-on-execute t, which
> has the bad behavior of splitting windows whenever the python shell is not
> visible in any of the windows.
>
> Ideally, I would like the behavior of just-two where the python shell
> buffer is placed in the bottom window even when it's not visible, BUT not
> kill all the remaining windows if 3 or more are open. Is this possible? I
> know 6.1.1 had this behavior and was happy with it but completion would not
> really work well there.
>
>

Maybe a threshold, where instead of further split something like
other-buffer is used.

As far as I see the compilation buffer just uses an adjacent window in the frame. For the C-x 2 <RET> C-x 3<RET> setup, the compile buffer will be shown in the most bottom window.

Can't there be an option added to py-split-window-on-execute such that if there are 3 or more windows open and the python shell is not visible just reuse a window (i.e. default is the left most, "bottom" most window) to display the shell buffer instead of splitting the current one?

Well anything would be better than manually bringing the python shell to
the buffer of my choice when (py-keep-windows-configuration t) or re-doing
my window setup when (py-split-window-on-execute 'just-two).
Personally, I'd suggest using the same window selection behavior and
splitting behavior of the compile command. Which afais, is split only if
there's one window present and re-use window if more than one window is
present.

Thanks for looking into this Andreas!

-Octi

On Thu, Jul 23, 2015 at 3:10 PM, Andreas Roehler <email address hidden>
wrote:

> ** Changed in: python-mode
> Status: Incomplete => New
>
> ** Changed in: python-mode
> Importance: Undecided => Medium
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1472620).
> https://bugs.launchpad.net/bugs/1361535
>
> Title:
> py-switch-buffers-on-execute-p is broken. It uses/kills other buffers.
>
> Status in python-mode.el:
> New
>
> Bug description:
> According to documentation, when non-nil py-switch-buffers-on-
> execute-p should switch to the Python output buffer.
>
> In practice the switching does *not* occur into the Python output
> buffer already open, but into any *other* buffer currently opened.
> This implies, that with several windows on the emacs pane opened each
> C-c | command issued will 'eat up' one more window and exchange its
> buffers content with the Python shell until emacs's pane is completely
> fill with many Python shells and a single Python code buffer.
>
> This behavior can be reproduced with the following simple init.el file
>
> ;; load path of most recent python-mode.el from bzr branch lp:python-mode
> (add-to-list 'load-path "~/temporary/py/python-mode/")
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-windows-on-execute-p t)
> (setq py-switch-buffers-on-execute-p t)
>
> Once the situation has been reached that emacs's pane is filled with
> many Python shells and a single Python code buffer, issuing the
> command C-c | still leads to a permanent interchange of buffers with
> the Python code file 'wandering' around on emacs's pane.
>
> In the simplest case with only one Python shell and one code buffer
> displayed, there will be a permanent exchange of the buffers location
> on the screen will issuing the command C-c |
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/python-mode/+bug/1361535/+subscriptions
>

Am 23.07.2015 um 20:30 schrieb <email address hidden>:
> I did M-x ert <RET> py-ert-split-window-on-execute-1361535-test <RET>
> I can't do M-x ert py-ert-split-window-on-execute-1361535-test
>

after M-x ert

yank in the test-name

Am 23.07.2015 um 21:10 schrieb <email address hidden>:
> As far as I see the compilation buffer just uses an adjacent window in
> the frame. For the C-x 2 <RET> C-x 3<RET> setup, the compile buffer will
> be shown in the most bottom window.
>
> Can't there be an option added to py-split-window-on-execute such that
> if there are 3 or more windows open and the python shell is not visible
> just reuse a window (i.e. default is the left most, "bottom" most
> window) to display the shell buffer instead of splitting the current
> one?
>

think yes

see last mail crossing yours.

Got it thanks. I guess I should post all replies here as opposed to my inbox to make it visible to the community.
Yes the option with a threshold would be good. Splitting every time it's not visible doesn't make sense to me. The most intuitive thing for me is to mimic the 'compile' command pop-to-buffer behavior.

As for the tests:

M-x ert <RET> \C-y <RET>
yields the trace I had shown before (with py-ert-split-window-on-execute-1361535-test being in my kill-ring

M-x ert\C-y<RET> displays:
M-x ertertpy-ert-split-window-on-execute-1361535-test[No match]
since there's no such command.

Am 23.07.2015 um 21:41 schrieb <email address hidden>:
> Got it thanks. I guess I should post all replies here as opposed to my inbox to make it visible to the community.
> Yes the option with a threshold would be good. Splitting every time it's not visible doesn't make sense to me. The most intuitive thing for me is to mimic the 'compile' command pop-to-buffer behavior.
>
> As for the tests:
>
> M-x ert <RET> \C-y <RET>
> yields the trace I had shown before (with py-ert-split-window-on-execute-1361535-test being in my kill-ring
>
> M-x ert\C-y<RET> displays:
> M-x ertertpy-ert-split-window-on-execute-1361535-test[No match]
> since there's no such command.
>

Assume some kind of mistake, hard to tell from here.

ert has an own info manual.

Please re-open if not done.

Hey thanks for the commit, the splitting no longer occurs and windows are
re-used. However there is a bit of erratic choice when windows are picked.
As usual the setup is C-x 2 <RET> C-x 3 <RET>
When 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)

-Octi

On Fri, Jul 24, 2015 at 2:48 AM, Andreas Roehler <email address hidden>
wrote:

> Please re-open if not done.
>
> ** Changed in: python-mode
> Status: New => Fix Committed
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1472620).
> https://bugs.launchpad.net/bugs/1361535
>
> Title:
> py-switch-buffers-on-execute-p is broken. It uses/kills other buffers.
>
> Status in python-mode.el:
> Fix Committed
>
> Bug description:
> According to documentation, when non-nil py-switch-buffers-on-
> execute-p should switch to the Python output buffer.
>
> In practice the switching does *not* occur into the Python output
> buffer already open, but into any *other* buffer currently opened.
> This implies, that with several windows on the emacs pane opened each
> C-c | command issued will 'eat up' one more window and exchange its
> buffers content with the Python shell until emacs's pane is completely
> fill with many Python shells and a single Python code buffer.
>
> This behavior can be reproduced with the following simple init.el file
>
> ;; load path of most recent python-mode.el from bzr branch lp:python-mode
> (add-to-list 'load-path "~/temporary/py/python-mode/")
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-windows-on-execute-p t)
> (setq py-switch-buffers-on-execute-p t)
>
> Once the situation has been reached that emacs's pane is filled with
> many Python shells and a single Python code buffer, issuing the
> command C-c | still leads to a permanent interchange of buffers with
> the Python code file 'wandering' around on emacs's pane.
>
> In the simplest case with only one Python shell and one code buffer
> displayed, there will be a permanent e...

Am 24.07.2015 um 17:16 schrieb <email address hidden>:
> Hey thanks for the commit, the splitting no longer occurs and windows are
> re-used.

Please open a new report for the remaining, as the topic is not covered
by this one.

It would be hard to fix all window-related issues with a single ticket.

Consider users may want to read the discussion in order to understand
what the fix is about.

> However there is a bit of erratic choice when windows are picked.
> As usual the setup is C-x 2 <RET> C-x 3 <RET>
> When 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)
>
> -Octi
>
> On Fri, Jul 24, 2015 at 2:48 AM, Andreas Roehler <email address hidden>
> wrote:
>
>> Please re-open if not done.
>>
>> ** Changed in: python-mode
>> Status: New => Fix Committed
>>
>> --
>> You received this bug notification because you are subscribed to a
>> duplicate bug report (1472620).
>> https://bugs.launchpad.net/bugs/1361535
>>
>> Title:
>> py-switch-buffers-on-execute-p is broken. It uses/kills other buffers.
>>
>> Status in python-mode.el:
>> Fix Committed
>>
>> Bug description:
>> According to documentation, when non-nil py-switch-buffers-on-
>> execute-p should switch to the Python output buffer.
>>
>> In practice the switching does *not* occur into the Python output
>> buffer already open, but into any *other* buffer currently opened.
>> This implies, that with several windows on the emacs pane opened each
>> C-c | command issued will 'eat up' one more window and exchange its
>> buffers content with the Python shell until emacs's pane is completely
>> fill with many Python shells and a single Python code buffer.
>>
>> This behavior can be reproduced with the following simple init.el file
>>
>> ;; load path of most recent python-mode.el from bzr branch lp:python-mode
>> (add-to-list 'load-path "~/temporary/py/python-mode/")
>>
>> (require 'python-mode)
>> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>>
>> (setq py-split-windows-on-execute-p t)
>> (setq py-swi...

I opened bug https://bugs.launchpad.net/python-mode/+bug/1478122.
The attachments are in a zip though.

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

> Am 24.07.2015 um 17:16 schrieb <email address hidden>:
> > Hey thanks for the commit, the splitting no longer occurs and windows are
> > re-used.
>
> Please open a new report for the remaining, as the topic is not covered
> by this one.
>
> It would be hard to fix all window-related issues with a single ticket.
>
> Consider users may want to read the discussion in order to understand
> what the fix is about.
>
> > However there is a bit of erratic choice when windows are picked.
> > As usual the setup is C-x 2 <RET> C-x 3 <RET>
> > When 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)
> >
> > -Octi
> >
> > On Fri, Jul 24, 2015 at 2:48 AM, Andreas Roehler <
> <email address hidden>>
> > wrote:
> >
> >> Please re-open if not done.
> >>
> >> ** Changed in: python-mode
> >> Status: New => Fix Committed
> >>
> >> --
> >> You received this bug notification because you are subscribed to a
> >> duplicate bug report (1472620).
> >> https://bugs.launchpad.net/bugs/1361535
> >>
> >> Title:
> >> py-switch-buffers-on-execute-p is broken. It uses/kills other
> buffers.
> >>
> >> Status in python-mode.el:
> >> Fix Committed
> >>
> >> Bug description:
> >> According to documentation, when non-nil py-switch-buffers-on-
> >> execute-p should switch to the Python output buffer.
> >>
> >> In practice the switching does *not* occur into the Python output
> >> buffer already open, but into any *other* buffer currently opened.
> >> This implies, that with several windows on the emacs pane opened each
> >> C-c | command issued will 'eat up' one more window and exchange its
> >> buffers content with the Python shell until emacs's pane is
> completely
> >> fill with many Python shells and a single Python code buffer.
> >>
> >> This behavior can be reproduced w...