GNU bug report logs - #7329
Fwd: 23.2; inferior-python-mode: completion does not work

Previous Next

Package: emacs;

Reported by: Андрей Парамонов <cmr.pent <at> gmail.com>

Date: Thu, 4 Nov 2010 17:09:02 UTC

Severity: normal

Tags: patch

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #14 received at 7329 <at> debbugs.gnu.org (full text, mbox):

From: Андрей Парамонов
	<cmr.pent <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: fx <at> gnu.org, 7329 <at> debbugs.gnu.org
Subject: Re: bug#7329: [Patch] Enable completion in inferior-python-mode
Date: Tue, 16 Nov 2010 11:41:59 +0300
2010/11/13 Stefan Monnier <monnier <at> 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




This bug report was last modified 12 years and 297 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.