read-file-name error-handling problem

[Noah Friedman]

Speaking of read-file-name calling conventions, I'm running into a case
where errors from read-file-name are not caught by condition-case even when
they should be.  I believe that the code snippet below should print a
message in the echo area instead of going into the debugger.

This happens building from the cvs trunk as of last night, but I first
noticed it a few weeks ago but was too busy to produce a smaller test case.
This test case attempts to call read-file-name in an xemacs-compatible
fashion but trap errors from that, and is failing.  (I first ran into this
problem with VM.)

To demonstrate the bug, load this file and run M-x foo, then type some
partial file name in your current working directory and then try to
complete it, e.g. I have a directory called "bin" in my home directory, and
if I type M-x b<TAB>, I get thrown into the elisp debugger.  The backtrace
is attached below.

No fix yet, but I thought I'd report it in the meantime in case someone
else immediately recognizes the problem.

(setq debug-on-error t)

(defun foo ()
  (interactive)
  (let ((foo-history '("~/foo")))
    (condition-case err
        (read-file-name "Foo: " "~/" nil nil nil foo-history)
      (error
       (message "caught error: %s" err)))))

Debugger entered--Lisp error: (invalid-function ("~/foo"))
  ("~/foo")("~/bin/")
  read-file-name-internal("~/bin/" "~/" lambda)
  minibuffer-complete()
* call-interactively(minibuffer-complete)
  read-file-name("Foo: " "~/" nil nil nil ("~/foo"))
  (condition-case err (read-file-name "Foo: " "~/" nil nil nil foo-history) 
(error (message "caught error: %s" err)))
  (let ((foo-history ...)) (condition-case err (read-file-name "Foo: " "~/" nil 
nil nil foo-history) (error ...)))
  foo()
* call-interactively(foo)
  execute-extended-command(nil)
* call-interactively(execute-extended-command)