From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Julian Scheid Newsgroups: gmane.emacs.devel Subject: Re: python-try-complete Date: Mon, 14 Apr 2008 23:05:59 +1200 Message-ID: <48033A97.8050208@gmail.com> References: <47F62CE4.7070903@gmail.com> <4800885A.1090402@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1208171218 31964 80.91.229.12 (14 Apr 2008 11:06:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Apr 2008 11:06:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 14 13:07:26 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JlMWi-0004D7-Fm for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 13:07:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlMW4-00084U-72 for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 07:06:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JlMVt-00080h-7S for emacs-devel@gnu.org; Mon, 14 Apr 2008 07:06:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JlMVr-0007xs-TO for emacs-devel@gnu.org; Mon, 14 Apr 2008 07:06:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlMVr-0007xW-O3 for emacs-devel@gnu.org; Mon, 14 Apr 2008 07:06:15 -0400 Original-Received: from wf-out-1314.google.com ([209.85.200.172]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JlMVr-0001cf-5w for emacs-devel@gnu.org; Mon, 14 Apr 2008 07:06:15 -0400 Original-Received: by wf-out-1314.google.com with SMTP id 29so1528748wff.24 for ; Mon, 14 Apr 2008 04:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=Xj0SCUv/ms9ZBdcZy97fplUYllL1kS8tMp6us+N/L4U=; b=AFOgaJP6TELSSdnJl6On9MClUxhkSTSRiD4e8cme5qOMriQExcUiwZWNdaGylLuqz7P52PVIcWocin/6t/LR7WAlME9Ixn7nsYyghFUeUmHd99NXcdnNILdOsPjMNfs2vKjQ639UrF6ZJ5I7xbUtkcjyu9i6clKEohuFWkI4XrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=M8duUGYQwlMI0bZO0v+D7nDAOrEx8DrWogVqoRChVktlqNV0AiQVPI362ksv84QohP3pzpR1xrdrlfj8FYwAD2M3poBPa25Zcfr4dVaJbGI6kcWcgcwe+mDnGah+FEQ9Yxj/3NJqewy/Ri8T5yfd2YRm2NKTQr6DCwXyN7yE0jw= Original-Received: by 10.142.71.9 with SMTP id t9mr878566wfa.246.1208171168207; Mon, 14 Apr 2008 04:06:08 -0700 (PDT) Original-Received: from tun0.core.adl.rsp.com.au ( [203.0.153.46]) by mx.google.com with ESMTPS id 30sm11557523wff.11.2008.04.14.04.06.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Apr 2008 04:06:06 -0700 (PDT) User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) In-Reply-To: <4800885A.1090402@gmail.com> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:95173 Archived-At: > Did you have any thoughts about the second problem I described in the > same mail - python-try-complete locking up when used in a remote buffer? > To quote from my previous mail, > > Either python-try-complete should refrain from launching the process > remotely by looking at (file-remote-p default-directory), or the > scripts it launches need to be prepared (e.g. in terms of quoting) for > being run remotely via ssh. I had a chance to narrow it down a bit more. Here is the stack trace I get when I quit while python-try-complete blocks: Debugger entered--Lisp error: (quit) accept-process-output(# 5) python-send-receive("import emacs; print '_emacs_out ()'") run-python(nil t) python-proc() python-send-string("emacs.complete(\"exitCode\",\"import os\\nimport logging\\nimport Queue\\nimport threading\\n\")") python-send-receive("emacs.complete(\"exitCode\",\"import os\\nimport logging\\nimport Queue\\nimport threading\\n\")") byte-code("..." [symbol python-imports read-from-string python-send-receive format "emacs.complete(%S,%s)"] 6) python-symbol-completions("exitCode") (and symbol (python-symbol-completions symbol)) (setq he-expand-list (and symbol (python-symbol-completions symbol))) (let ((symbol ...)) (he-init-string (- ... ...) (point)) (if (not ...) (push he-search-string he-tried-table)) (setq he-expand-list (and symbol ...))) (if old nil (let (...) (he-init-string ... ...) (if ... ...) (setq he-expand-list ...))) (unless old (let (...) (he-init-string ... ...) (if ... ...) (setq he-expand-list ...))) (progn (unless old (let ... ... ... ...)) (while (and he-expand-list ...) (pop he-expand-list)) (if he-expand-list (progn ... t) (if old ...) nil)) (if (derived-mode-p (quote python-mode)) (progn (unless old ...) (while ... ...) (if he-expand-list ... ... nil))) (when (derived-mode-p (quote python-mode)) (unless old (let ... ... ... ...)) (while (and he-expand-list ...) (pop he-expand-list)) (if he-expand-list (progn ... t) (if old ...) nil)) python-try-complete(nil) apply(python-try-complete nil) hippie-expand(nil) call-interactively(hippie-expand) And in *Python* I have: Python 2.3.4 (#1, Feb 2 2005, 12:11:53) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Traceback (most recent call last): File "", line 1, in ? ImportError: No module named emacs >>> Now the interesting thing with the second line of this output is that my Emacs is running on top of OS X; Linux is running on the box on which the Python file lives that I've opened using Tramp (that was visited when I ran hippie-expand.) So apparently Python gets run remotely (by the magic of Tramp?) but the "emacs" package which I suspect python-mode uses for helping with completion isn't available on the remote host; thus the whole completion attempt fails, but instead of gracefully failing python-try-complete sits there indefinitely. There seem to be two problems here: 1) Proper exception and/or exit code handling is missing which would allow the Python script to exit with an error without locking up Emacs. 2) Either the external Python process should be forced to run locally even if the file is remote; or python-try-complete should refrain from launching a Python process at all if the file is remote; or python-try-complete should be prepared for its external process to run remotely and set up its environment properly (by uploading the emacs module and setting PYTHONPATH accordingly.) As I said earlier I don't use python-try-complete anymore but FWIW simply not running Python when file-remote-p looks to me to be the best option. I'm using Emacs 22.1.2 and tramp 2.1.13. Hope this helps, Julian