Re: find-file dialog in Carbon Emacs is broken

[Miles Bader]

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)