Problem with ido-mode and partial-completion-mode.

[Matt Hodges]

In GNU Emacs 22.0.50.101 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2006-09-25 on escpc40
X server distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--with-gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

With emacs -Q and eval:

    (progn
      (ido-mode 1)
      (ido-everywhere 1)
      (partial-completion-mode 1))

In *scratch* enter non-ascii character (e.g., C-q 2 0 0 SPC), and
write file with C-x C-w (ido-write-file).  After choosing a file name,
if TAB is pressed for a list of coding systems, the following error is
signalled:

    Debugger entered--Lisp error: (wrong-type-argument stringp nil)
      expand-file-name(nil)
      PC-do-completion(nil)
      PC-complete()
      call-interactively(PC-complete)
      read-coding-system("Select coding system (default mule-utf-8): " 
mule-utf-8)
      select-safe-coding-system-interactively(1 3 (utf-8 utf-16 utf-16 utf-16 
utf-16be utf-16le raw-text emacs-mule no-conversion) (iso-latin-1) nil 
mule-utf-8)
      select-safe-coding-system(1 3 nil nil "/tmp/foo")
      write-region(1 3 "/tmp/foo" nil t "/tmp/foo")
      basic-save-buffer-2()
      basic-save-buffer-1()
      basic-save-buffer()
      save-buffer()
      write-file("/tmp/foo")
      ido-file-internal(write write-file nil "Write file: " nil nil ignore)
      ido-write-file()
      call-interactively(ido-write-file)

This is because minibuffer-completing-file-name is still bound to t
when write-file is called, and in particular the (funcall
PC-completion-as-file-name-predicate) in PC-do-completion returns this
value.

Localising the binding of minibuffer-completing-file-name to
ido-read-internal fixes the problem, but I don't know the code
sufficiently well to know if this is the correct fix.  Over to Kim...

Thanks,

Matt