* File menu changes (suggestions) @ 2005-06-19 23:25 Drew Adams 2005-06-20 4:56 ` Eli Zaretskii 2005-06-26 4:46 ` Richard M. Stallman 0 siblings, 2 replies; 80+ messages in thread From: Drew Adams @ 2005-06-19 23:25 UTC (permalink / raw) Suggestions to change some File menu items. A few of the renamings might be considered for this release. 1. Unsplit Windows is a very poor name. It doesn't give you a hint of what it does; in particular, it doesn't suggest that the current window is the only one that will remain displayed. It should be named something like `Delete Other Windows' or simply `One Window'. 2. Don't reference "buffer" or "file" in File menu items, when this just refers to the current buffer/file (or the one that will become current). The unreferenced object in a File menu item is understood to be the current buffer/file. And the distinction between file and buffer is not needed here. - New File -> New (but Open is better - see 3, below) - Save (current buffer) -> Save - Close (current buffer) -> Close - Save Buffer As -> Save As - Print Buffer -> Print - PostScript Print Buffer -> PostScript Print - Revert Buffer -> Revert People are used to all of these File commands in other applications. You don't see "Save Page" or "Close Page" in Web-browsers or "Save File" in other editors. In particular: a. Currently, there is an inconsistency wrt "Buffer" and "(current buffer)". These should be made consistent, since the same thing (the current buffer) is involved in each case. It is not as if one acted on the current buffer and the other prompted for an existing buffer to act upon. b. New File does not really create a new file; it opens a buffer (new or existing) that can be saved to a file (new or existing). Not mentioning "file" and "buffer" avoids the distinction, which doesn't matter here anyway. Mentioning "file" and "buffer", and using "file" where it should be "buffer", just misleads. So, New is better than New File (but see 3, below). 3. WRT 2b, it is true that the file or buffer opened need not in fact be new, so even "New" is misleading. The problem arises because we need a name to distinguish open-new-or-existing-buffer-for-new-or-existing-file from Open File (existing file only). A better name for New would be just "Open". Open File is technically "open existing file", but "Open File" is adequate for this action, and it fits with Open Directory and Insert File - explicit mention of "File" suggests an existing file here. 4. A better name for Revert is Reopen. Just as Paste is preferable to Yank in a menu, so is Reopen preferable to Revert: more users will understand it immediately. 5. Move all of the window and frame stuff to a new menu, "Frames". This menu is analogous to the "Buffers" menu. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-19 23:25 File menu changes (suggestions) Drew Adams @ 2005-06-20 4:56 ` Eli Zaretskii 2005-06-20 7:03 ` David Kastrup 2005-06-20 16:53 ` Drew Adams 2005-06-26 4:46 ` Richard M. Stallman 1 sibling, 2 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-06-20 4:56 UTC (permalink / raw) Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sun, 19 Jun 2005 16:25:53 -0700 > > 2. Don't reference "buffer" or "file" in File menu items, when this just > refers to the current buffer/file (or the one that will become current). The > unreferenced object in a File menu item is understood to be the current > buffer/file. And the distinction between file and buffer is not needed here. > > - New File -> New (but Open is better - see 3, below) > - Save (current buffer) -> Save > - Close (current buffer) -> Close > - Save Buffer As -> Save As > - Print Buffer -> Print > - PostScript Print Buffer -> PostScript Print > - Revert Buffer -> Revert > > People are used to all of these File commands in other applications. You > don't see "Save Page" or "Close Page" in Web-browsers or "Save File" in > other editors. We refer to the buffer on purpose: we want users to see Emacs terminology even in the menus, and even when the menus are following established UI guidelines and use standard entries like "New" and "Close". > a. Currently, there is an inconsistency wrt "Buffer" and "(current buffer)". That's not an inconsistency: in the first case, "Buffer" is part of the command name; in the second, it's a minor comment about the command's operation. > New is better than New File (but see 3, below). No, it is not better, since it doesn't say what new entity is created. Other GUI programs have a submenu there or work only with one type of entities (or just leave it vague, which we didn't want to do). > 3. WRT 2b, it is true that the file or buffer opened need not in fact be > new, so even "New" is misleading. The problem arises because we need a name > to distinguish open-new-or-existing-buffer-for-new-or-existing-file from > Open File (existing file only). A better name for New would be just "Open". "New" is a standard entry in the "File" menu, so I don't think renaming it to (a non-standard) "Open" is a good idea. > 4. A better name for Revert is Reopen. Do you know of any other GUI applications that have such a menu entry? > 5. Move all of the window and frame stuff to a new menu, "Frames". Not good: we have a crammed menu bar already, adding more top-level items would only make things worse with no real advantage. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-20 4:56 ` Eli Zaretskii @ 2005-06-20 7:03 ` David Kastrup 2005-06-20 16:53 ` Drew Adams 1 sibling, 0 replies; 80+ messages in thread From: David Kastrup @ 2005-06-20 7:03 UTC (permalink / raw) Cc: Drew Adams, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> 4. A better name for Revert is Reopen. > > Do you know of any other GUI applications that have such a menu > entry? xpdf, xdvi and ggv have "Reload", gimp has "Revert". I have not seen any "Reopen". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: File menu changes (suggestions) 2005-06-20 4:56 ` Eli Zaretskii 2005-06-20 7:03 ` David Kastrup @ 2005-06-20 16:53 ` Drew Adams 2005-06-20 20:37 ` Eli Zaretskii ` (2 more replies) 1 sibling, 3 replies; 80+ messages in thread From: Drew Adams @ 2005-06-20 16:53 UTC (permalink / raw) We refer to the buffer on purpose: we want users to see Emacs terminology even in the menus, and even when the menus are following established UI guidelines and use standard entries like "New" and "Close". Why then do we use Paste instead of Yank? Menu-item names can serve as a bridge between terms that newbies are used to and Emacs terminology. Users can find operations they are familiar with in the menus, and gradually learn the associated commands, which can have very different names. It doesn't help if we use common terminology in uncommon ways - see "New" below. > a. Currently, there is an inconsistency wrt "Buffer" and "(current buffer)". That's not an inconsistency: in the first case, "Buffer" is part of the command name; in the second, it's a minor comment about the command's operation. 1. "Save Buffer As" runs command `write-file'. Where's the beef - er - "buffer"? 2. "Save (current buffer)" runs command `save-buffer'. 3. "Close (current buffer)" runs command `kill-this-buffer'. 4. "Revert Buffer" runs command `revert-buffer'. - 1,2 & 3 seem opposite of the convention you say is behind the names. 4 confirms your rule, as do the "* Print Buffer" items. Not much of a rule (explanation). - The command name is irrelevant here. Again: `yank'. - A minor comment about a command's operation belongs perhaps in a tooltip or help, but not in the name of the menu item itself. > New is better than New File (but see 3, below). No, it is not better, since it doesn't say what new entity is created. Other GUI programs have a submenu there or work only with one type of entities (or just leave it vague, which we didn't want to do). So "New File" says that a new file is created? Yes, it says that, but it tells not the truth: no file is created by this operation. > 3. WRT 2b, it is true that the file or buffer opened need not in fact be > new, so even "New" is misleading. The problem arises because we need a name > to distinguish open-new-or-existing-buffer-for-new-or-existing-file from > Open File (existing file only). A better name for New would be just "Open". "New" is a standard entry in the "File" menu, so I don't think renaming it to (a non-standard) "Open" is a good idea. The name "New" is standard, but our meaning/use of that name is not so standard. "New" in many (most?) applications (e.g. Word and Windows Explorer are common ones) will not let you open an existing document. Our "Open" can do two things: 1) create new, 2) open existing. However, "Open Directory" does not create a new directory. That too is a place where we might consider either renaming the item or extending command `dired' to incorporate the behavior of `dired-create-directory'. > 4. A better name for Revert is Reopen. Do you know of any other GUI applications that have such a menu entry? I have seen "Revert to Saved", which is also clearer than "Revert" (and "Revert Buffer"). My knowledge is limited - you might be right; "Reopen" seems clearer to me, though. "Reload", which David mentioned, is also clearer (though it also suggests Columbine or Grand Theft Auto). Web browsers often use "Refresh" (in the View menu) for reloading a page (although the "reloading" often uses the cache, by default). > 5. Move all of the window and frame stuff to a new menu, "Frames". Not good: we have a crammed menu bar already, adding more top-level items would only make things worse with no real advantage. Agreed. But 1) this stuff has little to do with "File"; 2) use of a "Windows" menu, having a similar purpose, is common in other apps; 3) I think it is likely that we will have more frame and window commands to add to a Frames menu in the future. Again, I didn't expect that much of what I threw out would be agreed upon, especially in the immediate. I do think we might agree to rename a few of the items for this release. I'm thinking, for instance, of "Unsplit Windows". Another possible renaming I forgot to mention is "Split Window". The window is not split to result in a single window with a divider. "New Window" would be a better name for this menu item. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-20 16:53 ` Drew Adams @ 2005-06-20 20:37 ` Eli Zaretskii 2005-06-20 20:48 ` Drew Adams 2005-06-21 2:01 ` Richard Stallman 2005-06-21 7:59 ` Mathias Dahl 2 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-20 20:37 UTC (permalink / raw) Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 20 Jun 2005 09:53:13 -0700 > > We refer to the buffer on purpose: we want users to see Emacs > terminology even in the menus, and even when the menus are following > established UI guidelines and use standard entries like "New" and > "Close". > > Why then do we use Paste instead of Yank? It's not the same: "buffer" is _in_addition_ to "Save" etc., not _instead_ of them. > Menu-item names can serve as a bridge between terms that newbies are used to > and Emacs terminology. Exactly: thus "Save Buffer As" includes both the familiar "Save As" and the reference to "buffer". > > a. Currently, there is an inconsistency wrt "Buffer" and > "(current buffer)". > > That's not an inconsistency: in the first case, "Buffer" is part of > the command name; in the second, it's a minor comment about the > command's operation. > > 1. "Save Buffer As" runs command `write-file'. Where's the beef - er - > "buffer"? > 2. "Save (current buffer)" runs command `save-buffer'. > 3. "Close (current buffer)" runs command `kill-this-buffer'. > 4. "Revert Buffer" runs command `revert-buffer'. Wed are miscommunicating: I didn't mean the name of the Lisp function, I meant the command name that appears in the menu. > - The command name is irrelevant here. I disagree. > - A minor comment about a command's operation belongs perhaps in a tooltip > or help, but not in the name of the menu item itself. There were a lot of iterations about this, the current situation was a compromise between what different people wanted. Let's not go there again. > > New is better than New File (but see 3, below). > > No, it is not better, since it doesn't say what new entity is created. > Other GUI programs have a submenu there or work only with one type of > entities (or just leave it vague, which we didn't want to do). > > So "New File" says that a new file is created? Yes, it says that, but it > tells not the truth: no file is created by this operation. A lone "New" isn't better. I think we didn't find a better alternative. > > 5. Move all of the window and frame stuff to a new menu, "Frames". > > Not good: we have a crammed menu bar already, adding more top-level > items would only make things worse with no real advantage. > > Agreed. But 1) this stuff has little to do with "File"; 2) use of a > "Windows" menu, having a similar purpose, is common in other apps; Richard didn't want that, since in Emacs, `window' means something different. > Another possible renaming I forgot to mention is "Split Window". The window > is not split to result in a single window with a divider. "New Window" would > be a better name for this menu item. I think other applications use the same name. Perhaps just "Split" would be better, I don't know. ^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: File menu changes (suggestions) 2005-06-20 20:37 ` Eli Zaretskii @ 2005-06-20 20:48 ` Drew Adams 0 siblings, 0 replies; 80+ messages in thread From: Drew Adams @ 2005-06-20 20:48 UTC (permalink / raw) We are miscommunicating: I didn't mean the name of the Lisp function, I meant the command name that appears in the menu. > - The command name is irrelevant here. I disagree. Obviously, if I thought you were speaking of the Lisp command name, then that is what I meant was irrelevant here. And the menu command name is obviously relevant to the menu command name (!). And the rest of the line you quote read "Again: `yank'.", making it even clearer that I meant that the Lisp command name was irrelevant to the menu command name. Is that what you disagree with? > > 5. Move all of the window and frame stuff to a new > > menu, "Frames". > > Not good: we have a crammed menu bar already, adding more > top-level > items would only make things worse with no real advantage. > > Agreed. But 1) this stuff has little to do with "File"; 2) use of a > "Windows" menu, having a similar purpose, is common in other apps; Richard didn't want that, since in Emacs, `window' means something different. I proposed "Frames", not "Windows" - see just above. I simply mentioned that a menu (called "Windows") with a similar purpose is a common occurrence. > Another possible renaming I forgot to mention is "Split Window". The window > is not split to result in a single window with a divider. "New Window" would > be a better name for this menu item. I think other applications use the same name. Perhaps just "Split" would be better, I don't know. Verbs without objects in the File menu should, by default, refer to the default object for that menu, which is the current file/buffer. "Split" by itself would not suggest that a new window was to be created. It might suggest that the current file/buffer would be split, but that is not what happens. What's wrong with "New Window" for the menu command to create a new window? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-20 16:53 ` Drew Adams 2005-06-20 20:37 ` Eli Zaretskii @ 2005-06-21 2:01 ` Richard Stallman 2005-06-21 7:59 ` Mathias Dahl 2 siblings, 0 replies; 80+ messages in thread From: Richard Stallman @ 2005-06-21 2:01 UTC (permalink / raw) Cc: emacs-devel We refer to the buffer on purpose: we want users to see Emacs terminology even in the menus, and even when the menus are following established UI guidelines and use standard entries like "New" and "Close". Why then do we use Paste instead of Yank? Each one of these words is a different issue. Please do not start arguments based on a mistaken idea that they should be treated uniformly. That kind of discussion is not useful, and it is a waste of time. We consider these issues one by one. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-20 16:53 ` Drew Adams 2005-06-20 20:37 ` Eli Zaretskii 2005-06-21 2:01 ` Richard Stallman @ 2005-06-21 7:59 ` Mathias Dahl 2005-06-21 9:19 ` Miles Bader 2 siblings, 1 reply; 80+ messages in thread From: Mathias Dahl @ 2005-06-21 7:59 UTC (permalink / raw) "Drew Adams" <drew.adams@oracle.com> writes: > Another possible renaming I forgot to mention is "Split Window". The > window is not split to result in a single window with a > divider. "New Window" would be a better name for this menu item. I do not agree. "Split Window" is in my opinion a very good description of what that command does. I don't understand what you mean by "a single window with a divider": how would that look? If the window has a divider how can there only be one window? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-21 7:59 ` Mathias Dahl @ 2005-06-21 9:19 ` Miles Bader 0 siblings, 0 replies; 80+ messages in thread From: Miles Bader @ 2005-06-21 9:19 UTC (permalink / raw) Cc: emacs-devel On 6/21/05, Mathias Dahl <brakjoller@gmail.com> wrote: > > Another possible renaming I forgot to mention is "Split Window". The > > window is not split to result in a single window with a > > divider. > > I do not agree. "Split Window" is in my opinion a very good > description of what that command does. Indeed. Morever, it gives important information about the way the command works (which something like "new window" would _not_ do, and might actually be more confusing for that reason). Remember, the goal is not to be perfectly consistent with other apps, merely to provide a reasonable compromise that will help users of other apps adapt quickly and painlessly to emacs, and hopefully lead to them becoming skillful users of Emacs. -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-19 23:25 File menu changes (suggestions) Drew Adams 2005-06-20 4:56 ` Eli Zaretskii @ 2005-06-26 4:46 ` Richard M. Stallman 2005-06-26 5:29 ` Lennart Borgman ` (2 more replies) 1 sibling, 3 replies; 80+ messages in thread From: Richard M. Stallman @ 2005-06-26 4:46 UTC (permalink / raw) Cc: emacs-devel I've now read all the mail in this thread, and here are my conclusions. 1. Unsplit Windows is a very poor name. It doesn't give you a hint of what it does; in particular, it doesn't suggest that the current window is the only one that will remain displayed. I agree this name is sort of confusing. I do not see any obvious right name, but I came up with Absorb Other Windows, which I think is pretty clear. I have been trying to think of other verbs, but I can't find one that is entirely right. "Devour"? "Ingest"? "Conquer"? a. Currently, there is an inconsistency wrt "Buffer" and "(current buffer)". These should be made consistent, since the same thing (the current buffer) is involved in each case. I agree that that is inconsistent. It does not seem to be a useful distinction, as currently made. So I propose to remove "Buffer" from well-known operations, and leave it in names of operations that are unusual or where it contrasts with "Region". Here are the changes I propose to make. 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. Please write to me if you see a problem with these changes, or want to suggest an alteration in one of these changes. *** menu-bar.el 17 Jun 2005 09:37:17 -0400 1.260 --- menu-bar.el 25 Jun 2005 19:15:51 -0400 *************** *** 99,111 **** :help "Open a new frame")) (define-key menu-bar-file-menu [one-window] ! '(menu-item "Unsplit Windows" delete-other-windows :enable (not (one-window-p t nil)) ! :help "Make selected window fill its frame")) (define-key menu-bar-file-menu [split-window] '(menu-item "Split Window" split-window-vertically ! :help "Split selected window in two")) (define-key menu-bar-file-menu [separator-window] '(menu-item "--")) --- 99,111 ---- :help "Open a new frame")) (define-key menu-bar-file-menu [one-window] ! '(menu-item "Absorb Other Windows" delete-other-windows :enable (not (one-window-p t nil)) ! :help "Selected window swallows all windows in the frame")) (define-key menu-bar-file-menu [split-window] '(menu-item "Split Window" split-window-vertically ! :help "Split selected window in two windows")) (define-key menu-bar-file-menu [separator-window] '(menu-item "--")) *************** *** 159,170 **** (current-buffer)))))) :help "Re-read current buffer from its file")) (define-key menu-bar-file-menu [write-file] ! '(menu-item "Save Buffer As..." write-file :enable (not (window-minibuffer-p (frame-selected-window menu-updating-frame))) :help "Write current buffer to another file")) (define-key menu-bar-file-menu [save-buffer] ! '(menu-item "Save (current buffer)" save-buffer :enable (and (buffer-modified-p) (buffer-file-name) (not (window-minibuffer-p --- 159,170 ---- (current-buffer)))))) :help "Re-read current buffer from its file")) (define-key menu-bar-file-menu [write-file] ! '(menu-item "Save As..." write-file :enable (not (window-minibuffer-p (frame-selected-window menu-updating-frame))) :help "Write current buffer to another file")) (define-key menu-bar-file-menu [save-buffer] ! '(menu-item "Save" save-buffer :enable (and (buffer-modified-p) (buffer-file-name) (not (window-minibuffer-p *************** *** 175,183 **** '(menu-item "--")) (define-key menu-bar-file-menu [kill-buffer] ! '(menu-item "Close (current buffer)" kill-this-buffer :enable (kill-this-buffer-enabled-p) ! :help "Discard current buffer")) (define-key menu-bar-file-menu [insert-file] '(menu-item "Insert File..." insert-file :enable (not (window-minibuffer-p --- 175,183 ---- '(menu-item "--")) (define-key menu-bar-file-menu [kill-buffer] ! '(menu-item "Close" kill-this-buffer :enable (kill-this-buffer-enabled-p) ! :help "Discard (kill) current buffer")) (define-key menu-bar-file-menu [insert-file] '(menu-item "Insert File..." insert-file :enable (not (window-minibuffer-p *************** *** 194,200 **** (frame-selected-window menu-updating-frame))) :help "Read an existing file into an Emacs buffer")) (define-key menu-bar-file-menu [new-file] ! '(menu-item "New File..." find-file :enable (not (window-minibuffer-p (frame-selected-window menu-updating-frame))) :help "Read or create a file and edit it")) --- 194,200 ---- (frame-selected-window menu-updating-frame))) :help "Read an existing file into an Emacs buffer")) (define-key menu-bar-file-menu [new-file] ! '(menu-item "Visit New File..." find-file :enable (not (window-minibuffer-p (frame-selected-window menu-updating-frame))) :help "Read or create a file and edit it")) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 4:46 ` Richard M. Stallman @ 2005-06-26 5:29 ` Lennart Borgman 2005-06-26 22:42 ` Richard M. Stallman 2005-06-26 18:53 ` Eli Zaretskii 2005-06-28 5:28 ` Stefan Monnier 2 siblings, 1 reply; 80+ messages in thread From: Lennart Borgman @ 2005-06-26 5:29 UTC (permalink / raw) Cc: Drew Adams, emacs-devel Richard M. Stallman 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. > Does not "Visit New File" also imply that a new file is made? Maybe instead "New File Buffer"? It is actually a new buffer that is setup so that it will be associated with a file. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 5:29 ` Lennart Borgman @ 2005-06-26 22:42 ` Richard M. Stallman 2005-06-26 22:52 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 80+ messages in thread From: Richard M. Stallman @ 2005-06-26 22:42 UTC (permalink / raw) Cc: drew.adams, emacs-devel Does not "Visit New File" also imply that a new file is made? It does not have that implication for me. The word "visit" takes away the implication that it _creates_ the new file. Maybe some other word is better than "visit", but I can't think of one now. Maybe instead "New File Buffer"? It is actually a new buffer that is setup so that it will be associated with a file. That term could be unclear too, for people who don't know Emacs. It is grammatically ambiguous. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 22:42 ` Richard M. Stallman @ 2005-06-26 22:52 ` Lennart Borgman 2005-06-26 23:13 ` Drew Adams 2005-06-27 7:37 ` Kim F. Storm 2 siblings, 0 replies; 80+ messages in thread From: Lennart Borgman @ 2005-06-26 22:52 UTC (permalink / raw) Cc: drew.adams, emacs-devel Richard M. Stallman wrote: > Maybe instead "New File Buffer"? It is actually a new buffer that is > setup so that it will be associated with a file. > >That term could be unclear too, for people who don't know Emacs. It >is grammatically ambiguous. > > I would not expect them to believe that every new file will be named "Buffer" ... ;-) ^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: File menu changes (suggestions) 2005-06-26 22:42 ` Richard M. Stallman 2005-06-26 22:52 ` Lennart Borgman @ 2005-06-26 23:13 ` Drew Adams 2005-06-27 7:20 ` Eli Zaretskii 2005-06-27 7:37 ` Kim F. Storm 2 siblings, 1 reply; 80+ messages in thread From: Drew Adams @ 2005-06-26 23:13 UTC (permalink / raw) For a new name for "New File", recent discussion has included candidates Visit New File and New File Buffer. As I said in my original post, which started this, the problem here is "New". The best name for this Emacs operation is, as in the past, "Open". I gave reasons previously. The problem then is distinguishing this from opening an existing file *only*. For that, I suggested that "Open File" would be sufficient, since "file" implies an existing file - you cannot open a new file; you can only create a new file. If people don't think that "Open File" sufficiently makes this clear, then let's call it "Open Existing File" to remove all doubt. The two menu items would then be: - "Open Existing File" = create/select a buffer for an existing file. - "Open" = new or existing: "Open Existing File" or create a buffer for a new file. However, as I mentioned, to be consistent, "Open Directory" and "Insert File" should then also be renamed "Open Existing Directory" and "Insert Existing File". I personally think that the following sufficiently suggest existing objects: "Open File", "Open Directory", and "Insert File". But if people prefer "Open Existing File" to "Open File", then we have the choice of opting for consistency, using "Existing" for the others also, or inconsistency, using it only for "Open Existing File". ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 23:13 ` Drew Adams @ 2005-06-27 7:20 ` Eli Zaretskii 0 siblings, 0 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 7:20 UTC (permalink / raw) > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sun, 26 Jun 2005 16:13:02 -0700 > > For a new name for "New File", recent discussion has included candidates > Visit New File and New File Buffer. > > As I said in my original post, which started this, the problem here is > "New". The best name for this Emacs operation is, as in the past, "Open". I > gave reasons previously. What I say below will probably be ignored, but I feel I must say it anyway. The current discussion and the suggested changes is nothing more than a regress: we are slowly going back to the less compatible names and structure we had before Emacs 21.1 hit the streets. I think we should leave the menus alone. It took a lot of work to come to what we have now, the result exists for quite some time, and it didn't make users unhappy. As they say, the enemy of "good" is "better". And on top of that, now is not the time. Let's leave any changes in the menus for Emacs 23, which will have changes anyway, due to Unicode. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 22:42 ` Richard M. Stallman 2005-06-26 22:52 ` Lennart Borgman 2005-06-26 23:13 ` Drew Adams @ 2005-06-27 7:37 ` Kim F. Storm 2005-06-27 9:25 ` Miles Bader 2005-06-28 4:16 ` Richard M. Stallman 2 siblings, 2 replies; 80+ messages in thread From: Kim F. Storm @ 2005-06-27 7:37 UTC (permalink / raw) Cc: Lennart Borgman, drew.adams, emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > Does not "Visit New File" also imply that a new file is made? > > It does not have that implication for me. The word "visit" takes > away the implication that it _creates_ the new file. > > Maybe some other word is better than "visit", but I can't think of one > now. New Unsaved File ? -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 7:37 ` Kim F. Storm @ 2005-06-27 9:25 ` Miles Bader 2005-06-27 13:29 ` David Kastrup 2005-06-28 4:16 ` Richard M. Stallman 1 sibling, 1 reply; 80+ messages in thread From: Miles Bader @ 2005-06-27 9:25 UTC (permalink / raw) Cc: Lennart Borgman, rms, drew.adams, emacs-devel storm@cua.dk (Kim F. Storm) writes: > New Unsaved File ? I suspect many users would simply strangle themselves rather than try to figure out what that means... -miles -- Would you like fries with that? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 9:25 ` Miles Bader @ 2005-06-27 13:29 ` David Kastrup 0 siblings, 0 replies; 80+ messages in thread From: David Kastrup @ 2005-06-27 13:29 UTC (permalink / raw) Miles Bader <miles@lsi.nec.co.jp> writes: > storm@cua.dk (Kim F. Storm) writes: >> New Unsaved File ? > > I suspect many users would simply strangle themselves rather than > try to figure out what that means... That was pretty much my first thought, minus the flowery language. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 7:37 ` Kim F. Storm 2005-06-27 9:25 ` Miles Bader @ 2005-06-28 4:16 ` Richard M. Stallman 1 sibling, 0 replies; 80+ messages in thread From: Richard M. Stallman @ 2005-06-28 4:16 UTC (permalink / raw) Cc: lennart.borgman.073, drew.adams, emacs-devel New Unsaved File ? This operation has two differences from the usual "New" command: 1. It doesn't write the file yet. 2. You do specify the name now. "Unsaved" expresses #1, but I think that #2 is what users will find the most visibly surprising. That leads me to think that "Open New File" or "Open Nonexistent File" might be the best approach. This is a lot closer to the usual "Open" command than to the typical "New" command. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 4:46 ` Richard M. Stallman 2005-06-26 5:29 ` Lennart Borgman @ 2005-06-26 18:53 ` Eli Zaretskii 2005-06-26 18:00 ` Lennart Borgman ` (2 more replies) 2005-06-28 5:28 ` Stefan Monnier 2 siblings, 3 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-06-26 18:53 UTC (permalink / raw) Cc: drew.adams, emacs-devel > From: "Richard M. Stallman" <rms@gnu.org> > Date: Sun, 26 Jun 2005 00:46:31 -0400 > Cc: emacs-devel@gnu.org > > 1. Unsplit Windows is a very poor name. It doesn't give you a hint of what > it does; in particular, it doesn't suggest that the current window is the > only one that will remain displayed. > > I agree this name is sort of confusing. I do not see any obvious > right name, but I came up with Absorb Other Windows, which I think is > pretty clear. I have been trying to think of other verbs, but I can't > find one that is entirely right. "Devour"? "Ingest"? "Conquer"? FWIW, I see nothing wrong with "Unsplit". At least one other GUI program uses "Remove split", which is very similar; if that is better, let's use it. I think names like "Absorb", "Devour", etc. will tell nothing to users. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 18:53 ` Eli Zaretskii @ 2005-06-26 18:00 ` Lennart Borgman 2005-06-26 19:09 ` Eli Zaretskii 2005-06-26 18:30 ` Jason Rumney 2005-06-27 5:38 ` Richard M. Stallman 2 siblings, 1 reply; 80+ messages in thread From: Lennart Borgman @ 2005-06-26 18:00 UTC (permalink / raw) Cc: rms, drew.adams, emacs-devel Eli Zaretskii wrote: >>From: "Richard M. Stallman" <rms@gnu.org> >>Date: Sun, 26 Jun 2005 00:46:31 -0400 >>Cc: emacs-devel@gnu.org >> >> 1. Unsplit Windows is a very poor name. It doesn't give you a hint of what >> it does; in particular, it doesn't suggest that the current window is the >> only one that will remain displayed. >> >>I agree this name is sort of confusing. I do not see any obvious >>right name, but I came up with Absorb Other Windows, which I think is >>pretty clear. I have been trying to think of other verbs, but I can't >>find one that is entirely right. "Devour"? "Ingest"? "Conquer"? >> >> > >FWIW, I see nothing wrong with "Unsplit". At least one other GUI >program uses "Remove split", which is very similar; if that is better, >let's use it. I think names like "Absorb", "Devour", etc. will tell >nothing to users. > How about "Only One Window"? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 18:00 ` Lennart Borgman @ 2005-06-26 19:09 ` Eli Zaretskii 2005-06-26 18:20 ` Drew Adams 0 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-26 19:09 UTC (permalink / raw) Cc: rms, drew.adams, emacs-devel > Date: Sun, 26 Jun 2005 20:00:29 +0200 > From: Lennart Borgman <lennart.borgman.073@student.lu.se> > CC: rms@gnu.org, drew.adams@oracle.com, emacs-devel@gnu.org > > How about "Only One Window"? Fine with me. ^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: File menu changes (suggestions) 2005-06-26 19:09 ` Eli Zaretskii @ 2005-06-26 18:20 ` Drew Adams 2005-06-26 19:41 ` John S. Yates, Jr. 2005-06-27 13:24 ` David Kastrup 0 siblings, 2 replies; 80+ messages in thread From: Drew Adams @ 2005-06-26 18:20 UTC (permalink / raw) > How about "Only One Window"? Fine with me. "One Window" (my original suggestion) says just as much. My other original suggestion, "Delete Other Windows" is clearest: the command just deletes the other windows. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 18:20 ` Drew Adams @ 2005-06-26 19:41 ` John S. Yates, Jr. [not found] ` <42BF0E53.2020505@student.lu.se> 2005-06-27 13:24 ` David Kastrup 1 sibling, 1 reply; 80+ messages in thread From: John S. Yates, Jr. @ 2005-06-26 19:41 UTC (permalink / raw) Cc: emacs-devel On Sun, 26 Jun 2005 11:20:51 -0700, you wrote: > > How about "Only One Window"? > > Fine with me. > >"One Window" (my original suggestion) says just as much. > >My other original suggestion, "Delete Other Windows" is clearest: the >command just deletes the other windows. Maximize? /john ^ permalink raw reply [flat|nested] 80+ messages in thread
[parent not found: <42BF0E53.2020505@student.lu.se>]
* Re: File menu changes (suggestions) [not found] ` <42BF0E53.2020505@student.lu.se> @ 2005-06-27 12:51 ` John S. Yates, Jr. 2005-06-27 13:31 ` David Kastrup 2005-06-27 17:47 ` Robert J. Chassell 0 siblings, 2 replies; 80+ messages in thread From: John S. Yates, Jr. @ 2005-06-27 12:51 UTC (permalink / raw) Cc: Lennart Borgman Lennart Borgman wrote: >John S. Yates, Jr. wrote: > >>Maximize? > >It is a quite funny remark, but I do not believe anyone will understand >"Only One Window" that way... ;-) But I was not trying to be funny. "Maximize" was a sincere suggestion. That is because if the goal is to analogize Emacs' behavior to that of applications familiar to new users then the widely used Multiple Document Interface application style must be taken into account: http://en.wikipedia.org/wiki/Multiple_document_interface Except for the fact that MDI document windows are not tiled they are very akin to Emacs windows. An MDI document window invariably has iconize, close and maximize/restore icons on its title bar. Clicking an MDI document's maximize icon has an effect identical to delete-other-windows: - all other documents become invisible (ie their "windows" get deleted) - the clicked document grows to occupy the entire workspace of the MDI application (essentially the containing Emacs frame) /john ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 12:51 ` John S. Yates, Jr. @ 2005-06-27 13:31 ` David Kastrup 2005-06-27 17:47 ` Robert J. Chassell 1 sibling, 0 replies; 80+ messages in thread From: David Kastrup @ 2005-06-27 13:31 UTC (permalink / raw) Cc: Lennart Borgman, emacs-devel "John S. Yates, Jr." <john@yates-sheets.org> writes: > Lennart Borgman wrote: > >>John S. Yates, Jr. wrote: >> >>>Maximize? >> >>It is a quite funny remark, but I do not believe anyone will >>understand "Only One Window" that way... ;-) > > But I was not trying to be funny. How about "World domination"? That should be pretty obvious to every player of "Risk". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 12:51 ` John S. Yates, Jr. 2005-06-27 13:31 ` David Kastrup @ 2005-06-27 17:47 ` Robert J. Chassell 2005-06-28 1:57 ` John S. Yates, Jr. 1 sibling, 1 reply; 80+ messages in thread From: Robert J. Chassell @ 2005-06-27 17:47 UTC (permalink / raw) "John S. Yates, Jr." <john@yates-sheets.org> wrote Except for the fact that MDI document windows are not tiled they are very akin to Emacs windows. I don't know about MDI documents. There is a huge difference between deleting other windows within a frame and maximizing a frame so it covers all the other frames that previously could be seen. In my non-Emacs programs, the word `maximize' means `occupy an entire desktop (or `workspace'; the language varies)', not `occupy one frame in a manner that also provides for a mode line and echo area' Are the displays in which MDI documents are shown like Emacs windows which exist in a frame? Can you have two or three of them in the same frame? - the clicked document grows to occupy the entire workspace of the MDI application (essentially the containing Emacs frame) When you say this, do you mean the buffer grows to occupy an entire frame? You use the word `essentially' which suggests that the `entire workspace' is something other than a frame whose size you do not change. Or do you mean the buffer (and frame dressing) grows to occupy an entire desktop and covers over all the other frames visible on that desktop? (This is what `maximize' means for my frames.) I have just changed the work area for writing this message to occupy one frame and also provide for mode line and echo area. Eleven other frames are visible on this desktop, and this user and session are running seven other desktops with thirty-seven other frames visible on them. (I had not realized how many frames I was running. Of these frames, only five are different instances of Emacs.) -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 17:47 ` Robert J. Chassell @ 2005-06-28 1:57 ` John S. Yates, Jr. 0 siblings, 0 replies; 80+ messages in thread From: John S. Yates, Jr. @ 2005-06-28 1:57 UTC (permalink / raw) Cc: emacs-devel On Mon, 27 Jun 2005 17:47:53 (UTC), Robert J. Chassell wrote: >I don't know about MDI documents. In anticipation of which I included the link to the Wikipedia article. It includes an example of a Java MDI application. Here again is the link to the article: http://en.wikipedia.org/wiki/Multiple_document_interface And here is the included image showing multiple child windows within the parent application's window (Emacs frame): http://en.wikipedia.org/wiki/Image:MenuWindow.png >There is a huge difference between deleting other windows within a >frame and maximizing a frame so it covers all the other frames that >previously could be seen. > >In my non-Emacs programs, the word `maximize' means `occupy an entire >desktop (or `workspace'; the language varies)', not `occupy one frame >in a manner that also provides for a mode line and echo area' The former understand need not preclude the latter. Maximize is and operation on a window relative to its siblings. When a child window and its siblings all reside within a single parent window the notion of maximization is easily defined. >Are the displays in which MDI documents are shown like Emacs windows >which exist in a frame? Can you have two or three of them in the same >frame? Yes, that is the essence of MDI. > > - the clicked document grows to occupy the entire workspace > of the MDI application (essentially the containing Emacs > frame) > >When you say this, do you mean the buffer grows to occupy an entire >frame? You use the word `essentially' which suggests that the `entire >workspace' is something other than a frame whose size you do not >change. I think your question is incorrectly formed even if I interpret it according to Emacs vocabulary. It is not the buffer that grows but rather the window displaying the buffer. Most other applications do not make this distinction (though the CodeWright editor does). But the answer to what I believe to be the intent of your question is that the window (an Emacs window) displaying the child document (an Emacs buffer) grows to occupy the entire parent application's window (Emacs frame), hiding all other document windows within the application. This is independent of whether the parent application window (Emacs frame) is maximized or not. >Or do you mean the buffer (and frame dressing) grows to occupy an >entire desktop and covers over all the other frames visible on that >desktop? (This is what `maximize' means for my frames.) No. See discussion above. A MDI application is essentially a mini- window manager, in much the same way that Emacs is. The only real difference is that Emacs know only how to tile. Your typical MDI applications understands operations on individual child windows (minimize, restore, maximize and close) as well as operations on the full set of child windows (tiling horizontally and vertically, cascading, etc). A MDI child window exhibits functionality relative to its parent window that is entirely analogous to that exhibited by a top-level application window relative to the desktop. Because the analogy is so strong if the MDI application and the desktop window manager draw from the same collection of decorations then the widgets used end up being visually identical in both contexts. This was not the case in the Wikipedia image cited above. But I just did a quick Google search and found the following page at the bottom of which is an obvious example: http://www.csharphelp.com/archives/archive227.html /john ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 18:20 ` Drew Adams 2005-06-26 19:41 ` John S. Yates, Jr. @ 2005-06-27 13:24 ` David Kastrup 2005-06-27 16:18 ` Drew Adams 2005-06-27 18:44 ` Eli Zaretskii 1 sibling, 2 replies; 80+ messages in thread From: David Kastrup @ 2005-06-27 13:24 UTC (permalink / raw) Cc: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > > How about "Only One Window"? > > Fine with me. > > "One Window" (my original suggestion) says just as much. No. But "Single Window" would, more or less. "One Window" could also mean "One More Window". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: File menu changes (suggestions) 2005-06-27 13:24 ` David Kastrup @ 2005-06-27 16:18 ` Drew Adams 2005-06-27 18:44 ` Eli Zaretskii 1 sibling, 0 replies; 80+ messages in thread From: Drew Adams @ 2005-06-27 16:18 UTC (permalink / raw) > > How about "Only One Window"? > "One Window" (my original suggestion) says just as much. No. But "Single Window" would, more or less. "One Window" could also mean "One More Window". OK by me. The command takes you from multiple windows to a single window - clear enough. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 13:24 ` David Kastrup 2005-06-27 16:18 ` Drew Adams @ 2005-06-27 18:44 ` Eli Zaretskii 2005-06-27 18:13 ` Drew Adams 1 sibling, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 18:44 UTC (permalink / raw) Cc: drew.adams, emacs-devel > From: David Kastrup <dak@gnu.org> > Date: Mon, 27 Jun 2005 15:24:48 +0200 > Cc: emacs-devel@gnu.org > > "Drew Adams" <drew.adams@oracle.com> writes: > > > > How about "Only One Window"? > > > > Fine with me. > > > > "One Window" (my original suggestion) says just as much. > > No. But "Single Window" would, more or less. "One Window" could also > mean "One More Window". FYI, "One Window" is what we had before Emacs 21.1. Like I said: we are regressing. ^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: File menu changes (suggestions) 2005-06-27 18:44 ` Eli Zaretskii @ 2005-06-27 18:13 ` Drew Adams 2005-06-27 22:19 ` Eli Zaretskii 0 siblings, 1 reply; 80+ messages in thread From: Drew Adams @ 2005-06-27 18:13 UTC (permalink / raw) FYI, "One Window" is what we had before Emacs 21.1. Like I said: we are regressing. Not all movement from one version to the next is progress. It happens sometimes that previous behavior was better than current behavior. Life is like that, sometimes. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 18:13 ` Drew Adams @ 2005-06-27 22:19 ` Eli Zaretskii 2005-06-27 22:33 ` Drew Adams 0 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 22:19 UTC (permalink / raw) Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 27 Jun 2005 11:13:48 -0700 > > FYI, "One Window" is what we had before Emacs 21.1. Like I said: we > are regressing. > > Not all movement from one version to the next is progress. It happens > sometimes that previous behavior was better than current behavior. Life is > like that, sometimes. With all due respect, I don't know where you get the right to talk about the 21.1 menu design with such an arrogance. That design was based on a lot of research. Menus of quite a few other GUI programs were studied, as well as various GUI design guidelines for popular toolkits. The initial version based on that research was then scrutinized in prolonged discussions, and what went into v21.1 was the best solution we could find to the various issues and problems raised in those discussions. By contrast, your suggestions are based on opinions of a single individual. ^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: File menu changes (suggestions) 2005-06-27 22:19 ` Eli Zaretskii @ 2005-06-27 22:33 ` Drew Adams 2005-06-28 4:53 ` Eli Zaretskii 0 siblings, 1 reply; 80+ messages in thread From: Drew Adams @ 2005-06-27 22:33 UTC (permalink / raw) > FYI, "One Window" is what we had before Emacs 21.1. Like > I said: we are regressing. > > Not all movement from one version to the next is progress. > It happens sometimes that previous behavior was better than > current behavior. Life is like that, sometimes. With all due respect, I don't know where you get the right to talk about the 21.1 menu design with such an arrogance. With all due respect, don't get nasty. I did not mention 21.1 - or any particular Emacs version. You quoted my message in its entirety, and it says nothing about specific versions. And I do have the right to talk about any design - anyone does. And I do not feel arrogant - sorry if you take my suggestions that way. I simply pointed out the general rule that not all evolution is in the direction of progress. Or at least that's what I meant to say. Sorry if that wasn't clear. You, on the other hand, labeled "regression" any move to return to a previous state. "regression: 1) Reversion; retrogression. 2) Relapse to a less perfect or developed state." You assume perhaps that all past changes have improved things; I don't share that point of view - in general or in the particular case of Emacs. My point was that, instead of considering all movement to a previous state to be regression, we should consider potential changes on a case-by-case basis, judging them on their own merits - regardless of whether they might have already been visited. Even if most past Emacs changes have meant progress (which is what I think), we should still be able to question any of them and suggest improvements. My general remark about evolution was a response to your blanket judgement that we are regressing by even considering renamings like "New File" -> "Open". Such a change might represent a return to the past, but that would not, by itself, constitute regression. By speaking of "regression", you put a negative value on such a movement, in a wholesale way. If you take the (arrogant?) point of view that we have already achieved the "best of all possible worlds" because lots of discussion, research, experimentation, and expertise went into the existing design, then yes, it's futile not only to suggest repeating a past state but also to suggest any other changes. I (arrogantly?) have a less deferential attitude toward the status quo, but that doesn't mean that I don't value and respect it, its history, and the people who constructed it - I do. By contrast, your suggestions are based on opinions of a single individual. How do you know what I base my suggestions on? On the other hand, yes, my suggestions reflect my opinions, of course. It seems to me that you are the one who is arrogantly arguing from authority. I'm only speaking my mind, and, yes, I only speak for myself. You don't have to agree, but please try to be polite. ad hominem ad nauseum. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 22:33 ` Drew Adams @ 2005-06-28 4:53 ` Eli Zaretskii 2005-06-28 6:36 ` David Kastrup 0 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-28 4:53 UTC (permalink / raw) Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 27 Jun 2005 15:33:47 -0700 > > With all due respect, don't get nasty. If you get arrogant, I get nasty. > I simply pointed out the general rule that not all evolution is in the > direction of progress. We are not talking philosophy in this list. We are talking specific practical issues. > If you take the (arrogant?) point of view that we have already achieved the > "best of all possible worlds" because lots of discussion, research, > experimentation, and expertise went into the existing design, then yes, it's > futile not only to suggest repeating a past state but also to suggest any > other changes. Not everything in Emacs is based on such an effort. The current menu structure is. I never said that it's the best of all possible arrangements, but the fact that we changed it from A to B does mean that the merits and demerits of A vs B were already considered and after a long and constructive discussion we concluded that B is better. So going back to A without at least pointing out where the previous considerations were incorrect is a regression (a negative label) that wastes our valuable time and energy, and on top of that threatens to set us back 5 or 6 years. > I (arrogantly?) have a less deferential attitude toward the status quo, but > that doesn't mean that I don't value and respect it, its history, and the > people who constructed it - I do. Such respect does not mean anything if it does not have specific and clear expression. Arguing that we should go back to what was already considered and rejected, without at least retracing past discussions and pointing out where they were wrong, is anything but an expression of any respect for past deliberations, time, and energy invested back then, to say nothing of the effort we invest now. > please try to be polite. Yeah, right. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 4:53 ` Eli Zaretskii @ 2005-06-28 6:36 ` David Kastrup 0 siblings, 0 replies; 80+ messages in thread From: David Kastrup @ 2005-06-28 6:36 UTC (permalink / raw) Cc: Drew Adams, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: "Drew Adams" <drew.adams@oracle.com> >> Date: Mon, 27 Jun 2005 15:33:47 -0700 >> >> With all due respect, don't get nasty. > > If you get arrogant, I get nasty. We don't need an arms' race in escalation. >> If you take the (arrogant?) point of view that we have already >> achieved the "best of all possible worlds" because lots of >> discussion, research, experimentation, and expertise went into the >> existing design, then yes, it's futile not only to suggest >> repeating a past state but also to suggest any other changes. > > Not everything in Emacs is based on such an effort. The current > menu structure is. I never said that it's the best of all possible > arrangements, but the fact that we changed it from A to B does mean > that the merits and demerits of A vs B were already considered and > after a long and constructive discussion we concluded that B is > better. So going back to A without at least pointing out where the > previous considerations were incorrect is a regression (a negative > label) that wastes our valuable time and energy, and on top of that > threatens to set us back 5 or 6 years. Well, Drew is right that not every change is progress, but unless a change has produced new insights or new information is volunteered, I agree that the difference is not likely to merit wasting considerable time discussing it. We have other areas that are clearly quite more in need of further improvement. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 18:53 ` Eli Zaretskii 2005-06-26 18:00 ` Lennart Borgman @ 2005-06-26 18:30 ` Jason Rumney 2005-06-27 2:06 ` Miles Bader 2005-06-27 5:38 ` Richard M. Stallman 2 siblings, 1 reply; 80+ messages in thread From: Jason Rumney @ 2005-06-26 18:30 UTC (permalink / raw) Cc: rms, drew.adams, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> I agree this name is sort of confusing. I do not see any obvious >> right name, but I came up with Absorb Other Windows, which I think is >> pretty clear. I have been trying to think of other verbs, but I can't >> find one that is entirely right. "Devour"? "Ingest"? "Conquer"? > > FWIW, I see nothing wrong with "Unsplit". At least one other GUI > program uses "Remove split", which is very similar; if that is better, > let's use it. I think names like "Absorb", "Devour", etc. will tell > nothing to users. I agree. Unsplit Windows at least conveys the notion that it does the opposite of Split Window. Coming up with a new verb would remove that association. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 18:30 ` Jason Rumney @ 2005-06-27 2:06 ` Miles Bader 2005-06-27 7:24 ` Eli Zaretskii 2005-06-27 9:19 ` Jason Rumney 0 siblings, 2 replies; 80+ messages in thread From: Miles Bader @ 2005-06-27 2:06 UTC (permalink / raw) Cc: Eli Zaretskii, rms, drew.adams, emacs-devel Jason Rumney <jasonr@gnu.org> writes: > I agree. Unsplit Windows at least conveys the notion that it does the > opposite of Split Window. But it doesn't do the opposite of split-window... -Miles -- "Most attacks seem to take place at night, during a rainstorm, uphill, where four map sheets join." -- Anon. British Officer in WW I ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 2:06 ` Miles Bader @ 2005-06-27 7:24 ` Eli Zaretskii 2005-06-27 6:31 ` Miles Bader 2005-06-27 9:19 ` Jason Rumney 1 sibling, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 7:24 UTC (permalink / raw) Cc: emacs-devel > Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, drew.adams@oracle.com, > emacs-devel@gnu.org > From: Miles Bader <miles@lsi.nec.co.jp> > Date: Mon, 27 Jun 2005 11:06:54 +0900 > > Jason Rumney <jasonr@gnu.org> writes: > > I agree. Unsplit Windows at least conveys the notion that it does the > > opposite of Split Window. > > But it doesn't do the opposite of split-window... If you unsplit immediately after splitting, it does precisely that. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 7:24 ` Eli Zaretskii @ 2005-06-27 6:31 ` Miles Bader 2005-06-27 13:26 ` David Kastrup 0 siblings, 1 reply; 80+ messages in thread From: Miles Bader @ 2005-06-27 6:31 UTC (permalink / raw) Cc: emacs-devel, Miles Bader On 6/27/05, Eli Zaretskii <eliz@gnu.org> wrote: > > > I agree. Unsplit Windows at least conveys the notion that it does the > > > opposite of Split Window. > > > > But it doesn't do the opposite of split-window... > > If you unsplit immediately after splitting, it does precisely that. Yeah, but the menu label doesn't change depending on the number of windows displayed, so the label used has to be accurate for all cases (and > 2 windows is hardly a rare occurance!!). -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 6:31 ` Miles Bader @ 2005-06-27 13:26 ` David Kastrup 2005-06-27 18:26 ` Eli Zaretskii 0 siblings, 1 reply; 80+ messages in thread From: David Kastrup @ 2005-06-27 13:26 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel, miles Miles Bader <snogglethorpe@gmail.com> writes: > On 6/27/05, Eli Zaretskii <eliz@gnu.org> wrote: >> > > I agree. Unsplit Windows at least conveys the notion that it does the >> > > opposite of Split Window. >> > >> > But it doesn't do the opposite of split-window... >> >> If you unsplit immediately after splitting, it does precisely that. > > Yeah, No. I just tried it. I had a two-window frame, used C-x 2 (got three windows) and then C-x 1. After that, I had only a single frame. So it wasn't the opposite, but rather more that happened. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 13:26 ` David Kastrup @ 2005-06-27 18:26 ` Eli Zaretskii 0 siblings, 0 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 18:26 UTC (permalink / raw) Cc: emacs-devel > Cc: miles@gnu.org, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > From: David Kastrup <dak@gnu.org> > Date: Mon, 27 Jun 2005 15:26:26 +0200 > > Miles Bader <snogglethorpe@gmail.com> writes: > > > On 6/27/05, Eli Zaretskii <eliz@gnu.org> wrote: > >> > > I agree. Unsplit Windows at least conveys the notion that it does the > >> > > opposite of Split Window. > >> > > >> > But it doesn't do the opposite of split-window... > >> > >> If you unsplit immediately after splitting, it does precisely that. > > > > Yeah, > > No. I just tried it. I had a two-window frame, used C-x 2 (got three > windows) and then C-x 1. After that, I had only a single frame. Look, ma: another pedant... ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 2:06 ` Miles Bader 2005-06-27 7:24 ` Eli Zaretskii @ 2005-06-27 9:19 ` Jason Rumney 2005-06-27 9:41 ` Miles Bader 1 sibling, 1 reply; 80+ messages in thread From: Jason Rumney @ 2005-06-27 9:19 UTC (permalink / raw) Cc: Eli Zaretskii, rms, drew.adams, emacs-devel Miles Bader <miles@lsi.nec.co.jp> writes: > Jason Rumney <jasonr@gnu.org> writes: >> I agree. Unsplit Windows at least conveys the notion that it does the >> opposite of Split Window. > > But it doesn't do the opposite of split-window... That's a rather pedantic definition of opposite, and dwelling on such pedantry when choosing menu names results in confusion for less experienced users, because you're removing helpful associations between menu entries in return for absolute correctness. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 9:19 ` Jason Rumney @ 2005-06-27 9:41 ` Miles Bader 2005-06-27 18:25 ` Eli Zaretskii 0 siblings, 1 reply; 80+ messages in thread From: Miles Bader @ 2005-06-27 9:41 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel, rms, drew.adams, Miles Bader On 6/27/05, Jason Rumney <jasonr@gnu.org> wrote: > > But it doesn't do the opposite of split-window... > > That's a rather pedantic definition of opposite No it's not (are you serious?). "Unsplit window" vaguely implies that it simply undoes a previous split-window, leaving other windows alone -- but it doesn't do that, it removes all other windows. The lack of symmetry is not subtle. > and dwelling on such > pedantry when choosing menu names results in confusion for less > experienced users, because you're removing helpful associations > between menu entries in return for absolute correctness. ... and dwelling on "symmetry" when it conflicts with clarity is also counter-productive. In many cases there is no perfect name that will help all people form all the right associations; all we can do is try to consider all the factors, and come up with something that results in a minimum of confusion. -miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 9:41 ` Miles Bader @ 2005-06-27 18:25 ` Eli Zaretskii 2005-06-27 20:05 ` David Kastrup 0 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 18:25 UTC (permalink / raw) Cc: emacs-devel > Date: Mon, 27 Jun 2005 18:41:31 +0900 > From: Miles Bader <snogglethorpe@gmail.com> > Cc: Miles Bader <miles@gnu.org>, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, > drew.adams@oracle.com, emacs-devel@gnu.org > > On 6/27/05, Jason Rumney <jasonr@gnu.org> wrote: > > > But it doesn't do the opposite of split-window... > > > > That's a rather pedantic definition of opposite > > No it's not (are you serious?). "Unsplit window" vaguely implies that > it simply undoes a previous split-window To me, it means that a window (``frame'' in our parlance) that was previously split into two or more parts now becomes "unsplit", i.e. we are left with a frame that has only one window. > > and dwelling on such > > pedantry when choosing menu names results in confusion for less > > experienced users, because you're removing helpful associations > > between menu entries in return for absolute correctness. > > ... and dwelling on "symmetry" when it conflicts with clarity is also > counter-productive. In many cases there is no perfect name that will > help all people form all the right associations; all we can do is try > to consider all the factors, and come up with something that results > in a minimum of confusion. I think "Unsplit" is the most associative name of all those suggested in this discussion. Perhaps we should take a user poll to see whose opinion is closer to them. Personally, I fully agree with Jason. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 18:25 ` Eli Zaretskii @ 2005-06-27 20:05 ` David Kastrup 2005-06-27 20:47 ` Lennart Borgman 2005-06-27 21:40 ` Eli Zaretskii 0 siblings, 2 replies; 80+ messages in thread From: David Kastrup @ 2005-06-27 20:05 UTC (permalink / raw) Cc: emacs-devel, miles Eli Zaretskii <eliz@gnu.org> writes: >> Date: Mon, 27 Jun 2005 18:41:31 +0900 >> From: Miles Bader <snogglethorpe@gmail.com> >> Cc: Miles Bader <miles@gnu.org>, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, >> drew.adams@oracle.com, emacs-devel@gnu.org >> >> On 6/27/05, Jason Rumney <jasonr@gnu.org> wrote: >> > > But it doesn't do the opposite of split-window... >> > >> > That's a rather pedantic definition of opposite >> >> No it's not (are you serious?). "Unsplit window" vaguely implies that >> it simply undoes a previous split-window > > To me, it means that a window (``frame'' in our parlance) that was > previously split into two or more parts now becomes "unsplit", i.e. we > are left with a frame that has only one window. If you prefer that verb, I'd rather say something like "Unsplit all" or something like that to make obvious that it is not symmetric with "Split". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 20:05 ` David Kastrup @ 2005-06-27 20:47 ` Lennart Borgman 2005-06-27 21:40 ` Eli Zaretskii 1 sibling, 0 replies; 80+ messages in thread From: Lennart Borgman @ 2005-06-27 20:47 UTC (permalink / raw) Cc: Eli Zaretskii, miles, emacs-devel David Kastrup wrote: >If you prefer that verb, I'd rather say something like "Unsplit all" >or something like that to make obvious that it is not symmetric with >"Split". > After this incredible discussion of this rather tiny (but important) issue I actually had to look at the menu... - I guess most of us mostly use the keyboard, at least for splitting?;-) There is a separate section for splitting + frames. It kind of makes sense but it establish an environment for the name so to say: -------------------- Split Window Remove Window Splitting New Frame Delete Frame -------------------- "Remove Window Splitting" is my candidate now. That groups the two window splitting entries together. Frame is another group. (And I do not have to see that difficult word "unsplit".) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 20:05 ` David Kastrup 2005-06-27 20:47 ` Lennart Borgman @ 2005-06-27 21:40 ` Eli Zaretskii 1 sibling, 0 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 21:40 UTC (permalink / raw) Cc: emacs-devel > Cc: miles@gnu.org, emacs-devel@gnu.org > From: David Kastrup <dak@gnu.org> > Date: Mon, 27 Jun 2005 22:05:33 +0200 > > > To me, it means that a window (``frame'' in our parlance) that was > > previously split into two or more parts now becomes "unsplit", i.e. we > > are left with a frame that has only one window. > > If you prefer that verb, I'd rather say something like "Unsplit all" > or something like that to make obvious that it is not symmetric with > "Split". As Jason and myself tried to explained, it _is_ symmetric, just perhaps not in the sense that you think. It makes something that was split be unsplit. And that something, which we call ``frame'' is called ``window'' elsewhere. So, "Split Window" and "Unsplit Window" is the natural choice. (We actually say "Unsplit Windows" instead, to avoid calling the frame ``a window''. But to me, that subtlety is secondary in this case; I'm quite sure many, perhaps most, users of the menu don't even notice it.) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 18:53 ` Eli Zaretskii 2005-06-26 18:00 ` Lennart Borgman 2005-06-26 18:30 ` Jason Rumney @ 2005-06-27 5:38 ` Richard M. Stallman 2005-06-27 7:24 ` Eli Zaretskii 2 siblings, 1 reply; 80+ messages in thread From: Richard M. Stallman @ 2005-06-27 5:38 UTC (permalink / raw) Cc: drew.adams, emacs-devel FWIW, I see nothing wrong with "Unsplit". At least one other GUI program uses "Remove split", which is very similar; if that is better, let's use it. It isn't better a priori, but if it is widely used and lots of people would have seen it, that would make it better. What other programs use "Remove split"? How about "Only One Window"? I think that is better than just "One Window". The word "Only" carries the implication of getting rid of the rest. Or maybe "Just This Window", which indicates that the selected window is the one that will remain. What do people think of "Just This Window"? >"One Window" (my original suggestion) says just as much. > >My other original suggestion, "Delete Other Windows" is clearest: the >command just deletes the other windows. Maximize? "Maximize" is associated with frames, so people would get the wrong idea. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 5:38 ` Richard M. Stallman @ 2005-06-27 7:24 ` Eli Zaretskii 2005-06-27 11:40 ` John S. Yates, Jr. 0 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 7:24 UTC (permalink / raw) Cc: drew.adams, emacs-devel > From: "Richard M. Stallman" <rms@gnu.org> > CC: drew.adams@oracle.com, emacs-devel@gnu.org > Date: Mon, 27 Jun 2005 01:38:12 -0400 > > FWIW, I see nothing wrong with "Unsplit". At least one other GUI > program uses "Remove split", which is very similar; if that is better, > let's use it. > > It isn't better a priori, but if it is widely used and lots of people > would have seen it, that would make it better. What other programs > use "Remove split"? I saw it in Word. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 7:24 ` Eli Zaretskii @ 2005-06-27 11:40 ` John S. Yates, Jr. 2005-06-27 13:26 ` Lennart Borgman 0 siblings, 1 reply; 80+ messages in thread From: John S. Yates, Jr. @ 2005-06-27 11:40 UTC (permalink / raw) Cc: rms, drew.adams, emacs-devel On Mon, 27 Jun 2005 09:24:33 +0200, you wrote: >> It isn't better a priori, but if it is widely used and lots of people >> would have seen it, that would make it better. What other programs >> use "Remove split"? > >I saw it in Word. Yes, though I wonder how many Word users are aware of its existence or actually use it. OTOH Excel users use it all the time. /john ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 11:40 ` John S. Yates, Jr. @ 2005-06-27 13:26 ` Lennart Borgman 2005-06-27 18:41 ` Eli Zaretskii 2005-06-28 4:17 ` File menu changes (suggestions) Richard M. Stallman 0 siblings, 2 replies; 80+ messages in thread From: Lennart Borgman @ 2005-06-27 13:26 UTC (permalink / raw) Cc: Eli Zaretskii, rms, drew.adams, emacs-devel John S. Yates, Jr. wrote: >On Mon, 27 Jun 2005 09:24:33 +0200, you wrote: > > > >>>It isn't better a priori, but if it is widely used and lots of people >>>would have seen it, that would make it better. What other programs >>>use "Remove split"? >>> >>> >>I saw it in Word. >> >> > >Yes, though I wonder how many Word users are aware of its existence >or actually use it. OTOH Excel users use it all the time. > > But at least in Word it is in another kind of context I believe: - A window is what we call a frame. "Split Window" would be "Split Frame". - You can only split in two parts. - The two parts contains the same file. In this context "Remove Split" is meaningful and does the opposite of "Split Window". ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 13:26 ` Lennart Borgman @ 2005-06-27 18:41 ` Eli Zaretskii [not found] ` <42C044F3.60606@student.lu.se> 2005-06-28 18:46 ` Richard M. Stallman 2005-06-28 4:17 ` File menu changes (suggestions) Richard M. Stallman 1 sibling, 2 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-06-27 18:41 UTC (permalink / raw) Cc: emacs-devel > Date: Mon, 27 Jun 2005 15:26:52 +0200 > From: Lennart Borgman <lennart.borgman.073@student.lu.se> > CC: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, drew.adams@oracle.com, > emacs-devel@gnu.org > > - A window is what we call a frame. "Split Window" would be "Split Frame". > - You can only split in two parts. > - The two parts contains the same file. > > In this context "Remove Split" is meaningful and does the opposite of > "Split Window". Except that "Remove Split" doesn't say which split it removes, and thus leaves even the meaning of ``remove'' ambiguous. ^ permalink raw reply [flat|nested] 80+ messages in thread
[parent not found: <42C044F3.60606@student.lu.se>]
[parent not found: <uzmtbeam9.fsf@gnu.org>]
* Re: File menu changes (suggestions) [not found] ` <uzmtbeam9.fsf@gnu.org> @ 2005-06-27 21:06 ` Lennart Borgman 0 siblings, 0 replies; 80+ messages in thread From: Lennart Borgman @ 2005-06-27 21:06 UTC (permalink / raw) Eli Zaretskii wrote: >No, I understood you perfectly. I still submit that the exact meaning >of "split" in "remove split" is more ambiguous than "remove split >between windows" or simply "unsplit window". > > And I just suggested "Remove Window Splitting" - but now I realize it is ambigous... Hm. "Remove All Splitting", hm "Unsplit Windows" - not the pluralis. Hm. >From my own arguing on the list I actually feel that "Unsplit Windows" might be better. Less ambigous. Shorter. Contains both "split" and "window" (good for grouping the items logically). "Unsplit Frame Windows" - less ambigous still. ("Unsplit All Windows" is a bit more ambigous.) So I would go for "Unsplit Frame Windows". It misses that "One" but it is better for the text of logical grouping in the menus. The "One" will be implied I guess. But "unsplit" tastes bad. Maybe I just need education in english? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 18:41 ` Eli Zaretskii [not found] ` <42C044F3.60606@student.lu.se> @ 2005-06-28 18:46 ` Richard M. Stallman 2005-06-28 18:54 ` Lennart Borgman 2005-06-29 16:05 ` Sticks! (was: File menu changes (suggestions)) Drew Adams 1 sibling, 2 replies; 80+ messages in thread From: Richard M. Stallman @ 2005-06-28 18:46 UTC (permalink / raw) Cc: lennart.borgman.073, emacs-devel Except that "Remove Split" doesn't say which split it removes, and thus leaves even the meaning of ``remove'' ambiguous. I see no ambiguity. It removes the split which exists. What other split could it remove? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 18:46 ` Richard M. Stallman @ 2005-06-28 18:54 ` Lennart Borgman 2005-06-29 16:05 ` Sticks! (was: File menu changes (suggestions)) Drew Adams 1 sibling, 0 replies; 80+ messages in thread From: Lennart Borgman @ 2005-06-28 18:54 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel Richard M. Stallman wrote: > Except that "Remove Split" doesn't say which split it removes, and > thus leaves even the meaning of ``remove'' ambiguous. > >I see no ambiguity. It removes the split which exists. >What other split could it remove? > > English is not my mohter tongue but it sounds to me like "remove one split" (which?). Maybe "Remove Splitting", "Remove Splits"? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Sticks! (was: File menu changes (suggestions)) 2005-06-28 18:46 ` Richard M. Stallman 2005-06-28 18:54 ` Lennart Borgman @ 2005-06-29 16:05 ` Drew Adams 1 sibling, 0 replies; 80+ messages in thread From: Drew Adams @ 2005-06-29 16:05 UTC (permalink / raw) Sticks and stones will break one's bones, but names... STICKS!, THE GAME 1. Each player starts with one stick of wood. A player's sticks are his "collection". Each stick is identifiable by an identifier. 2. At any time, there is one stick in a player's collection that is his "favorite". A player can change favorites at any time, during his turn to play. 3. Additional sticks, of various kinds of wood, are available from the "stick supply". There is no limit to the supply. 4. At his turn, each player takes a card, reads it, and follows its instructions. 5. Possible cards (instructions): - Add a stick to your collection. It becomes your favorite stick. - Add a stick of the same kind of wood as your favorite to your collection. It becomes your favorite stick. - Add a stick to your collection. It does not become your favorite stick. - Split your favorite stick in two (giving you another stick). One of these two sticks retains the identity of the original, and it remains your favorite. The other stick has a new identity. - Remove your favorite stick from your collection. The previous favorite becomes your new favorite. - Remove a non-favorite stick from your collection. - Remove all sticks from your collection, except for your favorite. There are multiple cards of each kind in the deck. 6. The object of the game is be the first to get back to having only one stick. THE CHALLENGE The Great Newbie United company produces the game STICKS!. For the next version of STICKS!, GNU has decided to replace all instructions on cards by simple slogans, or names. It has decided on names for most of the cards, but it is having a contest to come up with the best name for the two cards with these instructions: Card 1. "Remove all sticks from your collection, except for your favorite". Card 2. "Split your favorite stick in two (giving you another stick)." So far, most contest entries fall into these two camps: Camp a (remove/add). These include names like these: For Card 1: One Stick, Only One Stick, Single Stick, Just This Stick, Maximize, Remove Other Sticks, Absorb Other Sticks, Devour Other Sticks, Ingest Other Sticks, Conquer Other Sticks For Card 2: New Stick, Clone Stick, Duplicate Stick Camp b (unsplit/split). These include names like these: For Card 1: Unsplit, Unsplit Stick, Unsplit Sticks, Unsplit All, Unsplit All Sticks, Remove Split, Remove Splits, Remove Stick Splitting, Remove All Splitting, Unsplit Collection Sticks For Card 2: Split Stick The Great Newbie himself, who likes things short and clear, will choose the winning entry. [Translator's note: I added "Clone Stick" and "Duplicate Stick" for card 2. I changed "Delete Other Sticks" to "Remove Other Sticks". All the rest were actual contest entries.] [Editor's note: The translator himself is in camp a, preferring "Remove Other Sticks" for card 1 and "Clone Stick" for card 2.] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-27 13:26 ` Lennart Borgman 2005-06-27 18:41 ` Eli Zaretskii @ 2005-06-28 4:17 ` Richard M. Stallman 2005-06-28 6:39 ` David Kastrup 1 sibling, 1 reply; 80+ messages in thread From: Richard M. Stallman @ 2005-06-28 4:17 UTC (permalink / raw) Cc: eliz, emacs-devel, drew.adams, john - A window is what we call a frame. "Split Window" would be "Split Frame". - You can only split in two parts. - The two parts contains the same file. In this context "Remove Split" is meaningful and does the opposite of "Split Window". Our "Split Window" operation does split into two parts that show the same file (more generally, same buffer). So "Remove Split" fits well. Both of them are more general than that, but I think users will understand that generalization. "Single Window" also seems like it might be a good name. So it is between those two. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 4:17 ` File menu changes (suggestions) Richard M. Stallman @ 2005-06-28 6:39 ` David Kastrup 0 siblings, 0 replies; 80+ messages in thread From: David Kastrup @ 2005-06-28 6:39 UTC (permalink / raw) Cc: Lennart Borgman, eliz, john, drew.adams, emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > - A window is what we call a frame. "Split Window" would be "Split Frame". > - You can only split in two parts. > - The two parts contains the same file. > > In this context "Remove Split" is meaningful and does the opposite of > "Split Window". > > Our "Split Window" operation does split into two parts that show > the same file (more generally, same buffer). So "Remove Split" > fits well. "Remove Splits" would probably be more fitting, as the frame is completely unsplit afterwards and all splitting operations are undone. > "Single Window" also seems like it might be a good name. > > So it is between those two. One problem I see with that is that beginners, one of the main audiences for menus, might feel less secure with Emacs terminology and the difference between frames and windows. Since splitting can't really apply to frames (which are separate items on the desktop), "Remove Splits" would probably feel less ambiguous to a beginner. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-26 4:46 ` Richard M. Stallman 2005-06-26 5:29 ` Lennart Borgman 2005-06-26 18:53 ` Eli Zaretskii @ 2005-06-28 5:28 ` Stefan Monnier 2005-06-28 7:17 ` Lennart Borgman ` (4 more replies) 2 siblings, 5 replies; 80+ messages in thread From: Stefan Monnier @ 2005-06-28 5:28 UTC (permalink / raw) Cc: Drew Adams, emacs-devel > 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. 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. 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]. 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. I guess I'm just repeating what Miles and Eli have said. Stefan ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 5:28 ` Stefan Monnier @ 2005-06-28 7:17 ` Lennart Borgman 2005-06-28 10:05 ` John S. Yates, Jr. ` (3 subsequent siblings) 4 siblings, 0 replies; 80+ messages in thread From: Lennart Borgman @ 2005-06-28 7:17 UTC (permalink / raw) Cc: rms, Drew Adams, emacs-devel Stefan Monnier wrote: >Rather than change menu entries's names to less "standard" ones, we should >change their behavior to better match what users expect. > >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. > > Agree. >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. > >I guess I'm just repeating what Miles and Eli have said. > > I too repeat and agree. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 5:28 ` Stefan Monnier 2005-06-28 7:17 ` Lennart Borgman @ 2005-06-28 10:05 ` John S. Yates, Jr. 2005-06-30 21:30 ` Richard M. Stallman 2005-06-28 15:28 ` Drew Adams ` (2 subsequent siblings) 4 siblings, 1 reply; 80+ messages in thread From: John S. Yates, Jr. @ 2005-06-28 10:05 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 10:05 ` John S. Yates, Jr. @ 2005-06-30 21:30 ` Richard M. Stallman 2005-06-30 22:15 ` Miles Bader 0 siblings, 1 reply; 80+ messages in thread From: Richard M. Stallman @ 2005-06-30 21:30 UTC (permalink / raw) Cc: monnier, emacs-devel >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. I think that is a good idea. It follows the design of Emacs, but it warns users who are confused. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-30 21:30 ` Richard M. Stallman @ 2005-06-30 22:15 ` Miles Bader 2005-07-01 22:45 ` Richard M. Stallman 0 siblings, 1 reply; 80+ messages in thread From: Miles Bader @ 2005-06-30 22:15 UTC (permalink / raw) Cc: emacs-devel, monnier, John S. Yates, Jr. 2005/7/1, Richard M. Stallman <rms@gnu.org>: > >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. > > I think that is a good idea. It follows the design of Emacs, > but it warns users who are confused. (defun new-file (filename) (interactive) (let ((find-file-confirm-existing t)) (find-file filename))) -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-30 22:15 ` Miles Bader @ 2005-07-01 22:45 ` Richard M. Stallman 2005-07-02 2:32 ` Miles Bader 0 siblings, 1 reply; 80+ messages in thread From: Richard M. Stallman @ 2005-07-01 22:45 UTC (permalink / raw) Cc: emacs-devel, monnier, john (defun new-file (filename) (interactive) (let ((find-file-confirm-existing t)) (find-file filename))) That is a fine way, but the variable find-file-confirm-existing doesn't seem to exist yet. Would you like to implement this? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-07-01 22:45 ` Richard M. Stallman @ 2005-07-02 2:32 ` Miles Bader 0 siblings, 0 replies; 80+ messages in thread From: Miles Bader @ 2005-07-02 2:32 UTC (permalink / raw) Cc: john, emacs-devel, monnier, miles 2005/7/2, Richard M. Stallman <rms@gnu.org>: > (defun new-file (filename) > (interactive) > (let ((find-file-confirm-existing t)) > (find-file filename))) > > Would you like to implement this? Er, sure. -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: File menu changes (suggestions) 2005-06-28 5:28 ` Stefan Monnier 2005-06-28 7:17 ` Lennart Borgman 2005-06-28 10:05 ` John S. Yates, Jr. @ 2005-06-28 15:28 ` Drew Adams 2005-06-28 16:01 ` Lennart Borgman 2005-06-28 19:46 ` Eli Zaretskii 2005-07-01 1:45 ` public 4 siblings, 1 reply; 80+ messages in thread From: Drew Adams @ 2005-06-28 15:28 UTC (permalink / raw) find-file might require confirmation before opening a non-existent file. "New File" entry ... prompt for a file name and require confirmation if the file already exists. Good solutions, both. Thanks. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 15:28 ` Drew Adams @ 2005-06-28 16:01 ` Lennart Borgman 0 siblings, 0 replies; 80+ messages in thread From: Lennart Borgman @ 2005-06-28 16:01 UTC (permalink / raw) Cc: emacs-devel Drew Adams wrote: > find-file might require confirmation before opening > a non-existent file. > > "New File" entry ... prompt for a file name and require > confirmation if the file already exists. > >Good solutions, both. Thanks. > > I agree too. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 5:28 ` Stefan Monnier ` (2 preceding siblings ...) 2005-06-28 15:28 ` Drew Adams @ 2005-06-28 19:46 ` Eli Zaretskii 2005-06-28 21:36 ` Miles Bader 2005-07-01 1:45 ` public 4 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-28 19:46 UTC (permalink / raw) Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Tue, 28 Jun 2005 01:28:53 -0400 > Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org > > Rather than change menu entries's names to less "standard" ones, we should > change their behavior to better match what users expect. Yes, I agree. File->New seems like a case in point. > 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]. > > 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. Yet another variety would be to create a buffer which does have a file, call it "Unnamed" or some such (i.e., in the default directory), and if such a file already exists, modify it by attaching something like a number. > I guess I'm just repeating what Miles and Eli have said. Ah, so that's why I agree with you ;-) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 19:46 ` Eli Zaretskii @ 2005-06-28 21:36 ` Miles Bader 2005-06-28 22:00 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 80+ messages in thread From: Miles Bader @ 2005-06-28 21:36 UTC (permalink / raw) Cc: Stefan Monnier, emacs-devel On 6/29/05, Eli Zaretskii <eliz@gnu.org> wrote: > Yet another variety would be to create a buffer which does have a > file, call it "Unnamed" or some such (i.e., in the default directory), > and if such a file already exists, modify it by attaching something > like a number. I think the default emacs behavior (if the buffer doesn't have a name, ask for one when saving) is far better. You could create new _buffer_ names like "unnamed" or whatever, but actually setting the _file_ name to that seems harmful. -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 21:36 ` Miles Bader @ 2005-06-28 22:00 ` David Kastrup 2005-06-30 7:40 ` Miles Bader 2005-06-29 3:39 ` Stefan Monnier 2005-06-29 20:43 ` Richard M. Stallman 2 siblings, 1 reply; 80+ messages in thread From: David Kastrup @ 2005-06-28 22:00 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel, Stefan Monnier, miles Miles Bader <snogglethorpe@gmail.com> writes: > On 6/29/05, Eli Zaretskii <eliz@gnu.org> wrote: >> Yet another variety would be to create a buffer which does have a >> file, call it "Unnamed" or some such (i.e., in the default >> directory), and if such a file already exists, modify it by >> attaching something like a number. > > I think the default emacs behavior (if the buffer doesn't have a > name, ask for one when saving) is far better. You could create new > _buffer_ names like "unnamed" or whatever, but actually setting the > _file_ name to that seems harmful. How does autosave work with an unnamed buffer? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 22:00 ` David Kastrup @ 2005-06-30 7:40 ` Miles Bader 0 siblings, 0 replies; 80+ messages in thread From: Miles Bader @ 2005-06-30 7:40 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel, Stefan Monnier, miles 2005/6/29, David Kastrup <dak@gnu.org>: > How does autosave work with an unnamed buffer? It tries to concoct an auto-save filename from the buffer name (remember, buffers always have names, but not always filenames) and a few likely directories. -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 21:36 ` Miles Bader 2005-06-28 22:00 ` David Kastrup @ 2005-06-29 3:39 ` Stefan Monnier 2005-06-29 4:45 ` Miles Bader ` (2 more replies) 2005-06-29 20:43 ` Richard M. Stallman 2 siblings, 3 replies; 80+ messages in thread From: Stefan Monnier @ 2005-06-29 3:39 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel, miles >> Yet another variety would be to create a buffer which does have a >> file, call it "Unnamed" or some such (i.e., in the default directory), >> and if such a file already exists, modify it by attaching something >> like a number. > I think the default emacs behavior (if the buffer doesn't have a name, > ask for one when saving) is far better. You could create new > _buffer_ names like "unnamed" or whatever, but actually setting the > _file_ name to that seems harmful. It all depends on whether other parts of the code would be adjusted or not. The important issues about the behavior of "new files" (whose file name has not yet been set): - make sure C-x C-s prompts for a file name. - make sure autosave works. - make sure the auto-save-list includes the new files. - there might be more. Of course the other option of prompting for a file name before creating the new buffer solves all the above problems (along with the others that have to do with the choice of major mode, ...), which is why I'm in favor of that one, even if it's a bit less CUA-ish. Stefan ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-29 3:39 ` Stefan Monnier @ 2005-06-29 4:45 ` Miles Bader 2005-06-29 18:51 ` Eli Zaretskii 2005-06-30 1:44 ` Richard M. Stallman 2005-06-30 5:38 ` David Kastrup 2 siblings, 1 reply; 80+ messages in thread From: Miles Bader @ 2005-06-29 4:45 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel, miles On 6/29/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > - make sure C-x C-s prompts for a file name. This seems to work already if you save a buffer with no associated filename. > Of course the other option of prompting for a file name before creating the > new buffer solves all the above problems (along with the others that have to > do with the choice of major mode, ...), which is why I'm in favor of that > one, even if it's a bit less CUA-ish. It's also often very annoying to be forced to pick a filename upfront... Granted that one can "rename" the file by using save-as before ever using save, but it's step one has to remember to do (and one I often forget). I think the changes you note would actually be very good to have around regardless of the menu issue actually -- I often want to create a file which may or may not be temporary, which I want to be auto-saved, but which I don't know the name of yet. My current solution is to visit "/tmp/,blah" or whatever, and then use C-x C-w to save it when I decide upon a name, but it'd be cool if I could set things up so that there was some way of identifying which non-file-associated buffers should be auto-saved. -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-29 4:45 ` Miles Bader @ 2005-06-29 18:51 ` Eli Zaretskii 2005-06-29 23:46 ` Miles Bader 0 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-06-29 18:51 UTC (permalink / raw) Cc: emacs-devel > Date: Wed, 29 Jun 2005 13:45:16 +0900 > From: Miles Bader <snogglethorpe@gmail.com> > Cc: miles@gnu.org, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > On 6/29/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > - make sure C-x C-s prompts for a file name. > > This seems to work already if you save a buffer with no associated filename. True; but what about if you kill Emacs? IIRC, a buffer that has no associated file will not cause Emacs to prompt for saving it, right? That's why I suggested to pick some mundane file name automatically. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-29 18:51 ` Eli Zaretskii @ 2005-06-29 23:46 ` Miles Bader 0 siblings, 0 replies; 80+ messages in thread From: Miles Bader @ 2005-06-29 23:46 UTC (permalink / raw) Cc: emacs-devel, miles 2005/6/30, Eli Zaretskii <eliz@gnu.org>: > > This seems to work already if you save a buffer with no associated filename. > > True; but what about if you kill Emacs? IIRC, a buffer that has no > associated file will not cause Emacs to prompt for saving it, right? > That's why I suggested to pick some mundane file name automatically. I don't think we should be creating random filenames, and I think we should treat such "new" buffers more like (though not entirely like) scratch buffers than normal file-visiting buffers. However, if someone creates a buffer with a "New File" menu item, it is actually somewhat more likely that they intended to save it. So I can envision a "New File" menu item that would (1) keep the buffer-file-name `nil', but (2) turn on auto-save mode, and (3) mark the buffer specially so that exit-emacs asks about saving it (and if you answer `y', asks you for a filename). [Of course scratch buffers created the old-fashioned way should continue to be not saved by default; that's far too ingrained to change I think. Maybe a non-menu user would want to use "M-x new-file" sometimes though...] -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-29 3:39 ` Stefan Monnier 2005-06-29 4:45 ` Miles Bader @ 2005-06-30 1:44 ` Richard M. Stallman 2005-06-30 5:38 ` David Kastrup 2 siblings, 0 replies; 80+ messages in thread From: Richard M. Stallman @ 2005-06-30 1:44 UTC (permalink / raw) Cc: miles, eliz, snogglethorpe, emacs-devel The Emacs design decision is to guide users to specify the file name when creating the buffer. We don't want them to leave it for later. So we will not change the interface to encourage users to leave the file name for later. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-29 3:39 ` Stefan Monnier 2005-06-29 4:45 ` Miles Bader 2005-06-30 1:44 ` Richard M. Stallman @ 2005-06-30 5:38 ` David Kastrup 2 siblings, 0 replies; 80+ messages in thread From: David Kastrup @ 2005-06-30 5:38 UTC (permalink / raw) Cc: miles, Eli Zaretskii, snogglethorpe, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> Yet another variety would be to create a buffer which does have a >>> file, call it "Unnamed" or some such (i.e., in the default directory), >>> and if such a file already exists, modify it by attaching something >>> like a number. > >> I think the default emacs behavior (if the buffer doesn't have a name, >> ask for one when saving) is far better. You could create new >> _buffer_ names like "unnamed" or whatever, but actually setting the >> _file_ name to that seems harmful. > > It all depends on whether other parts of the code would be adjusted or not. > The important issues about the behavior of "new files" (whose file name has > not yet been set): > - make sure C-x C-s prompts for a file name. > - make sure autosave works. > - make sure the auto-save-list includes the new files. > - there might be more. I think the main point is that the mode is set from auto-mode-alist, and that things like auto-insert work. Specifying the file name saves specifying mode and stuff. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 21:36 ` Miles Bader 2005-06-28 22:00 ` David Kastrup 2005-06-29 3:39 ` Stefan Monnier @ 2005-06-29 20:43 ` Richard M. Stallman 2 siblings, 0 replies; 80+ messages in thread From: Richard M. Stallman @ 2005-06-29 20:43 UTC (permalink / raw) Cc: eliz, monnier, emacs-devel > Yet another variety would be to create a buffer which does have a > file, call it "Unnamed" or some such (i.e., in the default directory), > and if such a file already exists, modify it by attaching something > like a number. I am not willing to distort Emacs that far just to fit the mold of someone else's interface. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: File menu changes (suggestions) 2005-06-28 5:28 ` Stefan Monnier ` (3 preceding siblings ...) 2005-06-28 19:46 ` Eli Zaretskii @ 2005-07-01 1:45 ` public 4 siblings, 0 replies; 80+ messages in thread From: public @ 2005-07-01 1:45 UTC (permalink / raw) Stefan Monnier <monnier@iro.umontreal.ca> writes: > 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. Here is what I use in Easymacs, which I have modified from http://www-xray.ast.cam.ac.uk/~gmorris/dotemacs.html -- I just added the make-directory bit. (defadvice find-file (around confirm-new-file activate) "If file does not exist, prompt." (let ((file (ad-get-arg 0))) (when (or (not (interactive-p)) (find-buffer-visiting file) (string-match "\\`/\\[" file) ; old-style TRAMP (string-match "\\`/[a-zA-Z0-9@]:" file) ; new-style TRAMP (file-directory-p file) ;; file-exists-p does not handle wildcards. (file-expand-wildcards file) ;; A nice trick, but not necessary. ;;; (string-match "0\n\\'" (shell-command-to-string ;;; (format "ls %s; echo $?" file))) (yes-or-no-p (format "`%s' does not exist, create new file? " file))) ;; Is this a good idea? If we open a new file by accident, ;; despite the confirmation, we probably don't want the directory. (unless (file-directory-p (file-name-directory file)) (make-directory (file-name-directory file) t)) ad-do-it))) (defadvice switch-to-buffer (around confirm-new-buffer activate) "If buffer does not exist, prompt." (let ((buff (ad-get-arg 0))) (if (or (not (interactive-p)) (get-buffer buff) (yes-or-no-p (format "`%s' does not exist, create new file? " buff))) ad-do-it))) ^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2005-07-02 2:32 UTC | newest] Thread overview: 80+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-06-19 23:25 File menu changes (suggestions) Drew Adams 2005-06-20 4:56 ` Eli Zaretskii 2005-06-20 7:03 ` David Kastrup 2005-06-20 16:53 ` Drew Adams 2005-06-20 20:37 ` Eli Zaretskii 2005-06-20 20:48 ` Drew Adams 2005-06-21 2:01 ` Richard Stallman 2005-06-21 7:59 ` Mathias Dahl 2005-06-21 9:19 ` Miles Bader 2005-06-26 4:46 ` Richard M. Stallman 2005-06-26 5:29 ` Lennart Borgman 2005-06-26 22:42 ` Richard M. Stallman 2005-06-26 22:52 ` Lennart Borgman 2005-06-26 23:13 ` Drew Adams 2005-06-27 7:20 ` Eli Zaretskii 2005-06-27 7:37 ` Kim F. Storm 2005-06-27 9:25 ` Miles Bader 2005-06-27 13:29 ` David Kastrup 2005-06-28 4:16 ` Richard M. Stallman 2005-06-26 18:53 ` Eli Zaretskii 2005-06-26 18:00 ` Lennart Borgman 2005-06-26 19:09 ` Eli Zaretskii 2005-06-26 18:20 ` Drew Adams 2005-06-26 19:41 ` John S. Yates, Jr. [not found] ` <42BF0E53.2020505@student.lu.se> 2005-06-27 12:51 ` John S. Yates, Jr. 2005-06-27 13:31 ` David Kastrup 2005-06-27 17:47 ` Robert J. Chassell 2005-06-28 1:57 ` John S. Yates, Jr. 2005-06-27 13:24 ` David Kastrup 2005-06-27 16:18 ` Drew Adams 2005-06-27 18:44 ` Eli Zaretskii 2005-06-27 18:13 ` Drew Adams 2005-06-27 22:19 ` Eli Zaretskii 2005-06-27 22:33 ` Drew Adams 2005-06-28 4:53 ` Eli Zaretskii 2005-06-28 6:36 ` David Kastrup 2005-06-26 18:30 ` Jason Rumney 2005-06-27 2:06 ` Miles Bader 2005-06-27 7:24 ` Eli Zaretskii 2005-06-27 6:31 ` Miles Bader 2005-06-27 13:26 ` David Kastrup 2005-06-27 18:26 ` Eli Zaretskii 2005-06-27 9:19 ` Jason Rumney 2005-06-27 9:41 ` Miles Bader 2005-06-27 18:25 ` Eli Zaretskii 2005-06-27 20:05 ` David Kastrup 2005-06-27 20:47 ` Lennart Borgman 2005-06-27 21:40 ` Eli Zaretskii 2005-06-27 5:38 ` Richard M. Stallman 2005-06-27 7:24 ` Eli Zaretskii 2005-06-27 11:40 ` John S. Yates, Jr. 2005-06-27 13:26 ` Lennart Borgman 2005-06-27 18:41 ` Eli Zaretskii [not found] ` <42C044F3.60606@student.lu.se> [not found] ` <uzmtbeam9.fsf@gnu.org> 2005-06-27 21:06 ` Lennart Borgman 2005-06-28 18:46 ` Richard M. Stallman 2005-06-28 18:54 ` Lennart Borgman 2005-06-29 16:05 ` Sticks! (was: File menu changes (suggestions)) Drew Adams 2005-06-28 4:17 ` File menu changes (suggestions) Richard M. Stallman 2005-06-28 6:39 ` David Kastrup 2005-06-28 5:28 ` Stefan Monnier 2005-06-28 7:17 ` Lennart Borgman 2005-06-28 10:05 ` John S. Yates, Jr. 2005-06-30 21:30 ` Richard M. Stallman 2005-06-30 22:15 ` Miles Bader 2005-07-01 22:45 ` Richard M. Stallman 2005-07-02 2:32 ` Miles Bader 2005-06-28 15:28 ` Drew Adams 2005-06-28 16:01 ` Lennart Borgman 2005-06-28 19:46 ` Eli Zaretskii 2005-06-28 21:36 ` Miles Bader 2005-06-28 22:00 ` David Kastrup 2005-06-30 7:40 ` Miles Bader 2005-06-29 3:39 ` Stefan Monnier 2005-06-29 4:45 ` Miles Bader 2005-06-29 18:51 ` Eli Zaretskii 2005-06-29 23:46 ` Miles Bader 2005-06-30 1:44 ` Richard M. Stallman 2005-06-30 5:38 ` David Kastrup 2005-06-29 20:43 ` Richard M. Stallman 2005-07-01 1:45 ` public
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.