find-file dialog in Carbon Emacs is broken

find-file dialog in Carbon Emacs is broken

[Mark Moll]

The find-file dialog window in Carbon Emacs, built today from CVS with 
.../emacs/mac/make-package --self-contained --keep-dir --without-x, is 
broken. When clicking on the "Open file" icon in the toolbar, a "Save 
as:" dialog window appears. However, if the current buffer is the 
"*Messages*" buffer, clicking on the "Open file" icon produces a "Find 
file:" dialog window.
-- 
Mark

Re: find-file dialog in Carbon Emacs is broken

[Steven Tamm]

I'm glad someone tried it ;-)

The problem is that there isn't a good way to determine if it should be 
an open or a save dialog, and unlike on W32 or X, you need to pick 
"ChooseFile" or "PutFile".  The comment I have in the code is;

	/* MAC_TODO: Find a better way to determine if this is a save
	   or load dialog than comparing dir with default_filename */

That's what I'm doing.  I'm checking to see if the directory and the 
default file name are the same, and if it is I put up a save dialog, 
otherwise an open dialog.

Is there a "better semantic" I should be using?

-Steven

On Oct 8, 2004, at 3:55 PM, Mark Moll wrote:

> The find-file dialog window in Carbon Emacs, built today from CVS with 
> .../emacs/mac/make-package --self-contained --keep-dir --without-x, is 
> broken. When clicking on the "Open file" icon in the toolbar, a "Save 
> as:" dialog window appears. However, if the current buffer is the 
> "*Messages*" buffer, clicking on the "Open file" icon produces a "Find 
> file:" dialog window.
> -- 
> Mark
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: find-file dialog in Carbon Emacs is broken

[Stefan]

> The problem is that there isn't a good way to determine if it should be an
> open or a save dialog, and unlike on W32 or X, you need to pick "ChooseFile"
> or "PutFile".  The comment I have in the code is;

It seems the Gtk support has the same problem.
Hopefully the two can share the code that implements their solution,
whatever that one is.


        Stefan

Re: find-file dialog in Carbon Emacs is broken

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

>> The problem is that there isn't a good way to determine if it should be an
>> open or a save dialog, and unlike on W32 or X, you need to pick "ChooseFile"
>> or "PutFile".  The comment I have in the code is;
>
> It seems the Gtk support has the same problem.
> Hopefully the two can share the code that implements their solution,
> whatever that one is.

I think it is obvious that the caller has to specify what it is
looking for.  Where the call comes from an interactive spec, a good
clue is whether the spec will allow non-existing files.

But apart from that, I am afraid there is no way around actually
having different functions (or arguments) for different outcomes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: find-file dialog in Carbon Emacs is broken

[Jan D.]

2004-10-09 kl. 19.14 skrev Stefan:

>> The problem is that there isn't a good way to determine if it should 
>> be an
>> open or a save dialog, and unlike on W32 or X, you need to pick 
>> "ChooseFile"
>> or "PutFile".  The comment I have in the code is;
>
> It seems the Gtk support has the same problem.
> Hopefully the two can share the code that implements their solution,
> whatever that one is.

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.

This is the plan discussed last time this came up, I don't think it is
something we should do for this release:


Replace "Open File" with "Open old file" and "New buffer".
Make them and "Save", "Save As" and "Open directory" call another 
function than read-file-name that opens a dialog in the correct GTK 
mode (i.e. ACTION_SAVE, ACTION_OPEN or ACTION_SELECT_FOLDER).  Do not 
open a dialog
for read-file-name.

Loss of functionality is that "Open old file" can not open a directory 
and "Open directory" can not open a file.  Also, the "New buffer" just 
creates a buffer without a file, the file is specified later when 
saved.  This may
confuse old Emacs users a bit.

	Jan D.

Re: find-file dialog in Carbon Emacs is broken

[Miles Bader]

On Sat, Oct 09, 2004 at 07:33:34PM +0200, Jan D. wrote:
> 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.

