From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17950: 24.4.50; REGRESSION: `read-file-name' from a menu (mouse) treats "~/" as installation dir Date: Mon, 7 Jul 2014 09:23:52 -0700 (PDT) Message-ID: References: <> <<83a98meb0w.fsf@gnu.org>> <<83zjglcice.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1404750334 10906 80.91.229.3 (7 Jul 2014 16:25:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Jul 2014 16:25:34 +0000 (UTC) Cc: 17950@debbugs.gnu.org To: Eli Zaretskii , drew.adams@oracle.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 07 18:25:26 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X4BjH-0008Hp-S4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Jul 2014 18:25:24 +0200 Original-Received: from localhost ([::1]:51686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4BjH-0003PB-G4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Jul 2014 12:25:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4Bj5-0003N0-FU for bug-gnu-emacs@gnu.org; Mon, 07 Jul 2014 12:25:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X4Biw-0005Jx-O3 for bug-gnu-emacs@gnu.org; Mon, 07 Jul 2014 12:25:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4Biw-0005JP-Ke for bug-gnu-emacs@gnu.org; Mon, 07 Jul 2014 12:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X4Biv-0000nM-TY for bug-gnu-emacs@gnu.org; Mon, 07 Jul 2014 12:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Jul 2014 16:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17950-submit@debbugs.gnu.org id=B17950.14047502432950 (code B ref 17950); Mon, 07 Jul 2014 16:25:01 +0000 Original-Received: (at 17950) by debbugs.gnu.org; 7 Jul 2014 16:24:03 +0000 Original-Received: from localhost ([127.0.0.1]:46149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X4Bhy-0000lW-S3 for submit@debbugs.gnu.org; Mon, 07 Jul 2014 12:24:03 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:46152) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X4Bhw-0000ky-NG for 17950@debbugs.gnu.org; Mon, 07 Jul 2014 12:24:01 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s67GNsxx008413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jul 2014 16:23:54 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s67GNrGA005978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Jul 2014 16:23:53 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s67GNqnY005964; Mon, 7 Jul 2014 16:23:53 GMT In-Reply-To: <<83zjglcice.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:91281 Archived-At: > > > 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. >=20 > 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: >=20 > lpstrInitialDir >=20 > Type: LPCTSTR >=20 > The initial directory. The algorithm for selecting the initial > directory varies on different platforms. >=20 > Windows 7: >=20 > =09 If lpstrInitialDir has the same value as was passed the > =09 first time the application used an Open or Save As dialog > =09 box, the path most recently selected by the user is used as > =09 the initial directory. >=20 > =09 Otherwise, if lpstrFile contains a path, that path is the > =09 initial directory. >=20 > =09 Otherwise, if lpstrInitialDir is not NULL, it specifies the > =09 initial directory. If lpstrInitialDir is NULL and the > =09 current directory contains any files of the specified filter > =09 types, the initial directory is the current directory. >=20 > =09 Otherwise, the initial directory is the personal files > =09 directory of the current user. >=20 > =09 Otherwise, the initial directory is the Desktop folder. >=20 > Windows 2000/XP/Vista: >=20 > =09 If lpstrFile contains a path, that path is the initial > =09 directory. >=20 > =09 Otherwise, lpstrInitialDir specifies the initial directory. >=20 > =09 Otherwise, if the application has used an Open or Save As > =09 dialog box in the past, the path most recently used is > =09 selected as the initial directory. However, if an > =09 application is not run for a long time, its saved selected > =09 path is discarded. If lpstrInitialDir is NULL and the > =09 current directory contains any files of the specified filter > =09 types, the initial directory is the current directory. >=20 > =09 Otherwise, the initial directory is the personal files > =09 directory of the current user. >=20 > =09 Otherwise, the initial directory is the Desktop folder. >=20 > 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. >=20 > 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. >=20 > 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)? >=20 > 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.