An Emacs mode for editing Python code

inconvinient py-shell-switch-buffers-on-execute when the buffer with interpreter is already visible

Reported by Yaroslav Halchenko on 2012-11-01
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-mode.el
Medium
Andreas Roehler

Bug Description

now it would just switch current buffer from code to an interpreter buffer even if interpreter buffer is already visible next to it -- kinda pointless. I thought that in such scenario (both code + interpreter visible) it would be useful if just focus was switched from code buffer to interpreter buffer (I think that is how it was with old python-mode iirc)

Changed in python-mode:
assignee: nobody → Andreas Roehler (a-roehler)
milestone: none → 6.1.1
importance: Undecided → Medium

Am 01.11.2012 15:56, schrieb Yaroslav Halchenko:
> Public bug reported:
>
> now it would just switch current buffer from code to an interpreter
> buffer even if interpreter buffer is already visible next to it -- kinda
> pointless.

visibility and focus are different things.

if switch is t, focus will shift
set py-shell-switch-buffers-on-execute to nil to avoid this

   I thought that in such scenario (both code + interpreter
> visible) it would be useful if just focus was switched from code buffer
> to interpreter buffer

done when py-shell-switch-buffers-on-execute is t

(I think that is how it was with old python-mode
> iirc)
>

Yaroslav Halchenko (yarikoptic) wrote :

On Thu, 01 Nov 2012, Andreas Roehler wrote:
> > now it would just switch current buffer from code to an interpreter
> > buffer even if interpreter buffer is already visible next to it -- kinda
> > pointless.

> visibility and focus are different things.

agree! are focus and switching the same? ;)

> if switch is t, focus will shift
> set py-shell-switch-buffers-on-execute to nil to avoid this
> I thought that in such scenario (both code + interpreter
> > visible) it would be useful if just focus was switched from code buffer
> > to interpreter buffer
> done when py-shell-switch-buffers-on-execute is t

Once again, if I

py-shell-switch-buffers-on-execute: t

it first switches current buffer to the shell (thus maintaining
original focus). I expected it to shift focus to the Shell buffer
(already visible) instead of getting two vies of the same shell buffer.

demo:

before I press C-c C-c:
http://www.onerussian.com/tmp/gkrellShoot_11-01-12_145038.png

after:
http://www.onerussian.com/tmp/gkrellShoot_11-01-12_145054.png

with focus being in the first buffer in both of the figures, while
desired behavior to have first image with focus shifted to the shell

--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

Andreas Roehler (a-roehler) wrote :

Am 01.11.2012 19:52, schrieb Yaroslav Halchenko:
> On Thu, 01 Nov 2012, Andreas Roehler wrote:
>>> now it would just switch current buffer from code to an interpreter
>>> buffer even if interpreter buffer is already visible next to it -- kinda
>>> pointless.
>
>> visibility and focus are different things.
>
> agree! are focus and switching the same? ;)

to be more precise let's drop the term focus and say

buffer-current-and-displayed

>
>> if switch is t, focus will shift
>> set py-shell-switch-buffers-on-execute to nil to avoid this
>> I thought that in such scenario (both code + interpreter
>>> visible) it would be useful if just focus was switched from code buffer
>>> to interpreter buffer
>> done when py-shell-switch-buffers-on-execute is t
>
> Once again, if I
>
> py-shell-switch-buffers-on-execute: t
>
> it first switches current buffer to the shell (thus maintaining
> original focus). I expected it to shift focus to the Shell buffer
> (already visible) instead of getting two vies of the same shell buffer.
>

Setting that variable alone should do nothing.
The result depends on the command which will follow

To make some ground, maybe try this:

Set py-shell-switch-buffers-on-execute: t
Register a point in your script buffer
M-x split-buffer-vertically
Switch to shell
M-x other-window
jump-to-register

now you should have the desired configuration, save it

M-x window-configuration-to-register

Hmm, C-c C-c works nicely, but py-shell-switch-buffers-on-execute is ignored, cursor remains in script-buffer.

So there is a bug,

So far,

Andreas

Andreas Roehler (a-roehler) wrote :

[ ... ]

checked in some fixes, please try again