This sounds like a rather fragile method -- it means non-standard emacs
commands (and of those, only the ones that someone remembered to change) will
cease to use the dialog boxes entirely, which seems guaranteed to cheese some
people off.

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?

-Miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

Re: find-file dialog in Carbon Emacs is broken

[Jan D.]

> On Sat, Oct 09, 2004 at 07:33:34PM +0200, Jan D. wrote:
>> 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.
>
> This sounds like a rather fragile method -- it means non-standard emacs
> commands (and of those, only the ones that someone remembered to 
> change) will
> cease to use the dialog boxes entirely, which seems guaranteed to 
> cheese some
> people off.

I'd imagine we could make the selection of new and old behaviour
customizable.  Which should be default I'm not sure.  Maybe new 
behaviour
for those file dialogs that can't support the old behaviour (new GTK
and Mac OSX file dialogs).  The thing is if we switch to the new GTK
dialog and/or the Mac OSX dialog, the user will be frustrated anyway.
If these dialogs are opened in the wrong mode (i.e. existing file
instead of new file), there is no way to enter a new file name in these
dialogs.

Also, using a Motif compiled version of Emacs today gives you file 
dialogs,
but the Lucid version does not.  So the usage of file dialogs are 
different
for different users already.

>
> 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.  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.

Today read-file-name just checks if there is a file dialog in the 
toolkit
Emacs was compiled for (and that the use-dialog-box and use-file-dialog
variables are not nil) and assumes that the dialog doesn't need to know
if this is an open for a new or existing file.  Which is fine for the
Motif and old GTK dialogs.

	Jan D.

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)

Re: find-file dialog in Carbon Emacs is broken

[Jan D.]

>>
>> 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).

First we must agree on what MUST-MATCH means.  The Motif dialog box
thinks MUST-MATCH means that the user must select a file that exists
and has the name of the default file (or initial).  The file name can 
not
be changed by the user.  This is for example the case when doing 
next-error
but the current directory is wrong, so the user is basically asked to
change to the correct directory and select the file suggested by Emacs.

But for read-file-name the user is only presented with the default file
name, but can change it.

In the first case, ediff is not broken. In the second case it is, and so
is the code for the Motif dialog.

	Jan D.

Re: find-file dialog in Carbon Emacs is broken

[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.  It 
also figures out if it's open vs. save by comparing the directory with 
the default_filename (i.e. if there is no default filename, then it 
must be open).  If we are going to change any semantics, we should also 
specify whether or not it is trying to open a file, open a directory, 
or save: Distinct from mustmatch.

Right now, the code I have uses the following decision tree:
- If prompt starts with "Dired" use a ChooseFolderDialog
- If mustmatch, use the ChooseFileDialog
- If the directory is the same as the default_filename, use 
ChooseFileDialog
- Otherwise use the PutFileDialog

With newer sematics, the dialogs would "do the right thing."  For 
example, if the request was "open file"and mustmatch was t, then I 
should use the standard ChooseFileDialog.  If mustmatch was nil, it's 
still "open file" but I would have to present the ability to enter a 
filename, which is not supported by default in the OS (but easy to 
add).

-Steven

On Oct 9, 2004, at 1:20 PM, Jan D. wrote:

>
>>>
>>> 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).
>
> First we must agree on what MUST-MATCH means.  The Motif dialog box
> thinks MUST-MATCH means that the user must select a file that exists
> and has the name of the default file (or initial).  The file name can 
> not
> be changed by the user.  This is for example the case when doing 
> next-error
> but the current directory is wrong, so the user is basically asked to
> change to the correct directory and select the file suggested by Emacs.
>
> But for read-file-name the user is only presented with the default file
> name, but can change it.
>
> In the first case, ediff is not broken. In the second case it is, and 
> so
> is the code for the Motif dialog.
>
> 	Jan D.
>

Re: find-file dialog in Carbon Emacs is broken

