bug#7329: [Patch] Enable completion in inferior-python-mode

["Андрей Парамонов" <cmr.pent@gmail.com>]

2010/11/13 Stefan Monnier <monnier@iro.umontreal.ca>:
> That patch doesn't look bad at all.  The \\= construct means "match
> point", i.e. (re-search-backward ">>> \\=" nil t) is very much like
> (looking-back ">>> ").  So if that doesn't work it's probably because
> there is text between the ">>> " prompt and point.
> Do you happen to know what that text is, so we can assess whether we can
> just plainly ignore it as you do, or whether there's more to it.

The text between >>> and point is what I'm going to complete. I think
it can be anything.

> E.g. maybe we should use
> (re-search-backward "^>>> " (line-beginning-position) t)

Good idea. I missed that re-search-backward jumps over linebreaks by
default. Thinking a bit more, (re-search-backward "^\(>>>|...\) "
(line-beginning-position) t) is even better as it allows completion
inside loops.

> so that we won't be searching back for umpteen megabytes of output until
> we accidentally find some unrelated prompt.
> Then again, maybe the issue is simply that since we're always in the
> process-buffer in the first place, point is not at the expected place
> (the code currently expects point to stay put right after the prompt,
> whereas in the inferior-python case point may have simply been pushed
> down by the process's output), in which case the right solution may be
> to explicitly store the earlier position of point and don't expect that
> (with-current-buffer (process-buffer (or proc (python-proc))) will
> automatically place us back at the same position.
>

My understanding about these checks is to avoid interacting with
interpreter while we at something like

while True:
    pass

or just doing a long processing. For completion we are using the same
interpreter. Requesting completion would freeze Emacs in such a case.

Thanks for your support,
Andrey Paramonov