inconvenient window splitting behavior

please re-open if not done

I do not see any reopen button, so I can't re-open

it seems to jump as bad as before
C-! still closes other windows if not in *split-windows*

Am 29.06.2012 16:33, schrieb Yaroslav Halchenko:
> I do not see any reopen button, so I can't re-open
>
> it seems to jump as bad as before
> C-! still closes other windows if not in *split-windows*
>

please give some details on situation

starting from windows splitted/not-splitted script buffer or not etc.
diffs expectation/happening

If window is already splitted, should py-shell split again?

thanks,

Andreas

> please give some details on situation
let's try

> starting from windows splitted/not-splitted script buffer or not etc.
> diffs expectation/happening

I will expand with my expections on what I previously written:

- if I disable splitting and shell-switch-buffers-on-execute is off -- it would maximize code buffer thus hiding all other visible before

IMHO it should do NOTHING with windows/focus -- since I did not ask it to split, nor I asked it to focus. It just should send content to the shell

- if -focus- is on -- then it works only if I have split into 2 ... if I had more splits -- only 2 survive upon C-c C-c and it might be not the actual buffer with code sent which would be visible after C-c C-c

IMHO if split is off, there should be no additional splitting/closing of windows done -- it needs to focus (since focus is on) into the shell... if that one is not visisble -- it must be made visible instead of current (code) buffer.... makes sense?

- If I enable splitting -- it becomes complete mad possibly making more splits, or making other splits show the buffer which I have sent with C-c C-c

> If window is already splitted, should py-shell split again?

if there is shell window already visible -- it should NOT alter anything in the state of split windows regardless either it was *-split*=on or off. if shell is not visible and "split" is on -- split to get shell window visible (but do not close other split windows). if shell is not visible and split is off -- do not split and do not in general do anything to the state of current windows splitting (only possibly switch to the shell buffer if switch is on within current code buffer split)... seems to be logical

Hi,

I too have been having a hard time with the window splitting. I was having problems trying to auto-complete and having my split windows being discarded. I have just had a bit of a dig through the code and i could find the offending line but instead of the worlds lamest patch i have attached something that should be a little better.

in regards to Yaroslav's issues

- if I disable splitting and shell-switch-buffers-on-execute is off -- it would maximize code buffer thus hiding all other visible before
This should be fixed in the patch, it was the same thing that was effecting my auto-completion.

- if -focus- is on -- then it works only if I have split into 2 ... if I had more splits -- only 2 survive upon C-c C-c and it might be not the actual buffer with code sent which would be visible after C-c C-c
It will raise the window over the existing one. This is only really useful if you like working with one big window.

- If I enable splitting -- it becomes complete mad possibly making more splits, or making other splits show the buffer which I have sent with C-c C-c
If you have less than the max splits variable then it will split the current window by method of choice. otherwise it will reuse an existing window.

Does that sound reasonable?

In regards to Andreas

If window is already splitted, should py-shell split again?
I have made a max split variable, to allow the user to specify the max number of splits they prefer.

 I'm happy to change the patch if you have any feedback :)

Thanks,
Russell

Hi,

I spotted a bug in the implementation of the 'split, not switch' functionality, i have updated the patch to fix this.

Cheers,
Russell

Hi Russell,

applied your patch, sorry for the delay,

cheers,

Andreas

Not sure if this might have been fixed with this patch: installed fresh Debian package of 6.0.12 from Barry, and while in ipython buffer, and trying to complete anything in the interactive shell, it opens up completions in a new buffer covering whole window, which when disappears returns to ipython buffer -- the catch is also that if there was any prior window splitting -- it is gone now.

made some change, please try again

Thanks Andreas -- tried it -- I guess it is better now...

