On Tue, 28 Jun 2005 01:28:53 -0400, you wrote: >> People pointed out that "New File" might be confusing >> since it does not in fact make a new file. I think the name >> "Visit New File" will help show that this isn't the same as the usual >> "New File" operation. > >Rather than change menu entries's names to less "standard" ones, we should >change their behavior to better match what users expect.
Exactly the attitude I advocate. >E.g. find-file might require confirmation before opening >a non-existent file. I'll love such a new feature, seeing how often I do >"C-x C-f emacs/src/rege TAB RET" only to find myself in "regexp." rather >than in the "regexp.c" that I intended to open. I love it. >As for the "New File" entry, there are several options. One is to just >create a new buffer called "New Document" and not attached to any file. >This mimicks many "CUA-style" systems. It sucks because it does give us >a chance to choose a good minor mode, and because we won't be able to >autosave the file [this latter point could be fixed, of course]. (Miss "not" near end of 3rd line?) >Another option is to prompt for a file name and require confirmation if the >file already exists. It's a slightly different behavior than those other >"CUA-style" systems, but unsuspecting users should hopefully not find >it confusing, which is all we really care about. Yes! A very nice solution. It alters the timing of when the user supplies the ultimate file-name but preserves essential Emacs models. In fact I suspect that one would be very hard put to find a user of a CUA-like system who would argue that giving new documents an initial, application-generated name and path, only to later have to remember to use SaveAs.. instead of Save is a virtue to be preserved. Thus I believe that Stefan's suggestion would be quite palatable to the CUA community. >I guess I'm just repeating what Miles and Eli have said. No. You have made a concrete suggestion that has not been aired before. I heartily endorse both the suggestion and your attitude of how to respond to the not-yet-Emacs-users community. /john _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
