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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 06 Jul 2014 18:56:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 17950@debbugs.gnu.org
> 
> > 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?