An Emacs mode for editing Python code

In "split-windows-on-execute" starts 1 more python to additional ipython shell

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

so I have a .py file loaded, and *IPython* visible (py-shell-name globally "ipython"). Now if I C-c C-c -- I get 1 more buffer with a Python shell, while code correctly executed in *Ipython" (remains visible, *Python* buffer is added in additional split)

FWIW: latest lines in Messages

py-shell-switch-buffers-on-execute: t
Wrote /home/yoh/.tmp/ipython-22782F8D.py
py-shell-switch-buffers-on-execute: nil
py-split-windows-on-execute-p: t
Wrote /home/yoh/.tmp/ipython-22782SGK.py
Wrote /home/yoh/.tmp/ipython-22782fQQ.py
Wrote /home/yoh/.tmp/ipython-22782saW.py
Buffer has a running process; kill it? (y or n) # That is where I forced to kill that additional *Python* buffer
Wrote /home/yoh/.tmp/ipython-227825kc.py
byte-code: End of buffer

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

Am 01.11.2012 15:53, schrieb Yaroslav Halchenko:
> Public bug reported:
>
> so I have a .py file loaded, and *IPython* visible (py-shell-name
> globally "ipython"). Now if I C-c C-c -- I get 1 more buffer with a
> Python shell, while code correctly executed in *Ipython" (remains
> visible, *Python* buffer is added in additional split)
>
> FWIW: latest lines in Messages
>
> py-shell-switch-buffers-on-execute: t
> Wrote /home/yoh/.tmp/ipython-22782F8D.py
> py-shell-switch-buffers-on-execute: nil
> py-split-windows-on-execute-p: t
> Wrote /home/yoh/.tmp/ipython-22782SGK.py
> Wrote /home/yoh/.tmp/ipython-22782fQQ.py
> Wrote /home/yoh/.tmp/ipython-22782saW.py
> Buffer has a running process; kill it? (y or n) # That is where I forced to kill that additional *Python* buffer
> Wrote /home/yoh/.tmp/ipython-227825kc.py
> byte-code: End of buffer
>
> ** Affects: python-mode
> Importance: Undecided
> Status: New
>

can't reproduce.
Please send some example code which triggers the bug.

thanks,

Andreas

Yaroslav Halchenko (yarikoptic) wrote :

well -- for me, in that instance of emacs (with bulk of other things
loaded) it happens with any file, e.g.

print "HELLO"

I now tried to start with an absent .emacs and then load
python-mode.el and then such a rudimentary 1.py -- now getting "File
mode ..." error and C-c C-c doesn't work at all due to "let: Wrong type
argument: stringp, nil" :-/

Loading /home/yoh/deb/gits/python-mode.bzr2/python-mode.el
(source)...done
File mode specification error: (wrong-type-argument stringp nil)

:-/

On Thu, 01 Nov 2012, Andreas Roehler wrote:

> can't reproduce.
> Please send some example code which triggers the 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 01.11.2012 19:34, schrieb Yaroslav Halchenko:
> well -- for me, in that instance of emacs (with bulk of other things
> loaded) it happens with any file, e.g.
>
> print "HELLO"
>
> I now tried to start with an absent .emacs and then load
> python-mode.el and then such a rudimentary 1.py -- now getting "File
> mode ..." error and C-c C-c doesn't work at all due to "let: Wrong type
> argument: stringp, nil" :-/
>
> Loading /home/yoh/deb/gits/python-mode.bzr2/python-mode.el
> (source)...done
> File mode specification error: (wrong-type-argument stringp nil)
>
> :-/
>

strange..

maybe lets try the following.

emacs -Q
load python-mode.el
load your example.py
C-c C-c
M-x report-emacs-bug

please send the output then

Yaroslav Halchenko (yarikoptic) wrote :
Download full text (10.2 KiB)

On Thu, 01 Nov 2012, Andreas Roehler wrote:

> Am 01.11.2012 19:34, schrieb Yaroslav Halchenko:
> > well -- for me, in that instance of emacs (with bulk of other things
> > loaded) it happens with any file, e.g.

> > print "HELLO"

> > I now tried to start with an absent .emacs and then load
> > python-mode.el and then such a rudimentary 1.py -- now getting "File
> > mode ..." error and C-c C-c doesn't work at all due to "let: Wrong type
> > argument: stringp, nil" :-/