so, now if I have pre-split window with an original source code in one (#1), and the interactive ipython in another (#2), completing in ipython shell uses the #1. Then whenever I am done completing I have following options to "close" it to get back to the code view: switch to it and press 'q' or actually complete completion by clicking mouse on a desired choice -- then completion buffer gets removed going back to #1 with the source code. And then if I just triple-Esc -- it closes ALL other buffers and I end up with the mighty shell. And I guess that is how other shells completions behave (tested with a regular shell). I just wondered what is your usage pattern? do you just keep completions buffer pre-opened all the time? or use mouse/switch+q to close it? Ideally, I wished there was a way to close completions buffer without leaving the prompt buffer and without hurting any previously opened (e.g. code view in #1) as if I pressed 'q' in it... e.g. if Triple-Esc (keyboard-escape-quit) could be overriden to invoke that action in the "*Python Completions". Or may be there is already some shortcut which would accomplish this?

An "interesting" side effect I ran into while playing with it
- if I quickly press tab 2 (or more) times, besides progressing to the first choice (and additional tab if more than twice tab was pressed) inserted after the completion, a previous prompt in the buffer might obtain a list of all possible completions ";"-separated, e.g.:

 [10]: np.array;np.array2string;np.array_equal;np.array_equiv;np.array_repr;np.array_split;np.array_str

In [12]: np.array

and then some times even cursor jumps to that line (instead that last prompt where I was trying to complete).
Have you ran into it?

lp:1065468 and lp:1065470 opened for this, closing splitting issue

Hi Andreas! Thanks a bunch -- now splitting behavior seems to be much better, i.e. I am not getting unexpected splits whenever I do not want anything changed while I am just sending a buffer for execution.

The only catch I found: if there is 2 (or more) views of the same buffer from which I am sending code for execution -- then the active one would flip into some other different (not visible before) buffer upon sending (e.g. via C-c C-c)

Am 29.10.2012 18:09, schrieb Yaroslav Halchenko:
> Hi Andreas! Thanks a bunch -- now splitting behavior seems to be much
> better, i.e. I am not getting unexpected splits whenever I do not want
> anything changed while I am just sending a buffer for execution.
>
> The only catch I found: if there is 2 (or more) views of the same
> buffer from which I am sending code for execution -- then the active one
> would flip into some other different (not visible before) buffer upon
> sending (e.g. via C-c C-c)
>

thanks, it here now: lp:1072816

This bug has come back again.

In the exact same situation Yaroslav Halchenko and Russell Sims described above. I have switching and splitting turned off, but if I have 2 windows open and do C-c C-c, I am left with only the code filling my whole screen.

The offending line(s?) are the (delete-other-windows) on 8730 and 8777 added back in revision 1162 ( http://bazaar.launchpad.net/~python-mode-devs/python-mode/python-mode/revision/1162 )

Am 19.12.2012 07:09, schrieb Thomas Caswell:
> This bug has come back again.
>
> In the exact same situation Yaroslav Halchenko and Russell Sims
> described above. I have switching and splitting turned off, but if I
> have 2 windows open and do C-c C-c, I am left with only the code filling
> my whole screen.
>
> The offending line(s?) are the (delete-other-windows) on 8730 and 8777
> added back in revision 1162 ( http://bazaar.launchpad.net/~python-mode-
> devs/python-mode/python-mode/revision/1162 )
>

Probably you should switch splitting on.
If off, what should Emacs do? Show the result? In which window?

BTW checked with emacs -Q, just loaded python-mode.el, all nice here - see attachment.

Andreas

If splitting and switching are both off emacs should not change my window layout in anyway, if the buffer with the results is hidden, that is my problem. I would like if there was a toggle that was basically 'leave-my-windows-exactly-as-they-were' that will turn off all of the window management (if you think this is a reasonable idea, I will try to write it).

I can confirm this bug still exists with emacs -Q and the following:

"""
(setq load-path (append load-path (list "~/.emacs.d/el-get/python-mode")))
(load "python-mode.el")
(setq py-split-windows-on-execute-p nil)
(setq py-switch-windows-on-execute-p nil)
"""
print 'h'

a C-cC-c will result in just the just a single window of the source

Am 20.12.2012 20:32, schrieb Thomas Caswell:
> If splitting and switching are both off emacs should not change my
> window layout in anyway, if the buffer with the results is hidden, that
> is my problem.

okay, that's reasonable.

  I would like if there was a toggle that was basically
> 'leave-my-windows-exactly-as-they-were' that will turn off all of the
> window management (if you think this is a reasonable idea, I will try to
> write it).

Great. So I'm looking forward for your patch.
BTW would welcome a new report for this, not to mix up several different scenarios, but that's up to you.

Andreas

On Thu, 20 Dec 2012, Andreas Roehler wrote:
> > If splitting and switching are both off emacs should not change my
> > window layout in anyway, if the buffer with the results is hidden, that
> > is my problem.
> okay, that's reasonable.
good

> I would like if there was a toggle that was basically
> > 'leave-my-windows-exactly-as-they-were' that will turn off all of the
> > window management (if you think this is a reasonable idea, I will try to
> > write it).
> Great. So I'm looking forward for your patch.
> BTW would welcome a new report for this, not to mix up several different scenarios, but that's up to you.

yikes -- why 1 more switch??? as you guys discussed, when both flags are
off (i.e. no splitting, no focusing) -- it should already behave as
'leave-my-windows-exactly-as-they-were'

imho (and I think I described it before) it should be:

# sorry for py-seudo code -- I have little clue in elisp
if py-switch-buffers-on-execute-p:
   if *Python* buffer is visible:
       switch focus to it (no additional splitting, blinking, etc)
   else:
      if py-split-windows-on-execute-p:
         split code buffer and switch to the shell split
      else:
         do not split -- just bring *Python* buffer up inplace of
         current code buffer
else:
   if py-split-windows-on-execute-p:
       if *Python* buffer is visible already:
          # DO NOTHING
       else:
          split current buffer, show *Python* in the 2nd split
   else:
       # DO NOTHING

--
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

Am 21.12.2012 18:45, schrieb Yaroslav Halchenko:
> On Thu, 20 Dec 2012, Andreas Roehler wrote:
>>> If splitting and switching are both off emacs should not change my
>>> window layout in anyway, if the buffer with the results is hidden, that
>>> is my problem.
>> okay, that's reasonable.
> good
>
>
>> I would like if there was a toggle that was basically
>>> 'leave-my-windows-exactly-as-they-were' that will turn off all of the
>>> window management (if you think this is a reasonable idea, I will try to
>>> write it).
>> Great. So I'm looking forward for your patch.
>> BTW would welcome a new report for this, not to mix up several different scenarios, but that's up to you.
>
> yikes -- why 1 more switch??? as you guys discussed, when both flags are
> off (i.e. no splitting, no focusing) -- it should already behave as
> 'leave-my-windows-exactly-as-they-were'
>

okay for me

> imho (and I think I described it before) it should be:
>
> # sorry for py-seudo code -- I have little clue in elisp
> if py-switch-buffers-on-execute-p:
> if *Python* buffer is visible:
> switch focus to it (no additional splitting, blinking, etc)
> else:
> if py-split-windows-on-execute-p:
> split code buffer and switch to the shell split
> else:
> do not split -- just bring *Python* buffer up inplace of
> current code buffer
> else:
> if py-split-windows-on-execute-p:
> if *Python* buffer is visible already:
> # DO NOTHING
> else:
> split current buffer, show *Python* in the 2nd split
> else:
> # DO NOTHING
>

Maybe have a look into py-shell-manage-windows which proceeds pretty close to your proposal.
The difference results from the flags overriding the default.

(I apologize now for muddling the terms around emacs windows/buffers...still trying to grok it all)
(also, sorry if this should get it's own issue, but it seems people who care about this are already following this bug)

I think we need the extra switch is necessary for the following reason.

I interpret the new switch as meaning 'try to make sure that the output buffer is visible after the code runs' ( py-on-execute-buffer-management-p )

If buffer management is disabled then everything else is ignored and emacs will not change anything about your buffers/windows.

If buffer management is enabled, then I interpret the switch flag as meaning 'make sure the current buffer/window after execution is the output buffer' and the split flag as 'if needed, emacs may create a new window by splitting the code buffer using the specified method'

This leads to the following logic

I) If there is only one window and splitting is disabled, then
    If switching is on, then we need to set the buffer in that window to the output buffer.
    If switching is off, nothing should change. (this is the one branch where emacs fails to make the output buffer visible)

II) if splitting is enabled and output buffer is not visible
IIa) if the number of windows is less than the maximum
  we split the code window, put the output in the new window, jump to III)
