From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: GTK file selector Date: Thu, 22 Dec 2005 10:27:17 +0100 (CET) Message-ID: <200512220927.jBM9RHcE021048@coolsville.localdomain> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1135252205 30713 80.91.229.2 (22 Dec 2005 11:50:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2005 11:50:05 +0000 (UTC) Cc: juri@jurta.org, ich@frank-schmitt.net, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 22 12:50:03 2005 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EpOxI-0003MD-Hw for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2005 12:49:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpOtO-0007Vc-Ns for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2005 06:45:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EpMtE-0001VC-2l for emacs-devel@gnu.org; Thu, 22 Dec 2005 04:37:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EpMkw-0000mh-V9 for emacs-devel@gnu.org; Thu, 22 Dec 2005 04:29:04 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpMkr-0000lu-AO for emacs-devel@gnu.org; Thu, 22 Dec 2005 04:28:58 -0500 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EpMjv-0006hZ-KM; Thu, 22 Dec 2005 04:27:59 -0500 Original-Received: from coolsville.localdomain ([83.226.180.193] [83.226.180.193]) by mxfep02.bredband.com with ESMTP id <20051222092751.BQI17186.mxfep02.bredband.com@coolsville.localdomain>; Thu, 22 Dec 2005 10:27:51 +0100 Original-Received: (from jhd@localhost) by coolsville.localdomain (8.13.4/8.13.4/Submit) id jBM9RHcE021048; Thu, 22 Dec 2005 10:27:17 +0100 In-Reply-To: "from Richard M. Stallman at Dec 21, 2005 00:30:00 am" Original-To: rms@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:48210 Archived-At: > I don't know, but if some lisp code sets mustmatch to t, it probably > expects the returned file name to be an existing file. > > Not for the Open File menu item! The only reason we made that pass t > for MUSTMATCH is that someone thought that's appropriate for Open File > menu items. Actually the reason was not just that someone thought it would be appropriate, but that the GTK/OSX (and perhaps W32) file dialogs more or less require it. For the new GTK file chooser, if you don't specify that it is selecting existing files, it does not show the directory/file tree (you have to click on a toggle to see it). Also, if we don't tell the new file chooser that it is opening an existing file and the user selects an existing file, the file chooser will pop up a dialog that asks the user if the file selected should be replaced. So, for the new file chooser, the behaviour between opening an existing file and saving a file is quite different. That is what motivated the difference between new and open file in the current Emacs. But the old GTK file dialog does not make any distinction between saving and opening, so for that one we could pass nil for MUSTMATCH. > If it works better, in practical terms, when MUSTMATCH is nil, > we can make it set MUSTMATCH to nil! Yes it can be done. But is it really worthwhile for a dialog that is not default in the first place, and that will probably be gone from GTK soon? Jan D.