From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Slawomir Nowaczyk Newsgroups: gmane.emacs.devel Subject: Re: python-mode: make sure output is not eaten Date: Tue, 22 Aug 2006 20:26:33 +0200 Message-ID: <20060822201045.4975.SLAWOMIR.NOWACZYK.847@student.lu.se> References: <20060821220052.494C.SLAWOMIR.NOWACZYK.847@student.lu.se> <87lkphe20n.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1156271696 19712 80.91.229.2 (22 Aug 2006 18:34:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2006 18:34:56 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 22 20:34:51 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GFb5O-0001HR-4v for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2006 20:34:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFaxs-0001iH-Ur for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2006 14:27:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GFaxc-0001el-0E for emacs-devel@gnu.org; Tue, 22 Aug 2006 14:26:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GFaxZ-0001dO-5J for emacs-devel@gnu.org; Tue, 22 Aug 2006 14:26:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFaxZ-0001dI-3B for emacs-devel@gnu.org; Tue, 22 Aug 2006 14:26:45 -0400 Original-Received: from [130.235.16.11] (helo=himmelsborg.cs.lth.se) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GFb5D-00082a-Q9 for emacs-devel@gnu.org; Tue, 22 Aug 2006 14:34:40 -0400 Original-Received: from [127.0.0.1] (slawek@dain [130.235.16.76]) by himmelsborg.cs.lth.se (8.13.6/8.13.6/perf-jw-tr) with ESMTP id k7MIQgbO021128 for ; Tue, 22 Aug 2006 20:26:42 +0200 (CEST) Original-To: emacs-devel@gnu.org In-Reply-To: <87lkphe20n.fsf-monnier+emacs@gnu.org> X-Esmandil_Citation: done X-Mailer-Plugin: Popup Memopad for Becky!2 Ver.0.02 Rev.2 X-Mailer: Becky! ver. 2.25.02 [en] 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:58735 Archived-At: On Tue, 22 Aug 2006 02:10:02 -0400 Stefan Monnier wrote: #> > the following path makes sure python-mode doesn't eat output coming #> > from the Python process. Without it, calling python-send-buffer on #> > a Python script which produces output, such as simple #> #> Does the patch below give good results as well? Not quite... I get the following error: error in process filter: Args out of range: ">>> >>> ", 22 It seems like this change is unnecessary: #> (cond ((and (string-match (rx string-start (repeat 3 (any ".>")) #> " " string-end) #> - s) #> + s start) as you setq `s' to the appropriate substring one line earlier, in (unless (zerop start) (setq s (substring s start))) Also, "\n\n" in python-send-string still needs to be changed into a single "\n" in order to avoid spurious prompts. Finally, when you test this patch, make sure you also try enabling eldoc-mode (it doesn't work too well, a patch to improve it a bit is forthcoming, but even now it works for built-in functions like "apply" or "map"). It is important to make sure no extra ">>>"s get added to the inferior buffer when eldoc is talking to Python process. This is -- partially -- the reason why it is important to save whatever text exists in front of "_emacs_out"... For example, when I python-send-buffer I can get output like "\nTest!\n>>> _emacs_out ()\n>>> "... and the ">>>" after "Test!" must show in the buffer. On the other hand, after eldoc asks Python about argument list, the output may look like this: "_emacs_out apply(object[, args[, kwargs]])\n>>> " and it is important that *nothing* is shown in the inferior buffer. The solution that seems easiest is to always eat the final prompt, but let the one in front of _emacs_out be printed. Anyway, the following patch, to be applied after yours, makes thing work OK for me: ********************************************************************** --- EmacsCVS/lisp/progmodes/python.el 2006-08-22 19:49:58.809940800 +0200 +++ Emacs/lisp/progmodes/python.el 2006-08-22 20:11:40.010976000 +0200 @@ -1274,14 +1274,15 @@ (when python-preoutput-continuation (funcall python-preoutput-continuation) (setq python-preoutput-continuation nil))) - ((string-match "\\`_emacs_out \\(.*\\)\n" line) - (setq python-preoutput-result (match-string 1 line))) + ((string-match "_emacs_out \\(.*\\)\n" line) + (setq python-preoutput-result (match-string 1 line)) + (setq res (concat res (substring line 0 (match-beginning 0))))) (t (setq res (concat res line)))))) ;; Then process the remaining partial line. (unless (zerop start) (setq s (substring s start))) (cond ((and (string-match (rx string-start (repeat 3 (any ".>")) " " string-end) - s start) + s); start) ;; Isn't that just (not (bolp)) ? --Stef (/= (let ((inhibit-field-text-motion t)) (line-beginning-position)) @@ -1416,7 +1417,7 @@ "Evaluate STRING in inferior Python process." (interactive "sPython command: ") (comint-send-string (python-proc) string) - (comint-send-string (python-proc) "\n\n")) + (comint-send-string (python-proc) "\n")) (defun python-send-buffer () "Send the current buffer to the inferior Python process." ********************************************************************** -- Best wishes, Slawomir Nowaczyk ( slawomir.nowaczyk.847@student.lu.se ) The Main Library at Indiana University sinks over an inch every year because when it was built, engineers failed to take into account the weight of all the books that would occupy the building.