IIb) if the number of windows is not less than the maximum
  we select the least recently used window and set it to display the output buffer

III) if output buffer is visible
    we switch to it depending on if switching is enabled

I have re-written py-shell-manage-windows (and added a helper function) to implement this logic and removed the (delete-other-frames) for else where in the code. Patch is attached (I am working off a git mirror, I'll also try to get this as a branch on lp).

also on branch lp:~tcaswell-gmail/python-mode/window_fix

not sure if I should whine here or initiate a new report ;)

so, with 1165 rev, if I open a single buffer with .py file, set splitting to on (via toggle in the menu), press C-c ! -- I will get then 3 buffers: code buffer split into two, and then lower one with code split again to get also *IPython* one. Expected: 2 buffers (original code buffer + *IPython*).

and then me whining again

enabled only switch-buffers-on-execute (no split): having code buffer on top, and shell on the bottom. Pressing C-c C-c pretty much swaps the buffers -- makes shell active (as it should) but brings it on top, while code on the bottom... I guess it could be considered a feature -- although I expected it just to switch focus to the bottom one (already visible shell buffer)

Am 02.01.2013 16:09, schrieb Yaroslav Halchenko:
> not sure if I should whine here or initiate a new report ;)
>

Hi, thanks for the reports. Providing separate reports might help.

