Current bzr head always pops up the *Python3* buffer when you find-file a .py file

[Barry Warsaw]

Subject pretty much says it all.

[Barry Warsaw (barry)]

I'm reopening this because I don't think bzr head is fixed. I'm running bzr head and still getting this behavior, e.g. when I revert-buffer. But maybe the fix isn't on bzr trunk, in which case, this is a plea to back port it (or maybe tell me a better branch to be running from with a view toward releasing in Debian).

[Andreas Roehler (a-roehler)]

Hmm, don't get it. May you send some example code, which triggers the bug?

[Barry Warsaw (barry)]

On Nov 17, 2012, at 08:45 AM, Andreas Roehler wrote:

>Hmm, don't get it. May you send some example code, which triggers the
>bug?

It's fairly simple.

-----/tmp/foo.py
#!/usr/bin/python3
-----/tmp/foo.py

The first time you visit the file and type this in, you will not get the extra
buffer. Then type C-M-r (or M-x revert-buffer). The buffer is reloaded and
the *ubp Python3* buffer pops up too.

[Andreas Roehler (a-roehler)]

not here. I'll repair the python-mode bug-report mailer. Make them report the var settings. Afterwards it should be visible whats on.

[Barry Warsaw (barry)]

I've done a little bit of tracing. The problem definitely occurs in py-shell-manage-windows which is called from py-shell in turn called from python-mode. Even though the py-shell call is wrapped in a save-excursion, once you enter py-shell-manage-windows, the buffer pops up and does not get hidden.

I haven't had time to trace py-shell-manage-windows yet. Maybe the above is enough to give you a hint as to the problem.

FWIW, I'm on Ubuntu Raring, Emacs version 23.4.1

[Andreas Roehler (a-roehler)]

last commit includes some changes here and around

[Andreas Roehler (a-roehler)]

Am 15.10.2012 19:52, schrieb Barry Warsaw:
> Public bug reported:
>

Hi Barry,

do you get this still?

The last remaining major issue before release 6.1.0 AFAIS.

Cheers,

Andreas

[Barry Warsaw (barry)]

On Nov 25, 2012, at 03:21 PM, Andreas Roehler wrote:

>do you get this still?
>
>The last remaining major issue before release 6.1.0 AFAIS.

Yes, it still happens.

Tracing py-shell-manage-windows, I end up in this section:

         (if (< (count-windows) py-max-split-windows)
             (progn
               (funcall py-split-windows-on-execute-function)
               (display-buffer py-buffer-name 'display-buffer-reuse-window))
           (display-buffer py-buffer-name 'display-buffer-reuse-window)))

(count-windows) -> 1
py-max-split-windows -> 2

so, it goes on to call py-split-windows-on-execute-function which is set to
split-windows-vertically. So the window gets split, and the *Python3* buffer
gets displayed in the lower window.

[Andreas Roehler (a-roehler)]

Am 25.11.2012 18:39, schrieb Barry Warsaw:
> On Nov 25, 2012, at 03:21 PM, Andreas Roehler wrote:
>
>> do you get this still?
>>
>> The last remaining major issue before release 6.1.0 AFAIS.
>
> Yes, it still happens.
>
> Tracing py-shell-manage-windows, I end up in this section:
>
> (if (< (count-windows) py-max-split-windows)
> (progn
> (funcall py-split-windows-on-execute-function)
> (display-buffer py-buffer-name 'display-buffer-reuse-window))
> (display-buffer py-buffer-name 'display-buffer-reuse-window)))
>
> (count-windows) -> 1
> py-max-split-windows -> 2
>
> so, it goes on to call py-split-windows-on-execute-function which is set to
> split-windows-vertically. So the window gets split, and the *Python3* buffer
> gets displayed in the lower window.
>

what is the command used before?

should not happen, if py-split-windows-on-execute-p is nil

[Barry Warsaw (barry)]

On Nov 25, 2012, at 07:26 PM, Andreas Roehler wrote:

>what is the command used before?

C-x 4 f /tmp/foo.py RET

>should not happen, if py-split-windows-on-execute-p is nil

It's set to t for me (supposedly the default value).

I don't really understand what the variable is supposed to control:

"""
Documentation:
When non-nil split windows.
"""

Setting this to nil seems to have other bad consequences.

* Let's say I'm visiting python-mode.el in the only window in the frame.
  C-x 4 f /tmp/foo.py RET

  Now I have two windows in the frame, both of which are visiting foo.py

* Bring up just one window visiting foo.py and hit C-c ! (py-shell). No shell
  buffer shows up.

* Bring up two windows in the frame. The top one is visiting the empty
  foo.py, the second one is your *Python3* buffer. Now hit `C-c !`. I see a
  prompt show up in the *Python3* buffer, but whatever is running in the
  *Python3* buffer is just hanging the process. Not even C-c C-c seems to
  bring the process back.

[Andreas Roehler (a-roehler)]

Presently py-start-run-py-shell defaults to non-nil. Wil change it to nil.