       (set-buffer curbuf))
     (process-send-string proc cmd)))
 
-(defun py-process-filter (pyproc string)
-  (let ((curbuf (current-buffer))
-	(pbuf (process-buffer pyproc))
-	(pmark (process-mark pyproc))
-	file-finished)
-    ;; make sure we switch to a different buffer at least once.  if we
-    ;; *don't* do this, then if the process buffer is in the selected
-    ;; window, and point is before the end, and lots of output is
-    ;; coming at a fast pace, then (a) simple cursor-movement commands
-    ;; like C-p, C-n, C-f, C-b, C-a, C-e take an incredibly long time
-    ;; to have a visible effect (the window just doesn't get updated,
-    ;; sometimes for minutes(!)), and (b) it takes about 5x longer to
-    ;; get all the process output (until the next python prompt).
-    ;;
-    ;; #b makes no sense to me at all.  #a almost makes sense: unless
-    ;; we actually change buffers, set_buffer_internal in buffer.c
-    ;; doesn't set windows_or_buffers_changed to 1, & that in turn
-    ;; seems to make the Emacs command loop reluctant to update the
-    ;; display.  Perhaps the default process filter in process.c's
-    ;; read_process_output has update_mode_lines++ for a similar
-    ;; reason?  beats me ...
-
-    (unwind-protect
-	;; make sure current buffer is restored
-	;; BAW - we want to check to see if this still applies
-	(progn
-	  ;; mysterious ugly hack
-	  (if (eq curbuf pbuf)
-	      (set-buffer (get-buffer-create "*scratch*")))
-
-	  (set-buffer pbuf)
-	  (let* ((start (point))
-		 (goback (< start pmark))
-		 (goend (and (not goback) (= start (point-max))))
-		 (buffer-read-only nil))
-	    (goto-char pmark)
-	    (insert string)
-	    (move-marker pmark (point))
-	    (setq file-finished
-		  (and py-file-queue
-		       (equal ">>> "
-			      (buffer-substring
-			       (prog2 (beginning-of-line) (point)
-				 (goto-char pmark))
-			       (point)))))
-	    (if goback (goto-char start)
-	      ;; else
-	      (if py-scroll-process-buffer
-		  (let* ((pop-up-windows t)
-			 (pwin (display-buffer pbuf)))
-		    (set-window-point pwin (point)))))
-	    (set-buffer curbuf)
-	    (if file-finished
-		(progn
-		  (py-safe (delete-file (car py-file-queue)))
-		  (setq py-file-queue (cdr py-file-queue))
-		  (if py-file-queue
-		      (py-execute-file pyproc (car py-file-queue)))))
-	    (and goend
-		 (progn (set-buffer pbuf)
-			(goto-char (point-max))))
-	    ))
-      (set-buffer curbuf))))
+(defun py-comint-output-filter-function (string)
+  "Watch output for Python prompt and exec next file waiting in queue.
+This function is appropriate for `comint-output-filter-functions'."
+  (when (and (string-equal ">>> " string)
+	     py-file-queue)
+    (py-safe (delete-file (car py-file-queue)))
+    (setq py-file-queue (cdr py-file-queue))
+    (if py-file-queue
+	(let ((pyproc (get-buffer-process (current-buffer))))
+	  (py-execute-file pyproc (car py-file-queue))))
+    ))
 
 (defun py-postprocess-output-buffer (buf)
   "Highlight exceptions found in BUF.

	  (const :tag "Single # `sets' indentation except at column zero"
		 other)
	  )
  :group 'python)

(defcustom py-scroll-process-buffer nil
  "*Scroll Python process buffer as output arrives.
If nil, the Python process buffer acts, with respect to scrolling, like
Shell-mode buffers normally act.  This is surprisingly complicated and
so won't be explained here; in fact, you can't get the whole story
without studying the Emacs C code.

If non-nil, the behavior is different in two respects (which are
slightly inaccurate in the interest of brevity):

  - If the buffer is in a window, and you left point at its end, the
    window will scroll as new output arrives, and point will move to the
    buffer's end, even if the window is not the selected window (that
    being the one the cursor is in).  The usual behavior for `shell-mode'
    windows is not to scroll, and to leave point where it was, if the
    buffer is in a window other than the selected window.

  - If the buffer is not visible in any window, and you left point at
    its end, the buffer will be popped into a window as soon as more
    output arrives.  This is handy if you have a long-running
    computation and don't want to tie up screen area waiting for the
    output.  The usual behavior for a `shell-mode' buffer is to stay
    invisible until you explicitly visit it.

Note the `and if you left point at its end' clauses in both of the
above:  you can `turn off' the special behaviors while output is in
progress, by visiting the Python buffer and moving point to anywhere
besides the end.  Then the buffer won't scroll, point will remain where
you leave it, and if you hide the buffer it will stay hidden until you
visit it again.  You can enable and disable the special behaviors as
often as you like, while output is in progress, by (respectively) moving
point to, or away from, the end of the buffer.

Warning:  If you expect a large amount of output, you'll probably be
happier setting this option to nil.

Obscure:  `End of buffer' above should really say `at or beyond the
process mark', but if you know what that means you didn't need to be
told <grin>."
  :type 'boolean
  :group 'python)

(defcustom py-temp-directory

       '(py-python-command
	 py-indent-offset
	 py-block-comment-prefix
	 py-temp-directory
	 py-beep-if-tab-change))
     nil				;pre-hooks
