From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#7329: [Patch] Enable completion in inferior-python-mode Date: Fri, 12 Nov 2010 16:35:46 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289861093 32032 80.91.229.12 (15 Nov 2010 22:44:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Nov 2010 22:44:53 +0000 (UTC) Cc: fx@gnu.org, 7329@debbugs.gnu.org To: =?UTF-8?Q?=D0=90=D0=BD=D0=B4=D1=80=D0=B5=D0=B9_?= =?UTF-8?Q?=D0=9F=D0=B0=D1=80=D0=B0=D0=BC=D0=BE=D0=BD=D0=BE=D0=B2?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 15 23:44:44 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PI7n1-0001Sz-PZ for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Nov 2010 23:44:44 +0100 Original-Received: from localhost ([127.0.0.1]:47626 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI7n1-0002az-8l for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Nov 2010 17:44:43 -0500 Original-Received: from [140.186.70.92] (port=53046 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI7ma-0002LM-Ga for bug-gnu-emacs@gnu.org; Mon, 15 Nov 2010 17:44:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PI7mZ-0000Fp-6A for bug-gnu-emacs@gnu.org; Mon, 15 Nov 2010 17:44:16 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PI7mZ-0000Fl-4m for bug-gnu-emacs@gnu.org; Mon, 15 Nov 2010 17:44:15 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PI7Ty-0004MV-DU; Mon, 15 Nov 2010 17:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Nov 2010 22:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7329 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 7329-submit@debbugs.gnu.org id=B7329.128985985116758 (code B ref 7329); Mon, 15 Nov 2010 22:25:02 +0000 Original-Received: (at 7329) by debbugs.gnu.org; 15 Nov 2010 22:24:11 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PI7T8-0004MF-EC for submit@debbugs.gnu.org; Mon, 15 Nov 2010 17:24:10 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PI7T7-0004M8-87 for 7329@debbugs.gnu.org; Mon, 15 Nov 2010 17:24:09 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQHADZD4UxFpY76/2dsb2JhbAChXX1ywRmFSgSEWo1f X-IronPort-AV: E=Sophos;i="4.59,202,1288584000"; d="scan'208";a="82628389" Original-Received: from 69-165-142-250.dsl.teksavvy.com (HELO ceviche.home) ([69.165.142.250]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 15 Nov 2010 17:29:06 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 40900663AE; Fri, 12 Nov 2010 16:35:46 -0500 (EST) In-Reply-To: ("=?UTF-8?Q?=D0=90=D0=BD=D0=B4=D1=80=D0=B5=D0=B9_?= =?UTF-8?Q?=D0=9F=D0=B0=D1=80=D0=B0=D0=BC=D0=BE=D0=BD=D0=BE=D0=B2?="'s message of "Fri, 12 Nov 2010 23:08:19 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 15 Nov 2010 17:25:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:41657 Archived-At: > 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