bug#19412: 24.3; ido-write-file sometimes writes to a different directory than, it says it will

["Ryan C. Thompson" <rct@thompsonclan.org>]

I believe I have discovered the cause of this bug. It can be reproduced 
by evaluating the following code and then hitting RET:

(read-file-name-default "Write file: " "/tmp/" "~/mumble.frotz" nil nil nil)

This will return "~/mumble.frotz" rather than "/tmp/". Ido triggers this 
issue by causing "read-file-name-default" to be called with arguments 
like the above when triggered to fall back to non-ido completion as 
described in the inital report. The crux of the issue is that the 
initial directory, "/tmp/", is treated as *not* user-entered, so 
pressing RET on it returns the default filename instead (which is 
populated from the buffer file name).

This is not trivial to fix, because ido isn't calling 
"read-file-name-default" directly. In the example given, it's 
let-binding "default-directory" to "/tmp/" and then doing:

(call-interactively 'write-file)

And then the interactive form calls:

(read-file-name "Write file: ")

which then picks up DIR and DEFAULT-FILENAME from "default-directory" 
and "buffer-file-name" respectively. So this isn't a case of just fixing 
a function call somewhere. One possible solution would be to also 
let-bind "buffer-file-name" to nil, in which case DEFAULT-FILENAME gets 
set to DIR. That would work for the case of "write-file", but I don't 
know if it would work for other functions that read file names.

Lastly, I'm guessing that the original reporter ran into this issue 
because they were using C-f RET to select "/tmp/" within ido completion, 
since RET would just select the first file or subdirectory on the list. 
They should be using C-j to do that.

I might add a hack to my ido-completing-read-plus package to fix this 
edge case, if I can figure out a reasonably clean way to fix it.