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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I've managed to enable completion in Python interpreter buffer, patch
> attached. The change in python-check-comint-prompt also fixes
> completion in Python buffer when prompt in interpreter buffer is not
> clear (a command is entered but not yet executed).

> I didn't notice any regressions yet, but maybe the "\\="-thingy was
> actually meaning something :-)  Please review my patch, I'm ready to
> improve it if needed.

> Best wishes,
> Andrey Paramonov
> --- /home/pent/python.el.orig	2010-11-12 21:55:47.000000000 +0300
> +++ /home/pent/python.el	2010-11-12 21:51:26.000000000 +0300
> @@ -1412,6 +1412,8 @@
>    (set (make-local-variable 'comint-input-filter) 'python-input-filter)
>    (add-hook 'comint-preoutput-filter-functions #'python-preoutput-filter
>  	    nil t)
> +  (add-hook 'completion-at-point-functions
> +            'python-completion-at-point nil 'local)
>    ;; Still required by `comint-redirect-send-command', for instance
>    ;; (and we need to match things like `>>> ... >>> '):
>    (set (make-local-variable 'comint-prompt-regexp)
> @@ -1814,7 +1816,7 @@
>  information etc.  If PROC is non-nil, check the buffer for that process."
>    (with-current-buffer (process-buffer (or proc (python-proc)))
>      (save-excursion
> -      (save-match-data (re-search-backward ">>> \\=" nil t)))))
> +      (save-match-data (re-search-backward "^>>> " nil t)))))

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.
E.g. maybe we should use
(re-search-backward "^>>> " (line-beginning-position) t)
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.


        Stefan