bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

1. emacs -q
2. M-x python-mode
3. C-c C-z
4. M-: (python-symbol-completions "s")

repeat step 4 a few times and you should notice the following
alternating results:

("setdefault" "sys")
nil
("setdefault" "sys")
nil
......

I wonder if this can be fixed before releasing emacs 24.1.

Tested on GNU Emacs 24.0.92.1 (i386-apple-darwin10.8.0, X toolkit) of 2011-12-14

I cannot reproduce this on a GNU/Linux host.

Regards,
Leo

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

The bug seems to be due to the following change:

Author: Chong Yidong <cyd@stupidchicken.com>
Date:   Sun Nov 21 12:04:43 2010 -0500

    Backport fixes for Bug#5390 and Bug#5694 from trunk.
    
    * progmodes/python.el: Add Ipython support (Bug#5390).
    (python-shell-prompt-alist)
    (python-shell-continuation-prompt-alist): New options.
    (python--set-prompt-regexp): New function.
    (inferior-python-mode, run-python, python-shell): Require
    ansi-color.  Use python--set-prompt-regexp to set the comint
    prompt based on the Python interpreter.
    (python--prompt-regexp): New var.
    (python-check-comint-prompt)
    (python-comint-output-filter-function): Use it.
    (run-python): Use a pipe (Bug#5694).

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> 1. emacs -q
> 2. M-x python-mode
> 3. C-c C-z
> 4. M-: (python-symbol-completions "s")
>
> repeat step 4 a few times and you should notice the following
> alternating results:
>
> ("setdefault" "sys")
> nil
> ("setdefault" "sys")
> nil

Hmm, I can't reproduce this on GNU/Linux.  The result of
python-symbol-completions is always ("setdefault" "sys").

OTOH, I don't see how the fixes to Bug#5390 or Bug#5694 would cause this
problem, either.

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]

On 2012-01-27 16:03 +0800, Chong Yidong wrote:
> Hmm, I can't reproduce this on GNU/Linux.  The result of
> python-symbol-completions is always ("setdefault" "sys").

On OSX, a build with X11 can reproduce the bug too.

I run (python-symbol-completions "s") 4 times in a session started with
`emacs -q -nw' (24.0.92) and see this:


[-- Attachment #2: *message*.png --]
[-- Type: image/png, Size: 8839 bytes --]

[-- Attachment #3: *python*.png --]
[-- Type: image/png, Size: 18151 bytes --]

[-- Attachment #4: Type: text/plain, Size: 234 bytes --]


> OTOH, I don't see how the fixes to Bug#5390 or Bug#5694 would cause this
> problem, either.

Empirically speaking, I have been using python.el with that commit
reverted for some months now and have no trouble with completion.

Leo

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On 2012-01-27 16:03 +0800, Chong Yidong wrote:
> Hmm, I can't reproduce this on GNU/Linux.  The result of
> python-symbol-completions is always ("setdefault" "sys").

There are some difference on GNU/Linux and OSX regarding
process-send-string that causes the failure.

1. emacs -q
2. M-x comint-run RET python RET
3. M-: (process-send-string nil "import sys\n")

On GNU/Linux, `import sys\n' is not printed in the *python* buffer but
on OSX with the stock python, it is. See the attached screenshots. This
extra echoing is only with the python interpreter built by Apple.


[-- Attachment #2: proc-osx.png --]
[-- Type: image/png, Size: 21493 bytes --]

[-- Attachment #3: proc-gnu.png --]
[-- Type: image/png, Size: 16442 bytes --]

[-- Attachment #4: Type: text/plain, Size: 5 bytes --]


Leo

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> There are some difference on GNU/Linux and OSX regarding
> process-send-string that causes the failure.
>
> 1. emacs -q
> 2. M-x comint-run RET python RET
> 3. M-: (process-send-string nil "import sys\n")
>
> On GNU/Linux, `import sys\n' is not printed in the *python* buffer but
> on OSX with the stock python, it is.

What are the tty settings in both cases?  (I see -echo, which is what
child_setup_tty actually does.)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

On 2012-04-17 16:34 +0800, Andreas Schwab wrote:
> What are the tty settings in both cases?  (I see -echo, which is what
> child_setup_tty actually does.)
>
> Andreas.

`stty -a' outputs:

OSX
=====

speed 9600 baud; 48 rows; 179 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
	-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
	-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -iutf8
	-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
	-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
	min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
	stop = ^S; susp = ^Z; time = 0; werase = ^W;

GNU/L
=====

speed 9600 baud; rows 48; columns 179; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe -echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> speed 9600 baud; rows 48; columns 179; line = 0;

Are you sure you used the right tty?  Ptys normally have 38400 baud.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

On 2012-04-17 23:21 +0800, Andreas Schwab wrote:
> Are you sure you used the right tty?  Ptys normally have 38400 baud.

I just went over to my G/L machine and yes it is 38400 but on OSX it is
9600. In my tests, I sshed to G/L machine.

Leo

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> On 2012-04-17 23:21 +0800, Andreas Schwab wrote:
>> Are you sure you used the right tty?  Ptys normally have 38400 baud.
>
> I just went over to my G/L machine and yes it is 38400

So please show the settings of the right tty.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

On 2012-04-18 15:22 +0800, Andreas Schwab wrote:
> So please show the settings of the right tty.

OK. BTW if I compile python from upstream source, it doesn't exhibit
this bug.

In GNU/Linux:

speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> On 2012-04-18 15:22 +0800, Andreas Schwab wrote:
>> So please show the settings of the right tty.
>
> OK. BTW if I compile python from upstream source, it doesn't exhibit
> this bug.
>
> In GNU/Linux:
>
> speed 38400 baud; rows 24; columns 80; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
> swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
> lnext = ^V; flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
> -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
> -iuclc ixany imaxbel iutf8
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt

Who is setting echo?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

On 2012-04-18 19:23 +0800, Andreas Schwab wrote:
> Who is setting echo?

I have no idea; I am using whatever is default in the system. How to
find out who?

Leo

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Andreas Schwab]

Try running python in a terminal with echo disabled.  If you see your
input echoed then you have a faulty python.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

On 2012-04-19 00:47 +0800, Andreas Schwab wrote:
> Try running python in a terminal with echo disabled.  If you see your
> input echoed then you have a faulty python.
>
> Andreas.

I tried

1. stty -echo
2. /usr/bin/python

after this echo is enabled.

So seems apple python is faulty.

Leo

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

On 2012-04-19 00:47 +0800, Andreas Schwab wrote:
> Try running python in a terminal with echo disabled.  If you see your
> input echoed then you have a faulty python.

Looks like everything linked with libedit on BSD has this issue:
http://article.gmane.org/gmane.comp.python.apple/17984

Leo

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Leo]

On 2012-04-19 02:52 +0800, Leo wrote:
> Looks like everything linked with libedit on BSD has this issue:
> http://article.gmane.org/gmane.comp.python.apple/17984

Now that we have identified the problem. How best to work around this
bug given libedit might be common in all BSD systems?

Leo

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Fabián Ezequiel Gallina]

Can someone using OSX try if this is still happening with current trunk?

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Jan Djärv]

Hello.

7 okt 2012 kl. 18:39 skrev Fabián Ezequiel Gallina <fabian@anue.biz>:

> Can someone using OSX try if this is still happening with current trunk?
> 

python-symbol-completions is not defined.
The discussion points to libedit which is not part of Emacs, so I guess the error remains.

	Jan D.

bug#10295: 24.0.92; Python completion fails on OSX (10.6.8)

[Jan Djärv]

Hello again.

However, complete-symbol works, but gives the extra '^M as I showed in bug 12409.

	Jan D.

7 okt 2012 kl. 19:59 skrev Jan Djärv <jan.h.d@swipnet.se>:

> Hello.
> 
> 7 okt 2012 kl. 18:39 skrev Fabián Ezequiel Gallina <fabian@anue.biz>:
> 
>> Can someone using OSX try if this is still happening with current trunk?
>> 
> 
> python-symbol-completions is not defined.
> The discussion points to libedit which is not part of Emacs, so I guess the error remains.
> 
> 	Jan D.
>