Re: python-mode: make sure output is not eaten

[Slawomir Nowaczyk]

On Tue, 22 Aug 2006 02:10:02 -0400
Stefan Monnier <address@hidden> 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
     ( address@hidden )

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.