py-switch-buffers-on-execute-p is broken. It uses/kills other buffers.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
python-mode.el |
Fix Committed
|
Medium
|
Andreas Roehler |
Bug Description
According to documentation, when non-nil py-switch-
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/
(require 'python-mode)
(add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
(setq py-split-
(setq py-switch-
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 |
Changed in python-mode: | |
importance: | Undecided → High |
assignee: | nobody → Andreas Roehler (a-roehler) |
milestone: | none → 6.2.0 |
Andreas Roehler (a-roehler) wrote : | #1 |
Changed in python-mode: | |
status: | New → Fix Committed |
Zeitlinie (zeitlinie) wrote : | #2 |
This does not have the desired effect.
What happens is that when I add
(setq py-switch-
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
Andreas Roehler (a-roehler) wrote : | #3 |
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
Changed in python-mode: | |
status: | Fix Committed → New |
Zeitlinie (zeitlinie) wrote : | #4 |
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/
(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-
py-switch-
Therefore I used M-x customize-variable RET to set py-switch-
(custom-
The behavior remains exactly the same as described before - no change.
(py-version = 6.1.4, revno=1663, emacs = 24.3.1)
Changed in python-mode: | |
status: | New → In Progress |
Andreas Roehler (a-roehler) wrote : | #5 |
Please re-open if not done.
Changed in python-mode: | |
status: | In Progress → Fix Committed |
Zeitlinie (zeitlinie) wrote : | #6 |
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
Andreas Roehler (a-roehler) wrote : Re: [Bug 1361535] Re: py-switch-buffers-on-execute-p is broken. It uses/kills other buffers. | #7 |
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
Changed in python-mode: | |
status: | Fix Committed → New |
Changed in python-mode: | |
status: | New → In Progress |
Changed in python-mode: | |
milestone: | 6.2.0 → 6.2.1 |
Changed in python-mode: | |
status: | In Progress → Fix Committed |
deuscovrigus@gmail.com (deuscovrigus) wrote : | #8 |
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-
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
---------- |-----------
|
deuscovrigus@gmail.com (deuscovrigus) wrote : | #9 |
|------
| | |
| | |
|------
| |
| |
|------
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?
Changed in python-mode: | |
status: | Fix Committed → New |
Andreas Roehler (a-roehler) wrote : | #10 |
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.
Changed in python-mode: | |
status: | New → Incomplete |
importance: | High → Undecided |
milestone: | 6.2.1 → none |
assignee: | Andreas Roehler (a-roehler) → nobody |
deuscovrigus@gmail.com (deuscovrigus) wrote : | #11 |
- window_setups.zip Edit (878.3 KiB, application/zip)
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
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_
So the t option really doesn't like re-using existing buffers.
Let me know is this is explained more clearly.
Andreas Roehler (a-roehler) wrote : | #12 |
Thanks going on. Please attach the png -iles as plain png again - no interest in opening zips :)
Changed in python-mode: | |
assignee: | nobody → Andreas Roehler (a-roehler) |
deuscovrigus@gmail.com (deuscovrigus) wrote : | #13 |
- after_executing_buffer_t.png Edit (356.4 KiB, image/png; name="after_executing_buffer_t.png")
- after_killing_ipython_and_executing_again.png Edit (303.7 KiB, image/png; name="after_killing_ipython_and_executing_again.png")
- init_setup.png Edit (242.9 KiB, image/png; name="init_setup.png")
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:/
>
> Title:
> py-switch-
>
> Status in python-mode.el:
> Incomplete
>
> Bug description:
> According to documentation, when non-nil py-switch-
> 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/
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-
> (setq py-switch-
>
> 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:/
>
deuscovrigus@gmail.com (deuscovrigus) wrote : | #14 |
Also please note that in "after_
It seems that one window was reused (top right) but for some reason the top left was split once again
Andreas Roehler (a-roehler) wrote : | #15 |
- reuse-py-shell-window.png Edit (135.2 KiB, image/png)
Py-shell is reused here - see attached reuse-py-
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-
deuscovrigus@gmail.com (deuscovrigus) wrote : | #16 |
- executing_python_once_splits_current_window_instead_of_using_bottom_window.png Edit (105.8 KiB, image/png)
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-
$EMACS -Q --batch --eval "(message (emacs-version))" --eval "(when (featurep 'python)
Is this how you evaluate the tests in the .el files?
this was the result:
$EMACS_DIR: /usr/share/
$EMACS: emacs
$CC_CMDS: /usr/share/
GNU Emacs 24.3.1 (x86_64-
of 2014-03-07 on lamiak, modified by Debian
py-install-
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)
Andreas Roehler (a-roehler) wrote : | #17 |
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-
>
> $EMACS -Q --batch --eval "(message (emacs-version))" --eval "(when
> (featurep 'python)
> 'python-
> 'load-path \"$PDIR/\")" --eval "(add-to-list 'load-path \"$TESTDIR/\")"
> --eval "(setq py-install-
> install-directory: %s\" py-install-
> 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-
> lp-1361531-test.el -f ert-run-
>
> Is this how you evaluate the tests in the .el files?
>
> this was the result:
> $EMACS_DIR: /usr/share/
> $EMACS: emacs
> $CC_CMDS: /usr/share/
> GNU Emacs 24.3.1 (x86_64-
> of 2014-03-07 on lamiak, modified by Debian
> py-install-
> 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_
> https:/
>
Do not use batch-mode for a single test. Batch-mode has some quirks and
bugs.
py-ert-
test/py-
All needed beside python-mode.el is
test/setup-
and the file, which contains the test.
Run the test M-x ert TESTNAME RET
Andreas Roehler (a-roehler) wrote : | #18 |
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?
deuscovrigus@gmail.com (deuscovrigus) wrote : | #19 |
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:/
>
> Title:
> py-switch-
>
> Status in python-mode.el:
> Incomplete
>
> Bug description:
> According to documentation, when non-nil py-switch-
> 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/
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-
> (setq py-switch-
>
> 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:/
deuscovrigus@gmail.com (deuscovrigus) wrote : | #20 |
Ok I ran the test as suggested and here is the trace in the ert buffer:
Selector: py-ert-
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-
(invalid-
Andreas Roehler (a-roehler) wrote : | #21 |
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-
Maybe give some more info WRT the workflow.
Andreas Roehler (a-roehler) wrote : | #22 |
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-
> 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-
> (invalid-function py-test-
>
Seems you did M-x testname
instead of M-x ert testname
deuscovrigus@gmail.com (deuscovrigus) wrote : | #24 |
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-
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-
>
>
> Maybe give some more info WRT the workflow.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1472620).
> https:/
>
> Title:
> py-switch-
>
> Status in python-mode.el:
> Incomplete
>
> Bug description:
> According to documentation, when non-nil py-switch-
> 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/
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-
> (setq py-switch-
>
> 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...
deuscovrigus@gmail.com (deuscovrigus) wrote : | #23 |
I did M-x ert <RET> py-ert-
I can't do M-x ert py-ert-
Andreas Roehler (a-roehler) wrote : | #26 |
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-
> 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.
Changed in python-mode: | |
status: | Incomplete → New |
importance: | Undecided → Medium |
deuscovrigus@gmail.com (deuscovrigus) wrote : | #25 |
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-
deuscovrigus@gmail.com (deuscovrigus) wrote : | #27 |
Well anything would be better than manually bringing the python shell to
the buffer of my choice when (py-keep-
my window setup when (py-split-
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:/
>
> Title:
> py-switch-
>
> Status in python-mode.el:
> New
>
> Bug description:
> According to documentation, when non-nil py-switch-
> 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/
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-
> (setq py-switch-
>
> 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:/
>
Andreas Roehler (a-roehler) wrote : | #28 |
Am 23.07.2015 um 20:30 schrieb <email address hidden>:
> I did M-x ert <RET> py-ert-
> I can't do M-x ert py-ert-
>
after M-x ert
yank in the test-name
Andreas Roehler (a-roehler) wrote : | #29 |
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-
> 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.
deuscovrigus@gmail.com (deuscovrigus) wrote : | #30 |
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-
M-x ert\C-y<RET> displays:
M-x ertertpy-
since there's no such command.
Andreas Roehler (a-roehler) wrote : | #31 |
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-
>
> M-x ert\C-y<RET> displays:
> M-x ertertpy-
> since there's no such command.
>
Assume some kind of mistake, hard to tell from here.
ert has an own info manual.
Andreas Roehler (a-roehler) wrote : | #32 |
Please re-open if not done.
Changed in python-mode: | |
status: | New → Fix Committed |
Changed in python-mode: | |
status: | Fix Committed → In Progress |
deuscovrigus@gmail.com (deuscovrigus) wrote : | #33 |
- additional_window_is_replaced_instead_of_reusing_bottom_window.png Edit (114.6 KiB, image/png; name="additional_window_is_replaced_instead_of_reusing_bottom_window.png")
- execution_of_pybuffer_results_in_different_window_focus.png Edit (269.8 KiB, image/png; name="execution_of_pybuffer_results_in_different_window_focus.png")
- init_setup_python_shell_visible.png Edit (265.5 KiB, image/png; name="init_setup_python_shell_visible.png")
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_
that window, executing python will replace an additional window. And, as
before, the buffer focus changes to the next window. (see
additional_
Seems to me that the current implementation just picks the window obtained
by C-x o (other-
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:/
>
> Title:
> py-switch-
>
> Status in python-mode.el:
> Fix Committed
>
> Bug description:
> According to documentation, when non-nil py-switch-
> 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/
>
> (require 'python-mode)
> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>
> (setq py-split-
> (setq py-switch-
>
> 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...
Andreas Roehler (a-roehler) wrote : | #34 |
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_
> that window, executing python will replace an additional window. And, as
> before, the buffer focus changes to the next window. (see
> additional_
>
> Seems to me that the current implementation just picks the window obtained
> by C-x o (other-
> 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:/
>>
>> Title:
>> py-switch-
>>
>> Status in python-mode.el:
>> Fix Committed
>>
>> Bug description:
>> According to documentation, when non-nil py-switch-
>> 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/
>>
>> (require 'python-mode)
>> (add-to-list 'auto-mode-alist '("\\.py$" . python-mode))
>>
>> (setq py-split-
>> (setq py-swi...
deuscovrigus@gmail.com (deuscovrigus) wrote : | #35 |
I opened bug https:/
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_
> re-using
> > that window, executing python will replace an additional window. And, as
> > before, the buffer focus changes to the next window. (see
> > additional_
> >
> > Seems to me that the current implementation just picks the window
> obtained
> > by C-x o (other-
> 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:/
> >>
> >> Title:
> >> py-switch-
> buffers.
> >>
> >> Status in python-mode.el:
> >> Fix Committed
> >>
> >> Bug description:
> >> According to documentation, when non-nil py-switch-
> >> 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...
Changed in python-mode: | |
status: | In Progress → Fix Committed |
Re-wrote some parts. Please try again.