> so, with 1165 rev, if I open a single buffer with .py file, set
> splitting to on (via toggle in the menu), press C-c ! -- I will get then
> 3 buffers: code buffer split into two, and then lower one with code
> split again to get also *IPython* one. Expected: 2 buffers (original
> code buffer + *IPython*).
>

can't get it for the moment, see png.

If you look at https://code.launchpad.net/~tcaswell-gmail/python-mode/window_fix
I re-worked py-shell-manage-windows to address the 3-window problem
(it is the pop-to-buffer commands that are causing it).

I have also started a more agressive re-factoring of the whole
py-execute-* stack on
https://code.launchpad.net/~tcaswell-gmail/python-mode/execute_refactor
so that we can wrap all of the work in sending the code to the
process in a save-window-excursion, which will make sure that the
window configuration before py-shell-manage-windows is in the state
the user last had it in. We can then work on how to manage the
windows from a known state.

On Wed, Jan 2, 2013 at 2:18 PM, Andreas Roehler
<email address hidden> wrote:
> ** Changed in: python-mode
> Status: Fix Committed => New
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1018996
>
> Title:
> inconvenient window splitting behavior
>
> Status in An Emacs mode for editing Python code:
> New
> Status in Debian GNU/Linux:
> Confirmed
>
> Bug description:
> I thought that before (with one of the tentative debian packages) I
> have managed to make it convenient -- that I split the window to have
> in one buffer the code and in another ipython shell, so that C-! jumps
> into ipython, and C-c C-c sends buffer to ipython shell but
> everything remains as is -- just 2 buffers visible.
>
> Now with 1:6.0.10-1 it is chaos for me
>
> - if I disable splitting and shell-switch-buffers-on-execute is off -- it would maximize code buffer thus hiding all other visible before
> - if -focus- is on -- then it works only if I have split into 2 ... if I had more splits -- only 2 survive upon C-c C-c and it might be not the actual buffer with code sent which would be visible after C-c C-c
>
> - If I enable splitting -- it becomes complete mad possibly making
> more splits, or making other splits show the buffer which I have sent
> with C-c C-c
>
> is it just me or you see it too?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/python-mode/+bug/1018996/+subscriptions

--
Thomas Caswell
<email address hidden>

On Wed, 02 Jan 2013, Andreas Roehler wrote:
> > not sure if I should whine here or initiate a new report ;)
> Hi, thanks for the reports. Providing separate reports might help.

ok -- will do next time

> > so, with 1165 rev, if I open a single buffer with .py file, set
> > splitting to on (via toggle in the menu), press C-c ! -- I will get then
> > 3 buffers: code buffer split into two, and then lower one with code
> > split again to get also *IPython* one. Expected: 2 buffers (original
> > code buffer + *IPython*).
> can't get it for the moment, see png.
> ** Attachment added: "ipython.png"
> https://bugs.launchpad.net/bugs/1018996/+attachment/3472854/+files/ipython.png

hm... it is even the same emacs version I have ;-)

so -- tried with a clean .emacs -- indeed not reproducible

trying with my nasty one
http://git.onerussian.com/?p=etc/emacs.git;a=blob;hb=HEAD;f=.emacs
it is there

first time it splits (code into two) upon:

Debugger entered--returning value: #<window 3 on 1.py>
  selected-window()