[Richard Stallman]

    First we must agree on what MUST-MATCH means.  The Motif dialog box
    thinks MUST-MATCH means that the user must select a file that exists
    and has the name of the default file (or initial).

I am having trouble understanding this.  It sounds like you are saying
that the Motif dialog box in the MUST-MATCH != nil case says to the user,
"Specify a file, but it has to be THIS one."  Like elections in the
Soviet Union where the only alternative was to vote for Stalin.

Maybe I did not understand clearly.

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?

Re: find-file dialog in Carbon Emacs is broken

[Jan D.]

> 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.

Re: find-file dialog in Carbon Emacs is broken

[Stefan]

> 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.

What's wrong with read-directory-name?


        Stefan

Re: find-file dialog in Carbon Emacs is broken

[Jan D.]

>> 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.
>
> What's wrong with read-directory-name?

Nothing, except dired does not use it, it uses read-file-name and the
information that a directory is wanted is in the predicate, so it is
not easy in the general case for read-file-name to figure out that
a directory is wanted (the caller may have written its own predicate).

	Jan D.

Re: find-file dialog in Carbon Emacs is broken

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

>>> 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.
>>
>> What's wrong with read-directory-name?
>
> Nothing, except dired does not use it,

So what about changing dired -- that must be a trivial change.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: find-file dialog in Carbon Emacs is broken

[Jason Rumney]

storm@cua.dk (Kim F. Storm) writes:

>>> What's wrong with read-directory-name?
>>
>> Nothing, except dired does not use it,
>
> So what about changing dired -- that must be a trivial change.

Would the following still work?

C-x d
~/emacs/src/p*

Re: find-file dialog in Carbon Emacs is broken

[Jan D.]

> storm@cua.dk (Kim F. Storm) writes:
>
>>>> What's wrong with read-directory-name?
>>>
>>> Nothing, except dired does not use it,
>>
>> So what about changing dired -- that must be a trivial change.

Yes, but we must change read-file-name also so the information that this
is a directory open is passed down to x-file-dialog somehow.

>
> Would the following still work?
>
> C-x d
> ~/emacs/src/p*

As long as no file dialog is involved, it should work.

	Jan D.

Re: find-file dialog in Carbon Emacs is broken

[Richard Stallman]

    >> So what about changing dired -- that must be a trivial change.

    Yes, but we must change read-file-name also so the information that this
    is a directory open is passed down to x-file-dialog somehow.

    >
    > Would the following still work?
    >
    > C-x d
    > ~/emacs/src/p*

    As long as no file dialog is involved, it should work.

Those two statements seem mutually contradictory.
The first says that Dired would use a file dialog,
and the second says that it won't.

Re: find-file dialog in Carbon Emacs is broken

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     >> So what about changing dired -- that must be a trivial change.
>
>     Yes, but we must change read-file-name also so the information that this
>     is a directory open is passed down to x-file-dialog somehow.
>
>     >
>     > Would the following still work?
>     >
>     > C-x d
>     > ~/emacs/src/p*
>
>     As long as no file dialog is involved, it should work.
>
> Those two statements seem mutually contradictory.
> The first says that Dired would use a file dialog,
> and the second says that it won't.

We get file dialogs only for commands started with a mouse.  C-x d
will give the normal minibuffer dialog instead.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: find-file dialog in Carbon Emacs is broken

[Richard Stallman]

The reason that dired does not use read-directory-name is that the
input need not be a directory name.  The input is often a wildcard
file name pattern.

If the file name dialogs don't handle wildcard file name patterns,
Dired has to read them in the minibuffer.  This means that the
menu item for Open Directory needs to run another command that
reads input in a special way.

Re: find-file dialog in Carbon Emacs is broken

[Richard Stallman]

    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.

The term "match" refers to a concept that applies to completion in
general.  It means that the value the user gives in the minibuffer
must match one of the completion alternatives.

