bug#17950: 24.4.50; REGRESSION: `read-file-name' from a menu (mouse) treats "~/" as installation dir

[Drew Adams]

> > > However, it seems that the directory used for the file selection box
> > > is not related to `Start in'.  It seems to be the something like a
> > > dir used in a different or a previous Emacs session (?).  Not sure
> > > about that, but it definitely comes up with a directory that is
> > > unrelated to either my HOME or the directory in `Start in'.
> >
> > Could be a Windows 7 thing (I'm testing on XP here).  I think it
> > remembers the last directory you were in, or something.  I'll try on
> > Windows 7 when I can.
> 
> OK, I do see this on Windows 7.  But it's not due to something Emacs
> does or started to do lately.  This is due to a deliberate change in
> behavior of the file selection dialogs introduced in Windows 7.  It is
> explicitly documented in the pertinent parameter we pass to the API
> that pops up the dialog:
> 
>   lpstrInitialDir
> 
>       Type: LPCTSTR
> 
>       The initial directory. The algorithm for selecting the initial
>       directory varies on different platforms.
> 
>       Windows 7:
> 
>         If lpstrInitialDir has the same value as was passed the
>         first time the application used an Open or Save As dialog
>         box, the path most recently selected by the user is used as
>         the initial directory.
> 
>         Otherwise, if lpstrFile contains a path, that path is the
>         initial directory.
> 
>         Otherwise, if lpstrInitialDir is not NULL, it specifies the
>         initial directory.  If lpstrInitialDir is NULL and the
>         current directory contains any files of the specified filter
>         types, the initial directory is the current directory.
> 
>         Otherwise, the initial directory is the personal files
>         directory of the current user.
> 
>         Otherwise, the initial directory is the Desktop folder.
> 
>       Windows 2000/XP/Vista:
> 
>         If lpstrFile contains a path, that path is the initial
>         directory.
> 
>         Otherwise, lpstrInitialDir specifies the initial directory.
> 
>         Otherwise, if the application has used an Open or Save As
>         dialog box in the past, the path most recently used is
>         selected as the initial directory. However, if an
>         application is not run for a long time, its saved selected
>         path is discarded.  If lpstrInitialDir is NULL and the
>         current directory contains any files of the specified filter
>         types, the initial directory is the current directory.
> 
>         Otherwise, the initial directory is the personal files
>         directory of the current user.
> 
>         Otherwise, the initial directory is the Desktop folder.
> 
> IOW, whenever you call x-file-dialog with the same 2nd argument as the
> last time, you will be presented with the directory where you selected
> a file at that prior call.
> 
> So I'm quite sure your previous binary (and all the older ones)
> behaves exactly like your current binary does.  All you need to
> trigger this "feature" is to navigate away from your home directory
> using the file selection dialog, and actually select a file in another
> directory, then invoke x-file-dialog again with the same "~/" argument
> as the first call -- you will see that the file selection dialog
> displays that other directory.
> 
> Given that this is standard behavior of the file selection dialog on
> Windows 7 and later, the question is, should we try to work around it
> (assuming there is a workaround, which is something I'm not yet sure)?
> 
> And if the workaround comes at a price, like initially having
> something like "*.*" in the "File Name" field, which currently starts
> empty, is that price acceptable, or would it be a nuisance?

Got it.  Thanks for looking into this.  I don't have a particular
opinion about how Emacs Dev should handle this.  I do see that this
could lead to user errors or at least confusion.

I'm OK with whatever you decide is TRT to do about this (including if
it is nothing). Thx.