bug#18582: 24.4.50; [python.el] completion error

[Rasmus <rasmus@gmx.us>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> When I try to complete something in a python-buffer I get an error
>> with the below backtrace.  I couldn't find other reports on this
>> issue, but maybe I overlooked something?
>
> Could you try it with the code from the `emacs-24' branch instead?
> I tried your recipe and got a backtrace, but a different one.  I think
> I fixed it.

Okay, I changed my build-script to download from:

      http://bzr.savannah.gnu.org/r/emacs/emacs-24/

It was trunk at the end of the url before.  I don't know bzr well, so
I might have done something wrong.

If this means anything to you: 

(emacs-bzr-get-version) => "ueno@gnu.org-20141001022515-zphv3mmopxc6h5gs"

>>    write im 
>>    press M-Tab, should expand to import
>
> This now works for me now in `emacs-24'.

Not for me (using python3).

Backtrace:
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  buffer-substring-no-properties(nil 5)
  python-shell-completion-at-point(#<process Python>)
  python-completion-at-point()
  completion--capf-wrapper(python-completion-at-point all)
  run-hook-wrapped(completion--capf-wrapper python-completion-at-point all)
  completion-at-point()
  funcall-interactively(completion-at-point)
  call-interactively(completion-at-point nil nil)
  command-execute(completion-at-point)

>> Here's another backtrace.  To get it I do
>>        import num
>>        Press M-Tab, should expand to numpy
>
> In the new code in emacs-24, I don't get a backtrace for this one, but
> I also don't get any completion.  Fabián?

Numpy was a bad example as it's an external library.

I get completion in my file-buffer, not in the shell-buffer.  I guess
that's another bug in itself.  Maybe that's why we are seeing
different things.

Here's when I try to expand datetime, which should be Python-core

import datet [TAB]

Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  buffer-substring-no-properties(nil 13)
  python-shell-completion-at-point(#<process Python>)
  python-completion-at-point()
  completion--capf-wrapper(python-completion-at-point all)
  run-hook-wrapped(completion--capf-wrapper python-completion-at-point all)
  completion-at-point()
  funcall-interactively(completion-at-point)
  call-interactively(completion-at-point nil nil)
  command-execute(completion-at-point)


This is the backtrace is identical when I use python2.

I could try to step through `python-shell-completion-at-point' to get
a better understanding of where the bug is from.

—Rasmus

-- 
When the facts change, I change my mind. What do you do, sir?