* split-window-vertically()
* funcall(split-window-vertically)
* (progn (funcall py-split-windows-on-execute-function) (display-buffer py-buffer-name (quote display-buffer-reuse-window)))
* (if (< (count-windows) py-max-split-windows) (progn (funcall py-split-windows-on-execute-function) (display-buffer py-buffer-name ...)) (display-buffer py-buffer-name (quote display-buffer-reuse-window)))
* (cond ((and ... py-split-windows-on-execute-p ... ...) (when ... ...) (pop-to-buffer py-buffer-name) (display-buffer oldbuf)) ((and ... py-split-windows-on-execute-p ...) (if ... ... ...) (pop-to-buffer oldbuf)) ((or ... ...) (let ... ...)) ((or ... ...) (let ... ... ...)))
* py-shell-manage-windows(nil t #<buffer 1.py> "*ubp Python*")
  (if done nil (py-shell-manage-windows switch split oldbuf py-buffer-name))
  (unless done (py-shell-manage-windows switch split oldbuf py-buffer-name))

and then seems to be within (I pressed c too many times to point exactly I guess ):

Debugger entered--returning value: #<window 165 on *ubp Python*>
  display-buffer("*ubp Python*" display-buffer-reuse-window)
* (progn (funcall py-split-windows-on-execute-function) (display-buffer py-buffer-name (quote display-buffer-reuse-window)))
* (if (< (count-windows) py-max-split-windows) (progn (funcall py-split-windows-on-execute-function) (display-buffer py-buffer-name ...)) (display-buffer py-buffer-name (quote display-buffer-reuse-window)))
* (cond ((and ... py-split-windows-on-execute-p ... ...) (when ... ...) (pop-to-buffer py-buffer-name) (display-buffer oldbuf)) ((and ... py-split-windows-on-execute-p ...) (if ... ... ...) (pop-to-buffer oldbuf)) ((or ... ...) (let ... ...)) ((or ... ...) (let ... ... ...)))

yeap -- that is where 1 more split happens:

Debugger entered--returning value: #<window 91 on 1.py>
  funcall(split-window-sensibly #<window 8 on 1.py>)
* window--try-to-split-window(#<window 8 on 1.py>)
* byte-code(\206....
* display-buffer("*ubp Python*" display-buffer-reuse-window)

is it of any help? ;)

--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Ha...

Am 02.01.2013 22:39, schrieb Yaroslav Halchenko:
> On Wed, 02 Jan 2013, Andreas Roehler wrote:
>>> not sure if I should whine here or initiate a new report ;)
>> Hi, thanks for the reports. Providing separate reports might help.
>
> ok -- will do next time
>
>>> so, with 1165 rev, if I open a single buffer with .py file, set
>>> splitting to on (via toggle in the menu), press C-c ! -- I will get then
>>> 3 buffers: code buffer split into two, and then lower one with code
>>> split again to get also *IPython* one. Expected: 2 buffers (original
>>> code buffer + *IPython*).
>> can't get it for the moment, see png.
>> ** Attachment added: "ipython.png"
>> https://bugs.launchpad.net/bugs/1018996/+attachment/3472854/+files/ipython.png
>
> hm... it is even the same emacs version I have ;-)
>
> so -- tried with a clean .emacs -- indeed not reproducible

which indicates some mistake not in pyton-mode.el

>
> trying with my nasty one
> http://git.onerussian.com/?p=etc/emacs.git;a=blob;hb=HEAD;f=.emacs
> it is there
>
> first time it splits (code into two) upon:
>
> Debugger entered--returning value: #<window 3 on 1.py>
> selected-window()
> * split-window-vertically()
> * funcall(split-window-vertically)
> * (progn (funcall py-split-windows-on-execute-function) (display-buffer py-buffer-name (quote display-buffer-reuse-window)))
> * (if (< (count-windows) py-max-split-windows) (progn (funcall py-split-windows-on-execute-function) (display-buffer py-buffer-name ...)) (display-buffer py-buffer-name (quote display-buffer-reuse-window)))
> * (cond ((and ... py-split-windows-on-execute-p ... ...) (when ... ...) (pop-to-buffer py-buffer-name) (display-buffer oldbuf)) ((and ... py-split-windows-on-execute-p ...) (if ... ... ...) (pop-to-buffer oldbuf)) ((or ... ...) (let ... ...)) ((or ... ...) (let ... ... ...)))
> * py-shell-manage-windows(nil t #<buffer 1.py> "*ubp Python*")
> (if done nil (py-shell-manage-windows switch split oldbuf py-buffer-name))
> (unless done (py-shell-manage-windows switch split oldbuf py-buffer-name))
>
>
> and then seems to be within (I pressed c too many times to point exactly I guess ):
>
> Debugger entered--returning value: #<window 165 on *ubp Python*>
> display-buffer("*ubp Python*" display-buffer-reuse-window)
> * (progn (funcall py-split-windows-on-execute-function) (display-buffer py-buffer-name (quote display-buffer-reuse-window)))
> * (if (< (count-windows) py-max-split-windows) (progn (funcall py-split-windows-on-execute-function) (display-buffer py-buffer-name ...)) (display-buffer py-buffer-name (quote display-buffer-reuse-window)))
> * (cond ((and ... py-split-windows-on-execute-p ... ...) (when ... ...) (pop-to-buffer py-buffer-name) (display-buffer oldbuf)) ((and ... py-split-windows-on-execute-p ...) (if ... ... ...) (pop-to-buffer oldbuf)) ((or ... ...) (let ... ...)) ((or ... ...) (let ... ... ...)))
>
> yeap -- that is where 1 more split happens:
>
> Debugger entered--returning value: #<window 91 on 1.py>
> funcall(split-window-sensibly #<window 8 on 1.py>)
> * window--try-to-split-window(#<window 8 on 1.py>)
> * byte-code(\206....
> * display-buffer("*ubp Python*" display-buffer-reuse-wi...