From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: find-file dialog in Carbon Emacs is broken Date: Mon, 11 Oct 2004 12:47:52 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <416A64D8.2050404@swipnet.se> References: <2E4D1BEC-197D-11D9-8298-00039384A728@rice.edu> <5860A2EC-1A19-11D9-BB9A-000D93505B76@swipnet.se> <20041009184338.GB22402@fencepost> <20041009192700.GA29314@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1097492134 18286 80.91.229.6 (11 Oct 2004 10:55:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 11 Oct 2004 10:55:34 +0000 (UTC) Cc: steventamm@mac.com, miles@gnu.org, mmoll@rice.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 11 12:55:25 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CGxpt-0002J3-00 for ; Mon, 11 Oct 2004 12:55:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGxwp-0007eV-7Q for ged-emacs-devel@m.gmane.org; Mon, 11 Oct 2004 07:02:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CGxqF-0001EX-OI for emacs-devel@gnu.org; Mon, 11 Oct 2004 06:55:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CGxqE-0001Cd-5u for emacs-devel@gnu.org; Mon, 11 Oct 2004 06:55:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGxqD-0001Ao-LU for emacs-devel@gnu.org; Mon, 11 Oct 2004 06:55:45 -0400 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CGxih-0002aA-8O; Mon, 11 Oct 2004 06:47:59 -0400 Original-Received: from coolsville.localdomain ([213.115.28.241] [213.115.28.241]) by mxfep02.bredband.com with ESMTP id <20041011104757.GSWW27821.mxfep02.bredband.com@coolsville.localdomain>; Mon, 11 Oct 2004 12:47:57 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916 X-Accept-Language: en-us, en Original-To: rms@gnu.org In-Reply-To: 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28227 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28227 > In any case, what MUST-MATCH != nil means in Emacs is that the user can > specify any existing file. If that is not what read-file-name does now with > the Motif toolkit in that case, that's a bug. Can you fix it? Okay, then I misunderstood the meaning of MUST-MATCH. I think the name is confusing (for me at least). If an existing file is wanted, it should be named MUST-EXIST or something like that. So we can use MUST-MATCH both for OSX and GTK. > Basically Emacs will have to change so that commands from the menu bar and > tool bar call a new function that knows if this is a save or load. We then > remove the use of a dialog entirely from read-file-name. > > We could define two new functions, read-input-file-name and > read-output-file-name. Would this do the job? Yes, but if MUST-MATCH already shows this, we can use that. But we need a method for opening a directory, as explained by Steven Tamm: > Another distinction is whether or not we mean to open a file or a directory. > To make the distinction in both the w32 & OSX code, we check for the prompt > starting with "Dired". That makes me ill. I don't know what is best, to have a new function that reads directories, or to extend the MUST-MATCH parameter with some value that indicates a directory read. > > Replace "Open File" with "Open old file" and "New buffer". > > It is not a good idea to encourage users to create a buffer to edit a new > file without specifying the file name. So instead let's have "Open File" > and "New File"; "New File" should use the Save dialog to choose the file > name. > > See any problem with that? No, that is okay. Jan D.