From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: python-mode: make sure output is not eaten Date: Wed, 23 Aug 2006 00:04:40 -0400 Message-ID: <87sljo40ra.fsf-monnier+emacs@gnu.org> References: <20060821220052.494C.SLAWOMIR.NOWACZYK.847@student.lu.se> <87lkphe20n.fsf-monnier+emacs@gnu.org> <20060822201045.4975.SLAWOMIR.NOWACZYK.847@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1156456168 6234 80.91.229.2 (24 Aug 2006 21:49:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2006 21:49:28 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 23:49:21 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 1GGN4i-0005Sh-43 for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2006 23:49:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGN4h-0002OM-Bo for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2006 17:49:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GGN4U-0002MY-Bi for emacs-devel@gnu.org; Thu, 24 Aug 2006 17:49:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GGN4R-0002ID-Lc for emacs-devel@gnu.org; Thu, 24 Aug 2006 17:49:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGN4R-0002Hy-HL for emacs-devel@gnu.org; Thu, 24 Aug 2006 17:49:03 -0400 Original-Received: from [209.226.175.34] (helo=tomts13-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GGNCZ-0000ZT-W4 for emacs-devel@gnu.org; Thu, 24 Aug 2006 17:57:28 -0400 Original-Received: from alfajor ([70.55.147.36]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060824214901.KNVF29052.tomts13-srv.bellnexxia.net@alfajor> for ; Thu, 24 Aug 2006 17:49:01 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id 2D96E1CD41; Wed, 23 Aug 2006 00:04:40 -0400 (EDT) Original-To: Slawomir Nowaczyk In-Reply-To: <20060822201045.4975.SLAWOMIR.NOWACZYK.847@student.lu.se> (Slawomir Nowaczyk's message of "Tue, 22 Aug 2006 20:26:33 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:58834 Archived-At: > #> (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=20 > (unless (zerop start) (setq s (substring s start))) Oh, right. I missed this one spot, sorry. > Also, "\n\n" in python-send-string still needs to be changed into a > single "\n" in order to avoid spurious prompts. Yes, of course. BTW do you have any idea why the current code uses "\n\n"? > 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. Would it be because eldoc ends up sending commands to the underlying process while some other command is still being processed? Maybe we'd need a "python-process-busy" variable to prevent eldoc from interfering. > 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 handling of the prompt looks pretty messy, indeed. I think we should never send a command followed by "\n" followed by "print _emacs_out ()", but instead we should send the command augmented with "; print _emacs_out ()\n". This should avoid those nasty intermediate prompts. How 'bout the patch below which also removes the _emacs_ok and preoutput continuation stuff which doesn't seem to be used any more. Stefan --- python.el 20 ao=FB 2006 14:13:46 -0400 1.41 +++ python.el 23 ao=FB 2006 00:00:28 -0400=09 @@ -1250,47 +1250,45 @@ (defvar python-preoutput-result nil "Data from last `_emacs_out' line seen by the preoutput filter.") =20 -(defvar python-preoutput-continuation nil - "If non-nil, funcall this when `python-preoutput-filter' sees `_emacs_ok= '.") - (defvar python-preoutput-leftover nil) =20 ;; Using this stops us getting lines in the buffer like ;; >>> ... ... >>> -;; Also look for (and delete) an `_emacs_ok' string and call -;; `python-preoutput-continuation' if we get it. (defun python-preoutput-filter (s) "`comint-preoutput-filter-functions' function: ignore prompts not at bol= ." (when python-preoutput-leftover (setq s (concat python-preoutput-leftover s)) (setq python-preoutput-leftover nil)) + (let ((start 0) + (res "")) + ;; First process whole lines. + (while (string-match "\n" s start) + (let ((line (substring s start (setq start (match-end 0))))) + (if (string-match "\\`_emacs_out \\(.*\\)\n\\'" line) + (setq python-preoutput-result (match-string 1 line)) + (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) - (/=3D (let ((inhibit-field-text-motion t)) - (line-beginning-position)) - (point))) + ;; Drop this prompt only if it's not gonna be inserted at = BOL. + (if (zerop (length res)) + (not (bolp)) + (string-match res ".\\'"))) ;; The need for this seems to be system-dependent: ;; What is this all about, exactly? --Stef ;; (if (and (eq ?. (aref s 0))) ;; (accept-process-output (get-buffer-process (current-buffer)) 1)) - "") - ((string=3D s "_emacs_ok\n") - (when python-preoutput-continuation - (funcall python-preoutput-continuation) - (setq python-preoutput-continuation nil)) - "") - ((string-match "_emacs_out \\(.*\\)\n" s) - (setq python-preoutput-result (match-string 1 s)) - "") - ((string-match ".*\n" s) - s) - ((or (eq t (compare-strings s nil nil "_emacs_ok\n" nil (length s))) - (let ((end (min (length "_emacs_out ") (length s)))) - (eq t (compare-strings s nil end "_emacs_out " nil end)))) + res) + ((let ((end (min (length "_emacs_out ") (length s)))) + (eq t (compare-strings s nil end "_emacs_out " nil end))) + ;; The leftover string is a prefix of _emacs_out so we don't kn= ow + ;; yet whether it's an _emacs_out or something else: wait until= we + ;; get more output so we can resolve this ambiguity. (setq python-preoutput-leftover s) - "") - (t s))) + res) + (t (concat res s))))) =20 (autoload 'comint-check-proc "comint") =20 @@ -1342,9 +1340,8 @@ ;; file. The code might be inline here, but there's enough that it ;; seems worth putting in a separate file, and it's probably cleaner ;; to put it in a module. - (python-send-string "import emacs") ;; Ensure we're at a prompt before doing anything else. - (python-send-receive "print '_emacs_out ()'") + (python-send-receive "import emacs; print '_emacs_out ()'") ;; Without this, help output goes into the inferior python buffer if ;; the process isn't already running. (sit-for 1 t) ;Should we use accept-process-output instead? --St= ef @@ -1362,9 +1359,8 @@ (let ((end (marker-position (process-mark (python-proc))))) (with-current-buffer python-buffer (goto-char (point-max))) (compilation-forget-errors) - (python-send-string command) ;; Must wait until this has completed before re-setting variables belo= w. - (python-send-receive "print '_emacs_out ()'") + (python-send-receive (concat comand "; print '_emacs_out ()'")) (with-current-buffer python-buffer (set-marker compilation-parsing-end end) (setq compilation-last-buffer (current-buffer))))) @@ -1409,7 +1405,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")) =20 (defun python-send-buffer () "Send the current buffer to the inferior Python process."