From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: find-file dialog in Carbon Emacs is broken Date: Sat, 9 Oct 2004 15:27:00 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <20041009192700.GA29314@fencepost> References: <2E4D1BEC-197D-11D9-8298-00039384A728@rice.edu> <5860A2EC-1A19-11D9-BB9A-000D93505B76@swipnet.se> <20041009184338.GB22402@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1097350061 32503 80.91.229.6 (9 Oct 2004 19:27:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 9 Oct 2004 19:27:41 +0000 (UTC) Cc: Steven Tamm , emacs-devel@gnu.org, Mark Moll , Stefan , Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 09 21:27:30 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 1CGMsM-0004VN-00 for ; Sat, 09 Oct 2004 21:27:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGMzD-0004pk-6r for ged-emacs-devel@m.gmane.org; Sat, 09 Oct 2004 15:34:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CGMz5-0004nO-Dq for emacs-devel@gnu.org; Sat, 09 Oct 2004 15:34:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CGMz4-0004mg-JA for emacs-devel@gnu.org; Sat, 09 Oct 2004 15:34:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGMz4-0004md-G6 for emacs-devel@gnu.org; Sat, 09 Oct 2004 15:34:26 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CGMrt-0006hl-32 for emacs-devel@gnu.org; Sat, 09 Oct 2004 15:27:01 -0400 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.34) id 1CGMrs-0007v5-Bi; Sat, 09 Oct 2004 15:27:00 -0400 Original-To: "Jan D." Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Blat: Foop 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:28153 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28153 On Sat, Oct 09, 2004 at 09:15:54PM +0200, Jan D. wrote: > > What does read-file-name use now? It seems like the state of MUST-MATCH > > is a pretty good hint what is wanted. If the File menu invoked something > > like `find-existing-file' (like find-file, but sets MUST-MATCH to > > non-nil) for the "Open" entry, wouldn't that just work? > > No, it is no good at all. Most operations doesn't set MUST-MATCH when > an existing file is to be opened. I can see two possibilities for such cases: (1) they are broken because they really do need an existing file, but don't ask for one, and (2) they really can handle entry of a non-existant filename (like find-file). It would seem that instances (1) should be fixed to use the proper MUST-MATCH setting, so they'd use the proper dialog too. For (disfunctional) GUI toolkits that force the save/load dichotomy on applications, it would seem that instances of (2) _must_ use the save dialog, even if it doesn't make sense to the user, because that's the only way you can allow new filenames to be entered (which is why I say that it's the GUI toolkit that's broken, not emacs)!?! Operations that can handle non-existant filenames, but which are `conventionally' used in a existant-file-only manner from a GUI can use the method I mentioned in my previous post: Add a new `FOO-existing-file' command for use in menus. > Take for example ediff. It needs two existing files, but it is impossible > to set MUST-MATCH in this case. For the GTK case, the button would then be > "Save" (and the word "Save" appears in other parts of the dialog as well), > and this is not possible to change from Emacs. It is just cosmetic, but > looks bad and would lead to confusion. Sounds like ediff needs fixing, not the lower layers. -Miles -- Saa, shall we dance? (from a dance-class advertisement)