   (process-send-string pyproc (format "execfile('%s')\n" fname)))
 
 (defun py-process-filter (pyproc string)
-  (let ( (curbuf (current-buffer))
-	 (pbuf (process-buffer pyproc))
-	 (pmark (process-mark pyproc))
-	 file-finished)
+  (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).
+    ;; 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 ...
+    ;; #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 ...
+
+    ;; BAW - we want to check to see if this still applies
     (if (eq curbuf pbuf)		; mysterious ugly hack
 	(set-buffer (get-buffer-create "*scratch*")))
 
     (set-buffer pbuf)
-    (let* ( (start (point))
-	    (goback (< start pmark))
-	    (buffer-read-only nil))
+    (let* ((start (point))
+	   (goback (< start pmark))
+	   (buffer-read-only nil))
       (goto-char pmark)
       (insert string)
       (move-marker pmark (point))

   "'\\([^'\n\\]\\|\\\\.\\)*'"		; single-quoted
   "\\|"				; or
   "\"\\([^\"\n\\]\\|\\\\.\\)*\"")	; double-quoted
  "regexp matching a Python string literal")

;; this is tricky because a trailing backslash does not mean
;; continuation if it's in a comment

  "Comment out region of code; with prefix arg, uncomment region.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
commented out, by inserting the string `py-block-comment-prefix' at
the start of each line.  With a prefix arg, removes
`py-block-comment-prefix' from the start of each line instead."
  (interactive "*r\nP")   ; region; raw prefix arg
  (goto-char end)   (beginning-of-line) (setq end (point))
  (goto-char start) (beginning-of-line) (setq start (point))
  (let ((prefix-len (length py-block-comment-prefix)) )
    (save-excursion
      (save-restriction
	(narrow-to-region start end)