However, I don't object if people rename this argument to
MUST-EXIST and change the doc string.

    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.

Whether it is a directory is an independent question from whether it
must match an existing alternative.  All four combinations are
meaningful--consider make-directory.  Also, since MUSTMATCH is an
instance of a more general concept of completion, it is better to keep
it the consistent and uniform.

The separate function read-directory-name is therefore the better way.

Re: find-file dialog in Carbon Emacs is broken

[Richard Stallman]

    No, it is no good at all.  Most operations doesn't set MUST-MATCH when
    an existing file is to be opened.  Take for example ediff.  It needs
    two existing files, but it is impossible to set MUST-MATCH in this case.

Why is that impossible?

Re: find-file dialog in Carbon Emacs is broken

[Richard Stallman]

    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?

    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?

Re: find-file dialog in Carbon Emacs is broken

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     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?
>
>     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.

Yes.  The file name tells Emacs which mode to use, and where to place
autosave files.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Need w32 help (was find-file dialog in Carbon Emacs is broken)

[Jan D.]

Richard Stallman wrote:

>     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.

I've done the changes for this for X and Mac.  I've updated w32fns.c, but I 
have no access to a build environment for W32.  Can someone please check if it 
is OK?

Thanks,

	Jan D.

Re: Need w32 help (was find-file dialog in Carbon Emacs is broken)

[Dhruva Krishnamurthy]

Hello,
 
On Tue, 02 Nov 2004 09:28:33 +0100, Jan D. <jan.h.d@swipnet.se> wrote:
> Richard Stallman wrote:
> 
> >     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.
> 
> I've done the changes for this for X and Mac.  I've updated w32fns.c, but I
> have no access to a build environment for W32.  Can someone please check if it
> is OK?

I tested it on Windows XP using MSVC 6.0, it compiles and works fine.
Open files allows me to open an existing file _only_. New file allows
me to create a file _or_ open an existing file.

with best regards,
dhruva

-- 
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Need w32 help

[Jason Rumney]

Dhruva Krishnamurthy <dhruva.krishnamurthy@gmail.com> writes:

> I tested it on Windows XP using MSVC 6.0, it compiles and works fine.
> Open files allows me to open an existing file _only_.

That sounds like a step backwards. I can understand this behaviour for
platforms that do not let you create a new file from the open file
dialog, but why change those platforms that do?

Re: Need w32 help

[Jan D.]

> Dhruva Krishnamurthy <dhruva.krishnamurthy@gmail.com> writes:
>
>> I tested it on Windows XP using MSVC 6.0, it compiles and works fine.
>> Open files allows me to open an existing file _only_.
>
> That sounds like a step backwards. I can understand this behaviour for
> platforms that do not let you create a new file from the open file
> dialog, but why change those platforms that do?

Doesn't "New File..." allow you to do that?  Anyway, the menu and 
toolbar are defined in menu-bar.el and toolbar/tool-bar.el and these 
files does not contain any platform specific code.  It would be a shame 
to change that.  The fact that Emacs has the same menu commands on all 
platforms is an andvantage for me at least.

	Jan D.

Re: Need w32 help

[Jason Rumney]

>> That sounds like a step backwards. I can understand this behaviour for
>> platforms that do not let you create a new file from the open file
>> dialog, but why change those platforms that do?
>
>
> Doesn't "New File..." allow you to do that?  Anyway, the menu and 
> toolbar are defined in menu-bar.el and toolbar/tool-bar.el and these 
> files does not contain any platform specific code.  It would be a 
> shame to change that.  The fact that Emacs has the same menu commands 
> on all platforms is an andvantage for me at least.
>
Having the same menu items for all platforms is good, but the current 
implementation seems confusing both to experienced Emacs users and to 
new users. "New File..." is in fact the old "Open File...". It allows 
you to both find an existing file and create a new file. This is unlike 
any other application, perhaps "New File..." should just prompt for the 
name rather than use a file dialog. "Open File..." is now a new option 
which actively prevents you from creating a new file, and has the 
toolbar icon of dired.