;;;;;;;;;;;;

   made settings more convenient, new commands

   - toggle-py-split-windows-on-execute-p
   - py-split-windows-on-execute-p-off
   - py-split-windows-on-execute-p-on

   - toggle-py-switch-buffers-on-execute-p
   - py-switch-buffers-on-execute-p-on
   - py-switch-buffers-on-execute-p-off

   `py-shell-manage-windows' reconsidered
   menu Modes from PyTools redone

Changed in python-mode:
status: New → Fix Committed
Yaroslav Halchenko (yarikoptic) wrote :

On Fri, 02 Nov 2012, Andreas Roehler wrote:
> Setting that variable alone should do nothing.
> The result depends on the command which will follow

> To make some ground, maybe try this:

> Set py-shell-switch-buffers-on-execute: t
> Register a point in your script buffer
> M-x split-buffer-vertically
> Switch to shell
> M-x other-window
> jump-to-register
> now you should have the desired configuration, save it

> M-x window-configuration-to-register

oy...

with all recent improvements (Thanks! trying them now) -- is there an
option accessible to mortals like me which would allow me to
focus into the python shell without changing anything in buffers/windows
configuration (and without going to the suggested "flow" of settings?
;) )

> Hmm, C-c C-c works nicely, but py-shell-switch-buffers-on-execute is
> ignored, cursor remains in script-buffer.

> So there is a bug,

--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

Andreas Roehler (a-roehler) wrote :

Am 06.11.2012 18:43, schrieb Yaroslav Halchenko:
> On Fri, 02 Nov 2012, Andreas Roehler wrote:
>> Setting that variable alone should do nothing.
>> The result depends on the command which will follow
>
>> To make some ground, maybe try this:
>
>> Set py-shell-switch-buffers-on-execute: t
>> Register a point in your script buffer
>> M-x split-buffer-vertically
>> Switch to shell
>> M-x other-window
>> jump-to-register
>> now you should have the desired configuration, save it
>
>> M-x window-configuration-to-register
>
> oy...
>
> with all recent improvements (Thanks! trying them now) -- is there an
> option accessible to mortals like me which would allow me to
> focus into the python shell without changing anything in buffers/windows
> configuration (and without going to the suggested "flow" of settings?
> ;) )

well, sure, just M-x python
resp. C-c C-c from script-buffer

All question starts of you want to have a specific look and feel and make Emacs remember it.

>
>> Hmm, C-c C-c works nicely, but py-shell-switch-buffers-on-execute is
>> ignored, cursor remains in script-buffer.
>
>> So there is a bug,
>

Yaroslav Halchenko (yarikoptic) wrote :

On Tue, 06 Nov 2012, Andreas Roehler wrote:
> > with all recent improvements (Thanks! trying them now) -- is there an
> > option accessible to mortals like me which would allow me to
> > focus into the python shell without changing anything in buffers/windows
> > configuration (and without going to the suggested "flow" of settings?
> > ;) )

> well, sure, just M-x python
> resp. C-c C-c from script-buffer

exactly my question since those do not switch focus into the Python
shell buffer.

> All question starts of you want to have a specific look and feel and
> make Emacs remember it.

I was just trying to get a "feel" similar to the one I had with
previous/elderly python-mode. But ok -- I guess what I am aiming at is
both py-split-windows-on-execute-p and
py-shell-switch-buffers-on-execute being set on and perform
consistently then...

another recent one I believe: with split-windows-on execute set,
if I have 1 buffer, initiate a new shell (C-c !) I get now 3 buffers --
two of the original file (some times 1 of the original, another one
*scratch*) and then the shell one. Then if I call C-c C-c again (while
having toggle-switch-shell-on-execute on) -- I can even get 4 buffers
now (2 for file, 2 for shell)

--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

Andreas Roehler (a-roehler) wrote :

Am 07.11.2012 03:44, schrieb Yaroslav Halchenko:
> On Tue, 06 Nov 2012, Andreas Roehler wrote:
>>> with all recent improvements (Thanks! trying them now) -- is there an
>>> option accessible to mortals like me which would allow me to
>>> focus into the python shell without changing anything in buffers/windows
>>> configuration (and without going to the suggested "flow" of settings?
>>> ;) )
>
>> well, sure, just M-x python
>> resp. C-c C-c from script-buffer
>
> exactly my question since those do not switch focus into the Python
> shell buffer.
>
>> All question starts of you want to have a specific look and feel and
>> make Emacs remember it.
>
> I was just trying to get a "feel" similar to the one I had with
> previous/elderly python-mode. But ok -- I guess what I am aiming at is
> both py-split-windows-on-execute-p and
> py-shell-switch-buffers-on-execute being set on and perform
> consistently then...

exactly. So please don't give up. It should work and will work :)

BTW you may ignore these setting with every command, no need to re-customize.
Just pick the right command from Menu PyExec at the bottom "Ignoring defaults..."

Just you miss a command there, tell me.

>
> another recent one I believe: with split-windows-on execute set,
> if I have 1 buffer, initiate a new shell (C-c !) I get now 3 buffers --
> two of the original file (some times 1 of the original, another one
> *scratch*) and then the shell one. Then if I call C-c C-c again (while
> having toggle-switch-shell-on-execute on) -- I can even get 4 buffers
> now (2 for file, 2 for shell)
>

This is controlled by py-max-split-windows.
When set 2, this should not happen. If it happens, please file another report.

Yaroslav Halchenko (yarikoptic) wrote :

During my fasco with shebang line (that bug report I just opened, please close):

but now interesting side-effect regarding splitting/focusing:
While working with *ubp Python" I first enabled splitting and switch, made only code buffer and *ubp Python* visible, disabled splitting AND then it started doing what I wanted -- no additional splitting upon C-c C-c -- just switching focus to the interpreter

Then I "Enforce py-shell-name", started my *Ipython" with C-c! (since it was in shebang) but now shit got loose -- whenever I do C-c C-c, even though *Ipython* is visible, current buffer switches from code to yet another view of *IPython* heh heh

ok -- remembered about your hint on

  py-max-split-windows is a variable defined in `python-mode.el'.
  Its value is 2

