Howdy all. I've periodically seen problems in the past with ClearCase mode being messed up to the point of it essentially locking up waiting for the underlying cleartool command to start, and after upgrading to the latest officially released cleartool.el today I'm now hitting it pretty much universally in my setup (including w/ -vanilla, eliminating my setup). Basically, I think there is a race condition going on where cleartool is starting (I can see the process running), but not seeing the command that the mode is passing to it, so it doesn't give the expected response, so XEmacs just sits there saying "waiting for cleartool to start". Even reverting to the previous version of clearcase.el I have (and removing the .elc of course) still exhibits the problem, so I'm thinking that one of the other updated packages it requires is triggering this...and in fact it appears to be tq.el because if I load the older version I had before loading clearcase.el, everything is fine. The delta between the previous tq.el and the current is pretty small: =========================================================================== --- tq.el.prev Thu Jan 20 17:08:03 2005 +++ tq.el Mon Nov 8 01:17:00 2004 ＠＠ -23,7 +23,7 ＠＠ ;; Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA ;; 02111-1307, USA. -;;; Synched up with: FSF 19.34. +;;; Synched up with: FSF 21.3. ;;; Commentary: ＠＠ -50,8 +50,8 ＠＠ (concat " tq-temp-" (process-name process))))))) (set-process-filter process - (`(lambda (proc string) - (tq-filter '(, tq) string)))) + `(lambda (proc string) + (tq-filter '(, tq) string))) tq)) ;;; accessors ＠＠ -69,7 +69,7 ＠＠ (defun tq-queue-head-closure (tq) (car (cdr (car (tq-queue tq))))) (defun tq-queue-empty (tq) (not (tq-queue tq))) (defun tq-queue-pop (tq) (setcar tq (cdr (car tq))) (null (car tq))) - + ;;; must add to queue before sending! (defun tq-enqueue (tq question regexp closure fn) ＠＠ -89,10 +89,10 ＠＠ (defun tq-filter (tq string) "Append STRING to the TQ's buffer; then process the new data." - (set-buffer (tq-buffer tq)) - (goto-char (point-max)) - (insert string) - (tq-process-buffer tq)) + (with-current-buffer (tq-buffer tq) + (goto-char (point-max)) + (insert string) + (tq-process-buffer tq))) (defun tq-process-buffer (tq) "Check TQ's buffer for the regexp at the head of the queue." ＠＠ -110,10 +110,13 ＠＠ (if (re-search-forward (tq-queue-head-regexp tq) nil t) (let ((answer (buffer-substring (point-min) (point)))) (delete-region (point-min) (point)) - (funcall (tq-queue-head-fn tq) - (tq-queue-head-closure tq) - answer) - (tq-queue-pop tq) + (unwind-protect + (condition-case nil + (funcall (tq-queue-head-fn tq) + (tq-queue-head-closure tq) + answer) + (error nil)) + (tq-queue-pop tq)) (tq-process-buffer tq)))))) (provide 'tq) =========================================================================== I'm suspecting that last delta, but haven't been able to figure out enough running under edebug yet to figure out exactly why. Figured I'd see if anyone on the list would know just by visual inspection before I dove too much deeper in...or if anyone had any advice on how to make debugging this easier? Thanks, Chuck -- Charles K. Hines <ckh(a)requesttech.com&gt; <chuck.hines(a)baesystems.com&gt; Principal Scientist at ReQuest Technologies Inc. (http://www.ReQuestTech.com/) "Oooh, you've touched my inner child...and HE'S REALLY MAD!" (The Black Knight Ghost in "Scooby-Doo 2")