The dired toolbar icon looks like the icon got corrupted, it took me a 
while to realise that it is in fact a 'd' superimposed on the old dired 
icon, and it would not be obvious to the new user what that meant. I 
suggest that we follow the example of other programs for icons, and 
restore the "Open File..." and "Open Directory..." icons to their 
previous state, and create a new icon for "New File..." based on the 
"Open File..." icon with an added highlight to make it look shiny.

Re: Need w32 help

[Jan D.]

>>> That sounds like a step backwards. I can understand this behaviour 
>>> for
>>> platforms that do not let you create a new file from the open file
>>> dialog, but why change those platforms that do?
>>
>>
>> Doesn't "New File..." allow you to do that?  Anyway, the menu and 
>> toolbar are defined in menu-bar.el and toolbar/tool-bar.el and these 
>> files does not contain any platform specific code.  It would be a 
>> shame to change that.  The fact that Emacs has the same menu commands 
>> on all platforms is an andvantage for me at least.
>>
> Having the same menu items for all platforms is good, but the current 
> implementation seems confusing both to experienced Emacs users and to 
> new users. "New File..." is in fact the old "Open File...". It allows 
> you to both find an existing file and create a new file. This is 
> unlike any other application, perhaps "New File..." should just prompt 
> for the name rather than use a file dialog. "Open File..." is now a 
> new option which actively prevents you from creating a new file, and 
> has the toolbar icon of dired.

My initial suggestion was "Open old file", but it was decided to use 
"Open File".  The fact that "New File" is different is more Emacs 
fault, it needs a file name to determine major mode and such.  Other 
applications create empty documents with no association to a file, 
until you do save.

As for the dired icon, it is actually Emacs who got this backwards.  
The icon Emacs used to use for dired is the GTK stock icon for "open".  
All Gnome applications use that icon just for the purpose Emacs does 
now, i.e. open an existing file.  So in a sense Emacs has become more 
Gnome compliant.

>
> The dired toolbar icon looks like the icon got corrupted, it took me a 
> while to realise that it is in fact a 'd' superimposed on the old 
> dired icon, and it would not be obvious to the new user what that 
> meant. I suggest that we follow the example of other programs for 
> icons, and restore the "Open File..." and "Open Directory..." icons to 
> their previous state, and create a new icon for "New File..." based on 
> the "Open File..." icon with an added highlight to make it look shiny.
>

I am not a graphic designer, that is for sure :-)  You are free to 
modify the dired icon, but I would think it would be counter productive 
to modify the "New File" and "Open File" ones, as this means Emacs 
would again drift away from GTK/Gnome stock icon usage.  As for 
confusing, most users use the tooltips in a toolbar to see what the 
icons do, so any initial confusion should be gone quickly.

	Jan D.

Re: Need w32 help (was find-file dialog in Carbon Emacs is broken)

[Jan D.]

>> I've done the changes for this for X and Mac.  I've updated w32fns.c, 
>> but I
>> have no access to a build environment for W32.  Can someone please 
>> check if it
>> is OK?
>
> I tested it on Windows XP using MSVC 6.0, it compiles and works fine.
> Open files allows me to open an existing file _only_. New file allows
> me to create a file _or_ open an existing file.

Thank you.

	Jan D.

Re: find-file dialog in Carbon Emacs is broken

[Jason Rumney]

Stefan <monnier@iro.umontreal.ca> writes:

>> The problem is that there isn't a good way to determine if it should be an
>> open or a save dialog, and unlike on W32 or X, you need to pick "ChooseFile"
>> or "PutFile".  The comment I have in the code is;
>
> It seems the Gtk support has the same problem.
> Hopefully the two can share the code that implements their solution,
> whatever that one is.

It's also a problem on Windows, though only cosmetic ("Save" vs "Open"
for the button name). At least one person has reported it as a bug
before now.