> > Loading /home/yoh/deb/gits/python-mode.bzr2/python-mode.el
> > (source)...done
> > File mode specification error: (wrong-type-argument stringp nil)

> > :-/

> strange..

> maybe lets try the following.

> emacs -Q
> load python-mode.el
> load your example.py

got

File mode specification error: (wrong-type-argument stringp nil)

upon loading 1.py

> C-c C-c

The same

> M-x report-emacs-bug
> please send the output then

In GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-04-07 on trouble, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
configured using `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.4/site-lisp:/usr/share/emacs/site-lisp' '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -DDEBIAN -O2' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: ru_RU.UTF-8
  value of $LC_NUMERIC: ru_RU.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Py

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x l o a d - l i v <backspace> b r <tab> <return>
<help-echo> <S-insert> <return> C-x C-f / t m p / 1
. p y <return> C-x 2 C-x o C-x b <return> C-x b * M
e <tab> <return> <help-echo> <down-mouse-1> <mouse-movement>
<mouse-movement> <drag-mouse-1> <help-echo> <down-mouse-1>
<mouse-1> C-c C-c <help-echo> M-x r e p o r t - e m
<tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading /home/yoh/deb/gits/python-mode.bzr2/python-mode.el (source)...done
File mode specification error: (wrong-type-argument stringp nil)
let: Wrong type argument: stringp, nil

Load-path shadows:
...

Andreas Roehler (a-roehler) wrote :
Download full text (10.3 KiB)

Am 01.11.2012 20:42, schrieb Yaroslav Halchenko:
> On Thu, 01 Nov 2012, Andreas Roehler wrote:
>
>> Am 01.11.2012 19:34, schrieb Yaroslav Halchenko:
>>> well -- for me, in that instance of emacs (with bulk of other things
>>> loaded) it happens with any file, e.g.
>
>>> print "HELLO"
>
>>> I now tried to start with an absent .emacs and then load
>>> python-mode.el and then such a rudimentary 1.py -- now getting "File
>>> mode ..." error and C-c C-c doesn't work at all due to "let: Wrong type
>>> argument: stringp, nil" :-/
>
>>> Loading /home/yoh/deb/gits/python-mode.bzr2/python-mode.el
>>> (source)...done
>>> File mode specification error: (wrong-type-argument stringp nil)
>
>>> :-/
>
>
>> strange..
>
>> maybe lets try the following.
>
>> emacs -Q
>> load python-mode.el
>> load your example.py
>
> got
>
> File mode specification error: (wrong-type-argument stringp nil)
>
> upon loading 1.py
>
>> C-c C-c
>
> The same
>
>> M-x report-emacs-bug
>> please send the output then
>
>
> In GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10)
> of 2012-04-07 on trouble, modified by Debian
> Windowing system distributor `The X.Org Foundation', version 11.0.11203000
> configured using `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.4/site-lisp:/usr/share/emacs/site-lisp' '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -DDEBIAN -O2' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''
>
> Important settings:
> value of $LC_ALL: nil
> value of $LC_COLLATE: en_US.UTF-8
> value of $LC_CTYPE: en_US.UTF-8
> value of $LC_MESSAGES: en_US.UTF-8
> value of $LC_MONETARY: ru_RU.UTF-8
> value of $LC_NUMERIC: ru_RU.UTF-8
> value of $LC_TIME: en_US.UTF-8
> value of $LANG: en_US
> value of $XMODIFIERS: nil
> locale-coding-system: utf-8-unix
> default enable-multibyte-characters: t
>
> Major mode: Py
>
> Minor modes in effect:
> shell-dirtrack-mode: t
> tooltip-mode: t
> mouse-wheel-mode: t
> tool-bar-mode: t
> menu-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
> line-number-mode: t
> transient-mark-mode: t
>
> Recent input:
> M-x l o a d - l i v <backspace> b r <tab> <return>
> <help-echo> <S-insert> <return> C-x C-f / t m p / 1
> . p y <return> C-x 2 C-x o C-x b <return> C-x b * M
> e <tab> <return> <help-echo> <down-mouse-1> <mouse-movement>
> <mouse-movement> <drag-mouse-1> <help-echo> <down-mouse-1>
> <mouse-1> C-c C-c <help-echo> M-x r e p o r t - e m
> <tab> <return>
>
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Loading...

Yaroslav Halchenko (yarikoptic) wrote :

On Thu, 01 Nov 2012, Andreas Roehler wrote:
> > make-network-process dbusbind system-font-setting font-render-setting
> > gtk x-toolkit x multi-tty emacs)

> sure you started from emacs -Q (capital letter Q)?
> it should not load the site-lisp stuff AFAIU

positive... here is also some kind of a proof:

$> strace emacs -Q 2>&1 | grep site-lisp 2>&1 | grep -v -e ENOENT | head -10
access("/usr/local/share/emacs/23.4/site-lisp", F_OK) = 0
access("/usr/local/share/emacs/site-lisp", F_OK) = 0
access("/usr/share/emacs/23.4/site-lisp", F_OK) = 0
access("/usr/share/emacs/site-lisp", F_OK) = 0
stat("/usr/share/emacs/23.4/site-lisp/subdirs.el", {st_mode=S_IFREG|0644, st_size=106, ...}) = 0
open("/usr/share/emacs/23.4/site-lisp/subdirs.el", O_RDONLY) = 3
stat("/usr/share/emacs/23.4/site-lisp/subdirs.el", {st_mode=S_IFREG|0644, st_size=106, ...}) = 0
open("/usr/share/emacs/23.4/site-lisp/subdirs.el", O_RDONLY) = 3
stat("/usr/share/emacs/23.4/site-lisp/subdirs.el", {st_mode=S_IFREG|0644, st_size=106, ...}) = 0
open("/usr/share/emacs/23.4/site-lisp/subdirs.el", O_RDONLY) = 3

also this issue -- seems to be quite nasty to replicate -- here is my
protocol of struggle:

just redid emacs start with -Q and site-lisp is there

more of a miracle for me was to see
Loading /home/yoh/deb/gits/python-mode.bzr2/python-mode.el (source)...done
when I opened 1.py since I had no ~/.emacs and was not in that directory ...

so I asked WTF and then ran

strace -fF -o /tmp/11 emacs -Q

and then when I opened /tmp/1.py it opened in Python (emacs-provided) not Py mode... WTF?

I have restarted clean with emacs -Q, loaded python-mode.el, opened
/tmp/1.py and no errors were reported, and I could C-c C-c ... !!!

how and why all the above? I do not know... may be there are side-effects of
emacs accessing those .saves-* files, like this recent one:

$> cat /home/yoh/.emacs.d/auto-save-list/.saves-22782-novo~
/tmp/1.py
/tmp/#1.py#
/home/yoh/proj/pymvpa/pymvpa/mvpa2/datasets/base.py
/home/yoh/proj/pymvpa/pymvpa/mvpa2/datasets/#base.py#
/home/yoh/proj/pymvpa/pymvpa/mvpa2/base/collections.py
/home/yoh/proj/pymvpa/pymvpa/mvpa2/base/#collections.py#
/home/yoh/deb/gits/python-mode.bzr2/python-mode.el
/home/yoh/deb/gits/python-mode.bzr2/#python-mode.el#

/home/yoh/proj/pymvpa/pymvpa/#%2Ascratch%2A#22782Ulo#

ok -- removed all of them, started regularly with emacs and the bug is
back!

Loading /home/yoh/deb/gits/python-mode.bzr2/python-mode.el (source)...done
File mode specification error: (wrong-type-argument stringp nil)

restarted emacs -Q, opened /tmp/1.py in built-in Python mode, load-library python-mode.el, closed 1.py, reopened it -- fails with the above...

restarted again with emacs -Q, load-library python-mode.el, opened 1.py -- error again

I am resting here
--
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 :

as for strace, don't think you may conclude from 'open' or 'access' it's loaded into the Emacs lisp space.

from info:

`-Q'
`--quick'
     Start emacs with minimum customizations. This is similar to using
     `-q', `--no-site-file', `--no-site-lisp', and `--no-splash'
     together. This also stops Emacs from processing X resources by
     setting `inhibit-x-resources' to `t' (*note Resources::).

Which doesn't mean other operations preparing the session aren't done.

Maybe set (debug-on-error t), (debug-on-quit t) and post the output again.

Changed in python-mode:
status: New → 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