enabled splitting and switch -- C-c C-c resulted in 3 buffers (from 2): code, *Python*, "*IPython*". you can see coursor jumpbing from code, to Python and then to IPython upon C-c C-c -- happens all the time and if *Python* is not visible -- would split/bring it up, jump through it. reproducible:

opened again

#emacs: -*- mode: python; py-indent-offset: 4; tab-width: 4; indent-tabs-mode: nil -*-
#ex: set sts=4 ts=4 sw=4 noet:

class X:
    XX = [
        "asdfasdF",
        "asdfasdf",
    # lakjsdflkjasdf
"lkajsdlkfj"
    ]

print X

set splitting and switch on, C-c C-c results in 4 buffers (ufff, with 2 of code), and C-c C-c jumps though *Python*....

ufffff

yet another side effect :
Symbol's function definition is void: py-execute-file-python-dedicated
while trying to execute file in a dedicated python via menu

Changed in python-mode:
status: Fix Committed → In Progress

Am 09.11.2012 18:02, schrieb Yaroslav Halchenko:
> During my fasco with shebang line (that bug report I just opened, please
> close):
>
> but now interesting side-effect regarding splitting/focusing:
> While working with *ubp Python" I first enabled splitting and switch, made only code buffer and *ubp Python* visible, disabled splitting AND then it started doing what I wanted -- no additional splitting upon C-c C-c -- just switching focus to the interpreter
>
> Then I "Enforce py-shell-name", started my *Ipython" with C-c! (since it
> was in shebang) but now shit got loose -- whenever I do C-c C-c, even
> though *Ipython* is visible, current buffer switches from code to yet
> another view of *IPython* heh heh
>
> ok -- remembered about your hint on
>
> py-max-split-windows is a variable defined in `python-mode.el'.
> Its value is 2
>
> enabled splitting and switch -- C-c C-c resulted in 3 buffers (from 2):
> code, *Python*, "*IPython*". you can see coursor jumpbing from code, to
> Python and then to IPython upon C-c C-c -- happens all the time and if
> *Python* is not visible -- would split/bring it up, jump through it.
> reproducible:
>
> opened again
>
> #emacs: -*- mode: python; py-indent-offset: 4; tab-width: 4; indent-tabs-mode: nil -*-
> #ex: set sts=4 ts=4 sw=4 noet:
>
>
> class X:
> XX = [
> "asdfasdF",
> "asdfasdf",
> # lakjsdflkjasdf
> "lkajsdlkfj"
> ]
>
> print X
>
> set splitting and switch on, C-c C-c results in 4 buffers (ufff, with 2
> of code), and C-c C-c jumps though *Python*....
>
> ufffff
>
> yet another side effect :
> Symbol's function definition is void: py-execute-file-python-dedicated
> while trying to execute file in a dedicated python via menu
>

the latter should be fixed - alongside with some other commands missing.

the former is lp:1077489

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

Other bug subscribers