* emacs mode line suggestions [not found] <mailman.215.1226562978.26697.help-gnu-emacs@gnu.org> @ 2008-11-14 23:18 ` Xah 2008-11-15 1:02 ` xahlee ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Xah @ 2008-11-14 23:18 UTC (permalink / raw) To: help-gnu-emacs On Nov 12, 11:55 pm, anhnmncb <anhnm...@sina.com> wrote: > Mouse when on modeline, and popup buffers menu by C-<left mouse> can be > used to change to other buffers, both of which are not what I want, can > I disable it? don't know. lol. I think the mode line is another of emacs's problem. Here's what i think are better default: • that the buffer location percentage should by default not shown if emacs is running in GUI with scroll bar. • clicking on the file name should not switch buffer. It could do contextual menu listing user buffers instead. (user buffer here are those not starting with “*”) • Minor mode should not be displayed there. It's confusing. Instead, the major mode can add a “mode” word after it. So this is more intuitive. (The idea of Minor modes are kinda confusing. They should be thought of as Preferences (Mac-speak) or Options (Windows-speak), which is what they mostly are used as.) • Clicking on the major mode name should pop up a contextual menu to let user switch to major major modes. (e.g. C, C++, java, perl, php, bash, javascript, html/xml, python, text, LaTeX.) • line number mode should be on by default. So that, the line number shows in the mode line. • the start of the mode line, showing like “-u:**”, “%%”, “%*”... are quite cryptic. Having used emacs for 10 years, these are still not burned into my brain. And it's not easy to look them up what they are until you are emacs diehard. (e.g. you'll have to know it's technically called “mode line”, then you'll have to know about emacs- index-search, and in general familiar with info and the bunch of emacs only terminologies) It'd better to instead say “Read Only” instead of “%*”, and show “Modified” instead of the “**”. (don't show anything when it's “--”) The coding system shown in mode line should be removed. The current coding system should be shown in the menu somewhere, and allow users to change thru menu. --------------------- Summary: So, i think the mode line should be like this: ‹buffer name› linePos/charPos (‹major mode name›)------‹status›--- where the status can be Modified or Read Only. Also, when editing as root, it'd be nice to indicate it in mode line. Some indication of being root is a frequently requested feature. Clicking on the buffer name should show menu list of user buffers, those not starting with a *. Clicking on linePos/charPos show a menu that allow user to turn on/off line number mode or char number mode. Clicking on the major mode name should show a menu of commonly used major modes, allowing user a easy way to switch. (currently, emacs has no intuitive way for user to switch a mode or know what modes are available. This is also a FAQ item.) Clicking on the “status” should show a menu allowing user to toggle read only. All these clicking should be Right Click, which is more standard behavior of clicking on things for contextual menu. (e.g. in Mac and Windows system wide, and in Firefox for example) Optionally, to the very right of the status bar could have a “i” or “info”, and when clicked, it shows all the current modified/read status, mode settings, minor modes, encoding used, etc of the current buffer. This can be done as a new split window much like C-h f would. In the result pane, it can show status of other buffer local vars that are related to text editing (such as case sensitive search, how lines are wrapped, length for truncation, margin ... ). With links or active text that lets user toggle or set new vals easily (similar to the UI of customize). Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-14 23:18 ` emacs mode line suggestions Xah @ 2008-11-15 1:02 ` xahlee 2008-11-15 9:23 ` Eli Zaretskii [not found] ` <mailman.423.1226741023.26697.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 39+ messages in thread From: xahlee @ 2008-11-15 1:02 UTC (permalink / raw) To: help-gnu-emacs On Nov 14, 3:18 pm, Xah <xah...@gmail.com> wrote: > On Nov 12, 11:55 pm, anhnmncb <anhnm...@sina.com> wrote: > > > Mouse when on modeline, and popup buffers menu by C-<left mouse> can be > > used to change to other buffers, both of which are not what I want, can > > I disable it? > > don't know. > > lol. I think the mode line is another of emacs's problem. > > Here's what i think are better default: > ... I've taken sometime to make a more coherent argument on suggestions for emacs mode line. Please see here: http://xahlee.org/emacs/modernization_mode_line.html Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-14 23:18 ` emacs mode line suggestions Xah 2008-11-15 1:02 ` xahlee @ 2008-11-15 9:23 ` Eli Zaretskii [not found] ` <mailman.423.1226741023.26697.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2008-11-15 9:23 UTC (permalink / raw) To: help-gnu-emacs > From: Xah <xahlee@gmail.com> > Date: Fri, 14 Nov 2008 15:18:31 -0800 (PST) > > • that the buffer location percentage should by default not shown if > emacs is running in GUI with scroll bar. This is already the default on _all_ types of displays, and has been so since day one, even when Emacs didn't support scroll bars. > • clicking on the file name should not switch buffer. That's not the file name, that's the buffer name. As for what it should do, I don't see why your preference is better than the current one. Popping a menu requires another click to actually select a buffer, whereas the current behavior does it in one click. Since there's a menu-bar menu item to do what you want, I don't see a problem. > • Minor mode should not be displayed there. It's confusing. Emacs always displayed it. Get used to it. > • Clicking on the major mode name should pop up a contextual menu to > let user switch to major major modes. Switching a major mode is a very rare command, so having this at your fingertips makes no sense, IMO. > • line number mode should be on by default. So that, the line number > shows in the mode line. This already is the default. > The coding system shown in mode line should be removed. The current > coding system should be shown in the menu somewhere It's an important piece of information, and takes only one position in the mode line. I always hated the way IE and Outlook hide this somewhere under View, because I might wish to know the current encoding even if I don't need to switch it. > and allow users to change [coding system] thru menu. Emacs does have the change encoding part in the menu. ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.423.1226741023.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.423.1226741023.26697.help-gnu-emacs@gnu.org> @ 2008-11-16 1:54 ` Xah 2008-11-16 18:12 ` Ian Eure ` (3 more replies) 0 siblings, 4 replies; 39+ messages in thread From: Xah @ 2008-11-16 1:54 UTC (permalink / raw) To: help-gnu-emacs On Nov 15, 1:23 am, Eli Zaretskii <e...@gnu.org> wrote: > > From:Xah<xah...@gmail.com> > > Date: Fri, 14 Nov 2008 15:18:31 -0800 (PST) > > > • that the buffer location percentage should by default not shown if > > emacs is running in GUI with scroll bar. > > This is already the default on _all_ types of displays, and has been > so since day one, even when Emacs didn't support scroll bars. umm? on my carbon emacs (based on emacs 22.x), it still show cursor location percentage. In my x11 emacs running in gui (emacs 21.x) with scroll bar, it also shows this percentage. > > • clicking on the file name should not switch buffer. > > That's not the file name, that's the buffer name. please get the over all picture, not bone picking. > As for what it should do, I don't see why your preference is better > than the current one. Popping a menu requires another click to > actually select a buffer, whereas the current behavior does it in one > click. typically, a user has several user buffers open, and as far as i guess many programers who use emacs extensively has like hundreds of buffers open. Cycling them one by one is not much useful. Counting emacs's own buffers, those info, messages, scratch, completions, grep output, shell output, C-h f and friends output, dictionary lookup output, ispell output, man page output ... etc... these are typically looked once and not useful afterwards. Switching and cycling thru them are not much useful. > Since there's a menu-bar menu item to do what you want, I > don't see a problem. it's more about what would be a useful behavior for clicking on the buffer name section of mode line, not about whether suggested functionality already exists somewhere. For example, the functionality of cycling thru buffers also is already in the menu under Buffers. i don't necessarily disagree with every point you make. But please consider the over all suggestion, as opposed to seeming to have a nay- say attitude and turn down the whole thing. > > • Minor mode should not be displayed there. It's confusing. > > Emacs always displayed it. Get used to it. the question is not about what emacs is. It is about what is better for emacs. if we already stick with what emacs always has been, there'd be no progress. here's a refined suggestion on the minor mode in mode line point: • Minor mode should not be displayed in mode line. It's confusing. For one reason, it by default selectively display only some of the minor modes currently on, and the selective process is not something people who intuitively understands. For the other reason, Emacs's technical concept of Minor mode is somewhat confusing. Most minor modes in practice are Preferences settings (Mac-speak) or Options (Windows- speak and Linux Desktops) from user point of view. > > • Clicking on the major mode name should pop up a contextual menu to > > let user switch to major major modes. > > Switching a major mode is a very rare command, so having this at your > fingertips makes no sense, IMO. switching between modes is not rarely used. I'd estimate it is used every other hour at least. > > • line number mode should be on by default. So that, the line number > > shows in the mode line. > > This already is the default. Opps, you are right. Thanks. > > The coding system shown in mode line should be removed. The current > > coding system should be shown in the menu somewhere > > It's an important piece of information, and takes only one position in > the mode line. I always hated the way IE and Outlook hide this > somewhere under View, because I might wish to know the current > encoding even if I don't need to switch it. > > > and allow users to change [coding system] thru menu. > > Emacs does have the change encoding part in the menu. I have refined my previous writings about the mode line suggestions. It has more neutral wording, with more explanations. This came in part when i just filed a bug report to GNU as suggestions so that developers have a chance to review this opinion. Please give it another try. The url is here: • Emacs's Mode Line Modernization Suggestions http://xahlee.org/emacs/modernization_mode_line.html plain text version follows: ----------------- Emacs's Mode Line Modernization Suggestions Xah Lee, 2008-12 This article gives some suggestions on improving emacs's “mode line”, so that it is more intuitive and useful. I think the mode line is one of emacs's problem in usability. emacs mode line above: Emacs's mode line. Here's what i think are better default: • The start of the mode line, displaying the coding system used such as “-u”, “-uuu”, and displaying the modification status like “:**”, “% %”, “%*” are quite cryptic. Having used emacs for 10 years, these are still not burned into my brain. And it's not easy to look them up what they are unless you are emacs diehard. (e.g. you'll have to know it's technically called “mode line”, then you'll have to know about emacs- index-search, and in general familiar with info and emacs) It'd better to instead say “Read Only” instead of “%*”, and show “Modified” instead of the “**”. (don't show anything when it's “--”) • The coding system shown in mode line should be removed. Because, for vast majority of programers, he rarely deals with different file coding systems or coding system change, perhaps just few times a year. It is not something programers encounter on a daily basis. Also, 3 letter-code is cryptic for conveying file coding system, especially today because there are lots of them. The current coding system should be shown perhaps in the menu somewhere, and allow users to change thru menu. For programers who deals with different file systems or coding systems hourly and need it be displayed on the mode line, perhaps emacs can introduce a customization feature so that the full coding system is displayed in modeline. • The cursor location percentage should by default not shown if emacs is running in GUI with scroll bar. (this is sometimes shown as “Top” or “Bot”) GUI scroll bar gives intuitive indication of where cursor is in relation to the whole buffer, and also gives a indication of the screen display size in relation to the buffer size, and conveys these info faster. • When emacs is running in a terminal, the special indicator “Top” and “Bot” should be shown as percentage as usual, because for someone uninitiated, consistent changing of percentage as he moves the cursor is more intuitive. The code word “Top” and “Bot” could mean many things to first time users. • Minor mode should not be displayed in mode line. It's confusing. For one reason, it by default selectively display only some of the minor modes currently on, and the selective process is not something people who intuitively understands. For the other reason, Emacs's technical concept of Minor mode is somewhat confusing. Most minor modes in practice are Preferences settings (Mac-speak) or Options (Windows- speak and Linux Desktops) from user point of view. • Line number mode should be on by default. So that, the line number shows in the mode line. How to show line number is a frequently asked question. • Clicking on the file name should not switch buffer. It could do contextual menu listing user buffers instead. (user buffer here are those not starting with “*”) • Clicking on the major mode name should pop up a contextual menu to let user switch to major modes that are familiar to majority of average programers. (e.g. C, C++, java, perl, php, bash, javascript, html/xml, python, text, LaTeX, elisp.) The menu can have a “More...” submenu to show all other available major modes. Summary I think the mode line should be like this: ‹buffer name› ‹major mode name› ‹line num› ‹status›------------------- where the status is Modified or Read Only. Here's a example of such actual display: elisp_basics.html html-mode L19 Modified------------------- Also, when editing as root, it'd be nice to indicate it in mode line. Possibly making the mode line's background red, or add a word “(root)” on the right. Some indication of being root is a frequently requested feature. If running in a GUI, clicking on the buffer name should show menu list of user buffers, those not starting with a “*”. Clicking on the major mode name should show a menu of commonly used major modes, allowing user a easy way to switch. (currently, emacs has no intuitive way for user to switch a mode or know what modes are available. This is also a FAQ item.) Clicking on linePos/charPos show a menu that allow user to turn on/off line number mode or char number mode. Clicking on the Read Only or “Modified”, should show a menu allowing user to toggle Read Only. Clicking the rest of the mode line displaying “--------”, can show all the useful info about the current buffer. For example: modified/read status, mode settings, minor modes, encoding used. This can be done as a new split window much like describe-function would. In the result pane, it can show status of other buffer local vars that are related to text editing (such as case sensitive search, how lines are wrapped, length for truncation, margin ... ). With links or active text that lets user toggle or set new vals easily (similar to the UI of the customize function). All these clicking should be Right Click, which is more standard behavior of clicking on things for contextual menu. (e.g. in Windows, Mac, Linux, system wide, and in Firefox and other browsers.) • The term “mode line” could be changed to “status bar” in the manuals. “Status bar” is more understandable to modern users. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-16 1:54 ` Xah @ 2008-11-16 18:12 ` Ian Eure 2008-11-18 9:39 ` Kevin Rodgers 2008-11-16 21:40 ` Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 39+ messages in thread From: Ian Eure @ 2008-11-16 18:12 UTC (permalink / raw) To: help-gnu-emacs On Nov 15, 2008, at 5:54 PM, Xah wrote: > On Nov 15, 1:23 am, Eli Zaretskii <e...@gnu.org> wrote: >>> From:Xah<xah...@gmail.com> >>> Date: Fri, 14 Nov 2008 15:18:31 -0800 (PST) >>> >>> • clicking on the file name should not switch buffer. >> >> That's not the file name, that's the buffer name. > > please get the over all picture, not bone picking. > >> As for what it should do, I don't see why your preference is better >> than the current one. Popping a menu requires another click to >> actually select a buffer, whereas the current behavior does it in one >> click. > > typically, a user has several user buffers open, and as far as i guess > many programers who use emacs extensively has like hundreds of buffers > open. Cycling them one by one is not much useful. > > Counting emacs's own buffers, those info, messages, scratch, > completions, grep output, shell output, C-h f and friends output, > dictionary lookup output, ispell output, man page output ... etc... > these are typically looked once and not useful afterwards. Switching > and cycling thru them are not much useful. I basically agree with this stuff. I doubt many hardcore Emacs users choose to switch buffers this way, which requires using the mouse. And the part of the behavior that is least useful is that the switch is blind - you don't know what buffer you're going to get unless you know the current state of the buffer-list. My objection is to the idea that you don't want star buffers in the list. These are also used for interaction with external processes: *ssh: host*, *SQL: foo*, *Twit-recent*, *compilation*, *shell*, *Python*. It seems ill advised to exclude those from the list. > • Minor mode should not be displayed in mode line. It's confusing. For > one reason, it by default selectively display only some of the minor > modes currently on, and the selective process is not something people > who intuitively understands. For the other reason, Emacs's technical > concept of Minor mode is somewhat confusing. Most minor modes in > practice are Preferences settings (Mac-speak) or Options (Windows- > speak and Linux Desktops) from user point of view. > Where would you suggest showing this information? Some minor modes change Emacs' behavior significantly. For example: auto-fill-mode or abbrev-mode. If these aren't in the mode line, where do you find this information? >>> • Clicking on the major mode name should pop up a contextual menu to >>> let user switch to major major modes. >> >> Switching a major mode is a very rare command, so having this at your >> fingertips makes no sense, IMO. > > switching between modes is not rarely used. I'd estimate it is used > every other hour at least. > Can you describe the use case where you do this? It sounds like you have a configuration issue, honestly. I think the only time I manually switch modes is when I need to use *scratch* for something, e.g. I'll switch to emacs-lisp-mode if I want to eval some code, sql-mode if I want to write a query, etc. I should probably write some functions to give me *lisp* and *SQL* buffers with the appropriate mode. - Ian ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-16 18:12 ` Ian Eure @ 2008-11-18 9:39 ` Kevin Rodgers 2008-11-18 23:25 ` Xavier Maillard 0 siblings, 1 reply; 39+ messages in thread From: Kevin Rodgers @ 2008-11-18 9:39 UTC (permalink / raw) To: help-gnu-emacs Ian Eure wrote: > I think the only time I manually switch modes is when I need to use > *scratch* for something, e.g. I'll switch to emacs-lisp-mode if I want > to eval some code, sql-mode if I want to write a query, etc. > > I should probably write some functions to give me *lisp* and *SQL* > buffers with the appropriate mode. I leave initial-major-mode set to lisp-interaction-mode, so *scratch* is my Emacs Lisp buffer. And I've got this in my ~/.emacs: (with-current-buffer (get-buffer-create "*Text*") (text-mode)) (with-current-buffer (get-buffer-create "*SQL*") (sql-mode)) -- Kevin Rodgers Denver, Colorado, USA ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-18 9:39 ` Kevin Rodgers @ 2008-11-18 23:25 ` Xavier Maillard 0 siblings, 0 replies; 39+ messages in thread From: Xavier Maillard @ 2008-11-18 23:25 UTC (permalink / raw) To: Kevin Rodgers; +Cc: help-gnu-emacs Ian Eure wrote: > I think the only time I manually switch modes is when I need to use > *scratch* for something, e.g. I'll switch to emacs-lisp-mode if I want > to eval some code, sql-mode if I want to write a query, etc. > > I should probably write some functions to give me *lisp* and *SQL* > buffers with the appropriate mode. I leave initial-major-mode set to lisp-interaction-mode, so *scratch* is my Emacs Lisp buffer. And I've got this in my ~/.emacs: (with-current-buffer (get-buffer-create "*Text*") (text-mode)) (with-current-buffer (get-buffer-create "*SQL*") (sql-mode)) Great idea Rogers (and so simple). For Ian, if you use SLIME, you will have access to a "lispified" *scratch* like buffer. Xavier -- http://www.gnu.org http://www.april.org http://www.lolica.org ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-16 1:54 ` Xah 2008-11-16 18:12 ` Ian Eure @ 2008-11-16 21:40 ` Eli Zaretskii [not found] ` <mailman.518.1226859137.26697.help-gnu-emacs@gnu.org> [not found] ` <mailman.536.1226871605.26697.help-gnu-emacs@gnu.org> 3 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2008-11-16 21:40 UTC (permalink / raw) To: help-gnu-emacs > From: Xah <xahlee@gmail.com> > Date: Sat, 15 Nov 2008 17:54:02 -0800 (PST) > > On Nov 15, 1:23 am, Eli Zaretskii <e...@gnu.org> wrote: > > > From:Xah<xah...@gmail.com> > > > Date: Fri, 14 Nov 2008 15:18:31 -0800 (PST) > > > > > • that the buffer location percentage should by default not shown if > > > emacs is running in GUI with scroll bar. > > > > This is already the default on _all_ types of displays, and has been > > so since day one, even when Emacs didn't support scroll bars. > > umm? on my carbon emacs (based on emacs 22.x), it still show cursor > location percentage. > > In my x11 emacs running in gui (emacs 21.x) with scroll bar, it also > shows this percentage. Please explain how you deduce that the cursor percentage is shown. Here's what I see (on MS-Windows, but that's the only GUI Emacs I can access where I type this): as long as the first and last line shown by the window don't move, I see the same percentage, no matter how I move the cursor; but when I scroll the window with "C-u 1 C-v" (which scrolls by one line without moving buffer position), the percentage starts changing, even though cursor is on the same place in the buffer. The same happens on a Unix text-only terminal. > > > • clicking on the file name should not switch buffer. > > > > That's not the file name, that's the buffer name. > > please get the over all picture, not bone picking. A veteran Emacs user who thinks he knows enough to suggest radical changes for Emacs look and feel can be expected to use the correct terminology. > > As for what it should do, I don't see why your preference is better > > than the current one. Popping a menu requires another click to > > actually select a buffer, whereas the current behavior does it in one > > click. > > typically, a user has several user buffers open, and as far as i guess > many programers who use emacs extensively has like hundreds of buffers > open. Cycling them one by one is not much useful. No one in their right mind will cycle buffers. This feature exists if your buffer is one or two away. Anything more than that, you should use the menu-bar's Buffers menu (or select the buffer by its name with C-x b). > i don't necessarily disagree with every point you make. But please > consider the over all suggestion, as opposed to seeming to have a nay- > say attitude and turn down the whole thing. The fact that we disagree doesn't say more about my attitude than it says about yours. > For one reason, it by default selectively display only some of the > minor modes currently on Perhaps because some minor modes decided not to announce themselves. For example, in the buffer where I type this I have "Fly Abbrev Fill" as the list of minor modes that I have turned on. > > > • Clicking on the major mode name should pop up a contextual menu to > > > let user switch to major major modes. > > > > Switching a major mode is a very rare command, so having this at your > > fingertips makes no sense, IMO. > > switching between modes is not rarely used. I'd estimate it is used > every other hour at least. Please provide some use-cases to back this up. FWIW, I almost never switch the major mode in the same buffer, unless Emacs didn't switch into the right one to begin with, and even then I only do that once in a given buffer. ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.518.1226859137.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.518.1226859137.26697.help-gnu-emacs@gnu.org> @ 2008-11-16 18:20 ` Richard Riley 2008-11-16 23:12 ` Ian Eure [not found] ` <mailman.543.1226877138.26697.help-gnu-emacs@gnu.org> 2008-11-16 22:45 ` Xah 1 sibling, 2 replies; 39+ messages in thread From: Richard Riley @ 2008-11-16 18:20 UTC (permalink / raw) To: help-gnu-emacs Ian Eure <ian@digg.com> writes: > On Nov 15, 2008, at 5:54 PM, Xah wrote: > >> On Nov 15, 1:23 am, Eli Zaretskii <e...@gnu.org> wrote: >>>> From:Xah<xah...@gmail.com> >>>> Date: Fri, 14 Nov 2008 15:18:31 -0800 (PST) >>>> >>>> • clicking on the file name should not switch buffer. >>> >>> That's not the file name, that's the buffer name. >> >> please get the over all picture, not bone picking. >> >>> As for what it should do, I don't see why your preference is better >>> than the current one. Popping a menu requires another click to >>> actually select a buffer, whereas the current behavior does it in one >>> click. >> >> typically, a user has several user buffers open, and as far as i guess >> many programers who use emacs extensively has like hundreds of buffers >> open. Cycling them one by one is not much useful. >> >> Counting emacs's own buffers, those info, messages, scratch, >> completions, grep output, shell output, C-h f and friends output, >> dictionary lookup output, ispell output, man page output ... etc... >> these are typically looked once and not useful afterwards. Switching >> and cycling thru them are not much useful. > I basically agree with this stuff. I doubt many hardcore Emacs users > choose to switch buffers this way, which requires using the mouse. And > the part of the behavior that is least useful is that the switch is > blind - you don't know what buffer you're going to get unless you know > the current state of the buffer-list. > > My objection is to the idea that you don't want star buffers in the > list. These are also used for interaction with external processes: > *ssh: host*, *SQL: foo*, *Twit-recent*, *compilation*, *shell*, > *Python*. It seems ill advised to exclude those from the list. The kind of user that might want to see them is clued in enough to use a prefix or customise their setup accordingly. I must say I agree with Xah and the "well thats the way its always been" kind of reply is not constructive in the slightest. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-16 18:20 ` Richard Riley @ 2008-11-16 23:12 ` Ian Eure 2008-11-17 8:37 ` Paul R [not found] ` <mailman.543.1226877138.26697.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 39+ messages in thread From: Ian Eure @ 2008-11-16 23:12 UTC (permalink / raw) To: help-gnu-emacs On Nov 16, 2008, at 10:20 AM, Richard Riley wrote: > Ian Eure <ian@digg.com> writes: >> >> My objection is to the idea that you don't want star buffers in the >> list. These are also used for interaction with external processes: >> *ssh: host*, *SQL: foo*, *Twit-recent*, *compilation*, *shell*, >> *Python*. It seems ill advised to exclude those from the list. > > The kind of user that might want to see them is clued in enough to > use a > prefix or customise their setup accordingly. > That's not the point. A behavior is being suggested which has a serious usability negative. Your argument cuts both ways; anyone who might use the existing mechanism surely is clued in enough to know how to use it, so why bother changing it, either? Consider: 1. Edit stuff. 2. Create a *shell* buffer, do work in the shell. 3. Switch back to editing. 4. Try to go back to the shell - but wait, it's gone! What happened? It's equally confusing. If you want to improve things, great, but replacing one crappy behavior with a different crappy behavior is a waste. > I must say I agree with Xah and the "well thats the way its always > been" > kind of reply is not constructive in the slightest. > Did you actually read my reply? Because I criticized the proposal on it's merits, and never said anything remotely like that. - Ian. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-16 23:12 ` Ian Eure @ 2008-11-17 8:37 ` Paul R 2008-11-17 15:45 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Paul R @ 2008-11-17 8:37 UTC (permalink / raw) To: Ian Eure; +Cc: help-gnu-emacs Ian> It's equally confusing. If you want to improve things, great, but Ian> replacing one crappy behavior with a different crappy behavior is Ian> a waste. Yes, that's right, but still, current behaviour is clearly confusing and suboptimal. Maybe buffers lack a :user or a :system flag that would be set automatically or by the producer, independently of setting the name to something matching the regexp \*.*\*. I think this is what Xah meant and I agree with this point. The effort could be joined with the one mentionned on emacs devel few months ago to give emacs enought facilities to propose "workspaces". In a workspace, the layout of the window is preserved and the list of proposed buffers for switching is restricted only to those relevants to the work being done in the workspace. We can imagine the compilation workspace, the jabber workspace, the mail workspace, the system monitoring workspace and so on. Finally, I also think that not turning on something like ido or iswitchb by default is a terrible default usability choice, and I hope it is still time for core developpers to think about it again. -- Paul ^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: emacs mode line suggestions 2008-11-17 8:37 ` Paul R @ 2008-11-17 15:45 ` Drew Adams [not found] ` <mailman.604.1226937124.26697.help-gnu-emacs@gnu.org> 2008-11-17 23:37 ` Alan Mackenzie 2 siblings, 0 replies; 39+ messages in thread From: Drew Adams @ 2008-11-17 15:45 UTC (permalink / raw) To: 'Paul R', 'Ian Eure'; +Cc: help-gnu-emacs > current behaviour is clearly confusing and suboptimal. > Maybe buffers lack a :user or a :system flag that would be set > automatically or by the producer,... > > The effort could be joined with the one mentionned on emacs devel few > months ago to give emacs enought facilities to propose "workspaces".... > > We can imagine... > > ... is a terrible default usability choice C'mon guys. This is help-gnu-emacs. It's for getting help about using Emacs. There is a mailing list for discussions of the suitability of the existing Emacs behavior and possible improvements: emacs-devel@gnu.org. Discussing such things (Emacs could, would, should) here is generally OT (IIUC). A help topic could of course evolve toward discussion of possible Emacs changes. When that happens, you can always divert it to emacs-devel, letting everyone here know. AFAICT, this thread did not evolve into such a discussion; it started out that way. It's time to move it where it belongs, I think. I don't mean to single out Paul's latest message or even just this thread. The text quoted above from Paul's message serves only as an illustration of the kind of thing that is now being discussed here. Let's help users by not diluting the help Q&A here. Please bring your suggestions for changing Emacs to emacs-devel, where they are appropriate. From http://lists.gnu.org/mailman/listinfo/help-gnu-emacs: This list is the place for users and installers of GNU Emacs to ask for help. Please send bug reports to bug-gnu-emacs instead of posting them here. Since help-gnu-emacs is a very large list, send it only those items that are seriously important to many people. ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.604.1226937124.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.604.1226937124.26697.help-gnu-emacs@gnu.org> @ 2008-11-17 16:11 ` Richard Riley 2008-11-17 18:53 ` Drew Adams 0 siblings, 1 reply; 39+ messages in thread From: Richard Riley @ 2008-11-17 16:11 UTC (permalink / raw) To: help-gnu-emacs "Drew Adams" <drew.adams@oracle.com> writes: >> current behaviour is clearly confusing and suboptimal. >> Maybe buffers lack a :user or a :system flag that would be set >> automatically or by the producer,... >> >> The effort could be joined with the one mentionned on emacs devel few >> months ago to give emacs enought facilities to propose "workspaces".... >> >> We can imagine... >> >> ... is a terrible default usability choice > > C'mon guys. This is help-gnu-emacs. It's for getting help about using > Emacs. But it should not be too disturbing to gauge Emacs user's views on certain issues. The nature of a Help group often means there are more new users and new users are often a catalyst for new and good ideas. Any half decent news reader features thread kill and keeping most in one or two threads is not disrupting. In addition discussion threads on functionality are often educational - many such threads have taught me new things about how and why things are in Emacs. ^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: emacs mode line suggestions 2008-11-17 16:11 ` Richard Riley @ 2008-11-17 18:53 ` Drew Adams 2008-11-17 19:10 ` Richard Riley 0 siblings, 1 reply; 39+ messages in thread From: Drew Adams @ 2008-11-17 18:53 UTC (permalink / raw) To: 'Richard Riley', help-gnu-emacs > > This is help-gnu-emacs. It's for getting help about using Emacs. > > But it should not be too disturbing to gauge Emacs user's views on > certain issues. The nature of a Help group often means there are more > new users and new users are often a catalyst for new and good > ideas. Any half decent news reader features thread kill and keeping > most in one or two threads is not disrupting. In addition discussion > threads on functionality are often educational - many such threads > have taught me new things about how and why things are in Emacs. You can do as you like, of course; I'm not moderating this mailing list. I'm really just trying to help. The point is that such discussions are part of the _purpose_ of emacs-devel, and help-gnu-emacs has a different purpose. If you want to influence Emacs developers to make changes, emacs-devel is the place. To get changes made, there will ultimately need to be a discussion at emacs-devel anyway - might as well put it there to begin with. Can discussion of possible Emacs improvements be educational and helpful for users, new and old? Yes, of course. Absolutely. Users who are interested in reading or participating in such discussions can subscribe to emacs-devel. Personally, I encourage that. In the world of Emacs _in particular_, there is no clear separation between user and designer or implementor. Any and all users - new and old - who are interested in such discussion: Please subscribe to emacs-devel, whether you just want to lurk or you want to contribute. That will help improve both emacs-devel and Emacs. People, myself included, sometimes complain that emacs-devel is not open enough or is too set in its ways. The remedy for that is for more people to participate. Like it or not, there is no substitute for arguing your case at emacs-devel for a particular change you want. If you think Emacs needs fresh ideas and you have some, bring them to emacs-devel, by all means. Be prepared to support them with clear, logical argument, of course. And patience is advised: "You can't always get what you want, but if you try sometimes well you just might find you get what you need." FWIW, I have contributed countless suggestions to emacs-devel for improving (IMO) Emacs. Relatively few have been incorporated. But emacs-devel is still the most effective place to discuss such things, IMO, not help-gnu-emacs. There is no guarantee that your suggestions will be followed at emacs-devel - the contrary is more likely. But they will be read and seriously considered. Another, indirect way to influence Emacs development is to implement the changes you propose and make them available somewhere in a library. That ultimately can affect Emacs development by being food for thought or through direct inclusion someday. The developers who build and distribute Emacs can sometimes be persuaded by sound argument if the idea is a good one, but working code that _shows_ them what you want can be even more persuasive. Even if your third-party code never changes the Emacs distribution, it can help other users, and they will give you valuable feedback to further your own ideas of improvement. There are many good libraries out there that have never been added to the Emacs distribution and probably never will be. Yet they indirectly affect the evolution of Emacs. This is because the real designers and developers of Emacs are a much wider group than those who modify and distribute the Emacs source code. All user feedback and bug reports are part of Emacs development, as are third-party Emacs libraries. This is of course true generally, but it is all the more true for Emacs, where many (most?) users create their own Emacs through customization, coding, and reuse of third-party code. Emacs's users are its developers. If you are interested in how Emacs evolves, please join the discussion at emacs-devel. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 18:53 ` Drew Adams @ 2008-11-17 19:10 ` Richard Riley 2008-11-17 19:57 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Richard Riley @ 2008-11-17 19:10 UTC (permalink / raw) To: Drew Adams; +Cc: 'Richard Riley', help-gnu-emacs "Drew Adams" <drew.adams@oracle.com> writes: >> > This is help-gnu-emacs. It's for getting help about using Emacs. >> >> But it should not be too disturbing to gauge Emacs user's views on >> certain issues. The nature of a Help group often means there are more >> new users and new users are often a catalyst for new and good >> ideas. Any half decent news reader features thread kill and keeping >> most in one or two threads is not disrupting. In addition discussion >> threads on functionality are often educational - many such threads >> have taught me new things about how and why things are in Emacs. > > You can do as you like, of course; I'm not moderating this mailing list. I'm > really just trying to help. > > The point is that such discussions are part of the _purpose_ of emacs-devel, and > help-gnu-emacs has a different purpose. If you want to influence Emacs > developers to make changes, emacs-devel is the place. To get changes made, there > will ultimately need to be a discussion at emacs-devel anyway - might as well > put it there to begin with. You seem to miss the point slightly. Many beginners do not, for obvious reasons, frequent emacs development. And it is beginners I was referring to. > > Can discussion of possible Emacs improvements be educational and helpful for > users, new and old? Yes, of course. Absolutely. Users who are interested in > reading or participating in such discussions can subscribe to emacs-devel. > Personally, I encourage that. In the world of Emacs _in particular_, there is no > clear separation between user and designer or implementor. Nearly all users tend to develop their own add ons and/or customisations. Looks at the far reaching Icicles for a good example :-; It would be a pretty poor sample if the the only new users you could discuss things with were the ones willing and able to subscribe to emacs development. Few users do. And having read some of the sniping there one can readily see why :-; > > Any and all users - new and old - who are interested in such discussion: Please > subscribe to emacs-devel, whether you just want to lurk or you want to > contribute. That will help improve both emacs-devel and Emacs. People, myself > included, sometimes complain that emacs-devel is not open enough or is too set > in its ways. The remedy for that is for more people to participate. If you want to discuss hard core stuff then yes I would concur. But gauging NEW users feeling about certain emacs defaults can hardly be done if there are no new users there. And you are an optimist if you feel that new users will be subscribing to emacs development where it can be slightly frightening for the non clued in new user IMO. While I realise you are not policing per se, I find it hard to agree with you that a discussion about some emacs basics here is a bad thing since the kind of people whose input would be most valuable are indeed here. Consider the "help" part of the group name as including helping people understand why certain things are as they are or even "help"ing someone come to a design suggestion on how to improve it. ^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: emacs mode line suggestions 2008-11-17 19:10 ` Richard Riley @ 2008-11-17 19:57 ` Drew Adams 2008-11-17 20:53 ` Eli Zaretskii [not found] ` <mailman.621.1226951870.26697.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 39+ messages in thread From: Drew Adams @ 2008-11-17 19:57 UTC (permalink / raw) To: 'Richard Riley'; +Cc: 'Richard Riley', help-gnu-emacs > You seem to miss the point slightly. Many beginners do not, > for obvious reasons, frequent emacs development. And it is beginners I > was referring to. I did not miss your point. Perhaps you missed mine. New users should be encouraged to join emacs-devel if they are interested in how Emacs might be improved. That is where they can give their views about it and hear from others about it. That list was created precisely for that, among other things. This, on the other hand, is primarily a list for help questions. > Nearly all users tend to develop their own add ons and/or > customisations. Looks at the far reaching Icicles for a good > example :-; Yes, and so? I said the same thing. > It would be a pretty poor sample if the the only new users you could > discuss things with were the ones willing and able to subscribe to emacs > development. No, emacs-devel was created as the place for such discussion. The Emacs wiki is another such place. IMO, such discussion is not best on help-gnu-emacs, for new users or old. > Few users do. That doesn't mean that that's not the appropriate place for such discussion. And it doesn't make this list appropriate for it. > And having read some of the sniping there one can readily see why :-; I fully understand that, believe me. I have the scars to prove it. ;-) Again, I'm afraid there is no getting around discussion at emacs-devel, if you really want the discussion to change Emacs development. emacs-devel is like sausage making and politics. If you want to clean it up, you have to enter the room and get your hands in the mess. > > Any and all users - new and old - who are interested in > > such discussion: Please subscribe to emacs-devel, whether you just > > want to lurk or you want to contribute. That will help improve both > > emacs-devel and Emacs. People, myself included, sometimes complain > > that emacs-devel is not open enough or is too set in its ways. > > The remedy for that is for more people to participate. > > If you want to discuss hard core stuff then yes I would concur. emacs-devel is not only for hard-core stuff. It is supposedly for all discussion affecting Emacs development. If the currently discussed topics are too hard-core, then bring some soft-core ones to the party. Nothing prevents you from doing that. The point is that discussion of Emacs development is a primary purpose of emacs-devel. It is not a primary purpose of help-gnu-emacs, AFAIK. > But gauging NEW users feeling about certain emacs defaults can hardly be > done if there are no new users there. So the remedy is to encourage new users to join emacs-devel. Bring the discussion (this one, for example) there. > And you are an optimist if you feel that new users will be > subscribing to emacs development where it can be slightly > frightening for the non clued in new user IMO. There's no alternative. IMO. And not encouraging them to do so only reinforces the situation that you decry of emacs-devel not being hospitable to new users. That's like abandoning politics to the "grey-suited grafters". You are living in fantasy land if you think that development or design discussion on only help-gnu-emacs is likely to affect Emacs development or design much. Sooner or later, a decision will be made only after a discussion of the matter at emacs-devel. Might as well bring up the matter there earlier, rather than later. > While I realise you are not policing per se, I find it hard to agree > with you that a discussion about some emacs basics here is a bad thing > since the kind of people whose input would be most valuable are indeed > here. Consider the "help" part of the group name as including helping > people understand why certain things are as they are or even "help"ing > someone come to a design suggestion on how to improve it. It's not a bad thing (except if it begins to distract from the ability to get and give help here, which is the list's purpose). It's not a bad thing to discuss Emacs development anywhere, including the local cafe. The point is that it is less effective, if your goal is to change Emacs. And yes, in some cases it can get in the way of the Q&A messages here, which are on topic. Everyone's input is valuable, new users and old. Neither is "most valuable". That new users gravitate to a help list is undeniable. They come here for help. That is not a reason to divert the list to off-topic discussion. It is on topic to poll users here, and Emacs developers do that from time to time to reach a wider sample than emacs-devel. I don't think it is particularly on topic, however, to delve into design or development discussions here. But hey, you're free to do so. I offered my two cents already; feel free to ignore it. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 19:10 ` Richard Riley 2008-11-17 19:57 ` Drew Adams @ 2008-11-17 20:53 ` Eli Zaretskii [not found] ` <mailman.621.1226951870.26697.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2008-11-17 20:53 UTC (permalink / raw) To: help-gnu-emacs > Date: Mon, 17 Nov 2008 20:10:23 +0100 > From: Richard Riley <rileyrgdev@googlemail.com> > Cc: 'Richard Riley' <rileyrgdev@gmail.com>, help-gnu-emacs@gnu.org > > "Drew Adams" <drew.adams@oracle.com> writes: > > You seem to miss the point slightly. Many beginners do not, for obvious > reasons, frequent emacs development. And it is beginners I was referring > to. For those, there's bug-gnu-emacs@gnu.org. All active developers read it, and recently it was connected to the Emacs bug tracker, so such reports are not lost in time. > And you are an optimist if you feel that new users will be > subscribing to emacs development There's no need to subscribe, if you are willing to suffer a few hours of delay due to moderation. > where it can be slightly frightening for the non clued in new user > IMO. ??? emacs-devel is far from being a frightening place. If you dwell on many forums, you will know what I mean. ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.621.1226951870.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.621.1226951870.26697.help-gnu-emacs@gnu.org> @ 2008-11-17 21:42 ` Richard Riley 2008-11-18 0:55 ` Drew Adams [not found] ` <mailman.641.1226969742.26697.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 39+ messages in thread From: Richard Riley @ 2008-11-17 21:42 UTC (permalink / raw) To: help-gnu-emacs "Drew Adams" <drew.adams@oracle.com> writes: >> You seem to miss the point slightly. Many beginners do not, >> for obvious reasons, frequent emacs development. And it is beginners I >> was referring to. > > I did not miss your point. Perhaps you missed mine. New users should be > encouraged to join emacs-devel if they are interested in how Emacs might be > improved. That is where they can give their views about it and hear from others > about it. That list was created precisely for that, among other > things. I think we are missing each others since I strongly disagree with your point. I do not think emacs-devel is the place for newbies to ask such questions. Here is. > This, on the other hand, is primarily a list for help questions. I think having the reasons behind certain "well thats the way it is" features of emacs explained is help. > >> Nearly all users tend to develop their own add ons and/or >> customisations. Looks at the far reaching Icicles for a good >> example :-; > > Yes, and so? > I said the same thing. > >> It would be a pretty poor sample if the the only new users you could >> discuss things with were the ones willing and able to subscribe to emacs >> development. > > No, emacs-devel was created as the place for such discussion. The Emacs wiki is > another such place. IMO, such discussion is not best on help-gnu-emacs, for new > users or old. The emacs wiki is not a good place for such discussions unless there is somewhere there I have missed. This group is a thread based group/list which enables one to easily censor/filter material one finds immaterial to ones needs. > >> Few users do. > > That doesn't mean that that's not the appropriate place for such discussion. And > it doesn't make this list appropriate for it. I think it is appropriate. I have explained why. Note I am not saying this is the "the discussion" group - just that the odd thread gleaning new users opinions when linked to a certain feature of emacs seems totally in the realms of "help". Maybe I am too liberal. > >> And having read some of the sniping there one can readily see why :-; > > I fully understand that, believe me. I have the scars to prove it. ;-) heh :-) But I know you do since I have read those threads ... > > Again, I'm afraid there is no getting around discussion at emacs-devel, if you > really want the discussion to change Emacs development. emacs-devel is like > sausage making and politics. If you want to clean it up, you have to enter the > room and get your hands in the mess. No doubt and I am not suggesting one should not. I am merely offering my opinion that this is a good group for certain threads discussing certain feature which seem somewhat silly to most noobs and some older hands too. ** I am not ** in any way suggesting this group as a replacement for serious pros and cons of the majority of emacs features or hard core design issues. Lets face it. A LOT of customisations are done to change the default behaviour of emacs and they are discussed and implemented daily here. Something like the default buffer list contents is hardly hardcore emacs devel material until there would be a consensus to change from those who contribute daily to this wonderfully helpful and resourceful group. The bottom line for me is simply : new users do not and probably will not join emacs development. It is not the end of the world to discuss issues which new users compete with daily here to a point. Nearly all additions and customisations are emacs development of a sort. I think we will probably agree to disagree, but that's life. ^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: emacs mode line suggestions 2008-11-17 21:42 ` Richard Riley @ 2008-11-18 0:55 ` Drew Adams [not found] ` <mailman.641.1226969742.26697.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 39+ messages in thread From: Drew Adams @ 2008-11-18 0:55 UTC (permalink / raw) To: 'Richard Riley', help-gnu-emacs > > I did not miss your point. Perhaps you missed mine. New > > users should be encouraged to join emacs-devel if they are > > interested in how Emacs might be improved. That is where > > they can give their views about it and hear from others > > about it. That list was created precisely for that, among other > > things. > > I think we are missing each others since I strongly disagree with your > point. I do not think emacs-devel is the place for newbies to ask such > questions. Here is. What does "such questions" refer to? I never mentioned any questions at all. I certainly never suggested that newbies should ask questions about how to use Emacs at emacs-devel. When they do so, I send them here. ;-) help-gnu-emacs is a _good_ place to ask questions about Emacs - that's what it's for. I said so explicitly. > > This, on the other hand, is primarily a list for help questions. > > I think having the reasons behind certain "well thats the way it is" > features of emacs explained is help. Yes, it is; no disagreement about that. help-gnu-emacs is a good place to ask about, or to explain, the rationale behind the current design. I never spoke to the contrary. I'm all for such explanations here, even without any questions having solicited them. help-gnu-emacs is not the best place to debate whether the current design is optimal or to discuss alternative designs - IMO. That's a design-change discussion, not a helpful explanation of what is and why it is. The reason it can be helpful to explain the rationale behind the existing behavior is that it helps users learn it. And that's because (and to the extent that) the design is coherent. If the design were essentially incoherent, then it would not be very helpful to explain why it is as it is. Because it is fairly systematic, knowing the rationale can also help you know something about the relations between the parts (e.g. UI components), and that can help you learn to use it. > > No, emacs-devel was created as the place for such > > discussion. The Emacs wiki is another such place. > > IMO, such discussion is not best on help-gnu-emacs, for new > > users or old. > > The emacs wiki is not a good place for such discussions > unless there is somewhere there I have missed. This group is a > thread based group/list which enables one to easily censor/filter > material one finds immaterial to ones needs. 1. I did not argue that Emacs Wiki is better for such discussion than a mailing list. 2. I have seen some very useful discussions on Emacs Wiki, including discussions about Emacs design. 3. There is a mailing list that was created expressly for such design and development discussion. Users who want to hear and be heard by others in such a discussion should think about taking advantage of that mailing list, which is emacs-devel, not help-gnu-emacs. > >> Few users do. > > > > That doesn't mean that that's not the appropriate place for > > such discussion. And it doesn't make this list appropriate for it. > > I think it is appropriate. I have explained why. You have also given statements such as "Few users do" use emacs-devel as a _reason why_ help-gnu-emacs is a good place for such discussion. I'm saying that that does not follow logically. > Note I am not saying this is the "the discussion" group - just that > the odd thread gleaning new users opinions when linked to a certain > feature of emacs seems totally in the realms of "help". Maybe I am too liberal. > > >> And having read some of the sniping there one can readily > >> see why :-; > > > > I fully understand that, believe me. I have the scars to > > prove it. ;-) > > heh :-) But I know you do since I have read those threads ... If one wants one's suggestions for change to be taken seriously by the Emacs developers, and thus potentially alter Emacs (the distribution), then there is no escaping emacs-devel. That's the hard-fact bottom line. It might be a tough slog, especially for someone who might not be used to design or development discussions (I do not mean anyone in particular), but that's the burden to take up, I'm afraid. This is no different from most development in that regard. One must be willing to support one's suggestions with good arguments and willing to confront questioning and disagreement. All progress is through contradiction, spake Dr Hegel. All. Of course, contradiction can take many forms, and it need not always be bloody. ;-) emacs-devel could sometimes stand to be a little more civilized, no doubt about it. But there must be logical debate and questioning (devil's advocate and otherwise), if progress is to be robust. Emacs is a good, solid product, with years of users pounding on it. There is always room for improvement, but proposals for improvement need to defend themselves. Hand-waving just doesn't cut the mustard. emacs-devel is sometimes tough, but the main toughness is, I think, to learn to separate one's ego from the logic behind one's suggestions. Logical confrontation is _helpful_ to everyone; personal attacks are only harmful. But we are all bundles of logic and emotions; it's sometimes not easy to keep arguments from becoming personal. Hey, what can I say? I can't defend emacs-devel in so far as it is a contact sport, but I can defend the need to confront, defend, and sometimes rough up _ideas_. If an idea can't stand close scrutiny and defend itself then avoiding such confrontation doesn't make it any stronger. > > Again, I'm afraid there is no getting around discussion at > > emacs-devel, if you really want the discussion to change Emacs > > development. emacs-devel is like sausage making and politics. > > If you want to clean it up, you have to enter the > > room and get your hands in the mess. > > No doubt and I am not suggesting one should not. I am merely > offering my opinion that this is a good group for certain threads > discussing certain feature which seem somewhat silly to most noobs > and some older hands too. > > ** I am not ** in any way suggesting this group as a replacement for > serious pros and cons of the majority of emacs features or hard core > design issues. Perhaps our disagreement is less than it seems. My point is that discussions such as this thread can possibly influence Emacs development if they are taken to emacs-devel. If that is not the intent, to change Emacs, then I'm not sure what the point is. A discussion here of such a thread seems of little value. And it could be productive if carried out on at emacs-devel. I'd rather not see that opportunity missed, whether I like the particular idea or not. Bringing such an idea to emacs-devel gives it a hearing that might lead to something. If I wanted to make a suggestion that the Emacs design be changed regarding the mode line, I would do so at emacs-devel. That is the only place where such a suggestion will have a chance of changing Emacs (other than in a distant, indirect, and butterfly-contingent way). Nothing prevents anyone from discussing the matter here, but don't expect much change that way. That's all. > Lets face it. A LOT of customisations are done to change the default > behaviour of emacs and they are discussed and implemented daily > here. Something like the default buffer list contents is hardly hardcore > emacs devel material until there would be a consensus to change from > those who contribute daily to this wonderfully helpful and resourceful > group. I don't see emacs-devel as only for "hard-core" changes. I suggest lightweight changes there all the time. I wouldn't think of making design-change suggestions, whether heavyweight or lightweight, on help-gnu-emacs. How would that change Emacs? > The bottom line for me is simply : new users do not and probably will > not join emacs development. Newbies certainly won't propose lightweight suggestions at emacs-devel if you keep telling them it is only for Emacs gurus and hard-core ideas. If you make it out to be a super serious, brutally scary place, then yes, people will hesitate to propose something there that they think might be taken as silly. Personally, I don't give a damn whether someone thinks my suggestions are silly, no matter how authoritative that person might be. Hey, we Americans are just big kids with no respect for nothin - whaddya gonna do? I learned long ago that there are no stupid questions and, as long as an honest and respectful effort is made to communicate and understand, there is no reason not to say what I think. More importantly, I learned that ideas progress by being confronted and argued - the stronger the counter arguments, the greater the progress. If I think I have a good idea and I have reasons behind it, then I propose it at emacs-devel. That mailing list is not some sacred temple, to be entered only by anointed heavyweights. It's not helpful, IMO, for you to paint it as such. Newbies have come to emacs-devel, survived, and gotten their suggestions implemented - it happens. But yes, there is some road-kill - that happens too. Far from scaring them away, precisely because it can be a bit scary to propose something for the first time to old-timers like RMS, newbies should be encouraged to lurk and participate at emacs-devel. Help them dare, don't scare them away. It's scary enough, but only a tiny few who do dare are ever eaten alive. The minotaur at the center of the labyrinth is mostly a paper tiger. > It is not the end of the world to discuss > issues which new users compete with daily here to a point. Nearly all > additions and customisations are emacs development of a sort. > > I think we will probably agree to disagree, but that's life. So it is. ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.641.1226969742.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.641.1226969742.26697.help-gnu-emacs@gnu.org> @ 2008-11-18 1:08 ` Richard Riley 2008-11-18 2:55 ` Drew Adams 0 siblings, 1 reply; 39+ messages in thread From: Richard Riley @ 2008-11-18 1:08 UTC (permalink / raw) To: help-gnu-emacs "Drew Adams" <drew.adams@oracle.com> writes: >> > I did not miss your point. Perhaps you missed mine. New >> > users should be encouraged to join emacs-devel if they are >> > interested in how Emacs might be improved. That is where >> > they can give their views about it and hear from others >> > about it. That list was created precisely for that, among other >> > things. >> >> I think we are missing each others since I strongly disagree with your >> point. I do not think emacs-devel is the place for newbies to ask such >> questions. Here is. > > What does "such questions" refer to? I never mentioned any questions at all. I > certainly never suggested that newbies should ask questions about how to use > Emacs at emacs-devel. When they do so, I send them here. ;-) > > help-gnu-emacs is a _good_ place to ask questions about Emacs - that's what it's > for. I said so explicitly. Sorry to snip so aggressively but the bottom line really is "this is how it is" not "how it maybe should be if all groups were used properly". The development list/group does not feature lots of new users whose input IS important when discussing such issues. The help group does feature these users. These new users do not and generally will not subscribe to the development list since they do not realise they are in fact contributing to "development" when expressing their confusion about certain emacs idiosyncrasies. Should new development be discussed in the devel group? Of course. Does that preclude certain things being discussed in the context of help threads here in the help group? Certainly not. ^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: emacs mode line suggestions 2008-11-18 1:08 ` Richard Riley @ 2008-11-18 2:55 ` Drew Adams 0 siblings, 0 replies; 39+ messages in thread From: Drew Adams @ 2008-11-18 2:55 UTC (permalink / raw) To: 'Richard Riley', help-gnu-emacs > the bottom line really is "this is how it is" not "how it maybe > should be if all groups were used properly". The development > list/group does not feature lots of new users whose input IS > important when discussing such issues. It's not about proper use. It's about being effective to get what you want. To change Emacs (the release), one needs to deal with <shudder> emacs-devel, like it or not. That's the "this-is-how-it-is" reality. > The help group does feature these users. These new users do not and > generally will not subscribe to the development list since they do > not realise they are in fact contributing to "development" when > expressing their confusion about certain emacs idiosyncrasies. Too bad, for everyone. But _you_ realize they are in fact contributing to development, so why don't you suggest moving such a thread to where you now apparently agree it belongs? Especially if that's the only thing keeping them away ("_since_ they do not realize"). You seem to be arguing that since those other, new guys don't know any better, don't know that such a discussion is in fact about Emacs development and logically belongs in emacs-devel, the discussion should just be carried on here instead. I'm arguing that if they don't know any better then we should help by guiding them to the fertile ground, the place where the discussion is most likely to bear fruit. > Should new development be discussed in the devel group? Of course. Then what's the argument? That's just what I'm saying. Let's encourage that to happen, since you agree. > Does that preclude certain things being discussed in the > context of help threads here in the help group? Certainly not. Preclude? No. But will a discussion only here change Emacs? Not likely. Is your aim to convince new users that you have a great idea or to change Emacs to reflect your great idea? That's the question. Please think about it. My point is not that you must not post such discussions here. It is that there is not much point in doing so - _if_ your intention is to change Emacs. "Philosophers have only interpreted the world, in various ways. The point, however, is to change it." ;-) I've qualified by adding that conditional, "if", several times now, with no correction from you. And I've asked, if that is not the intention, then what is? Again no response. I conclude that that is in fact the intention of having such a discussion here: to change Emacs. I think, in that case, that it is misguided. Those who will ultimately change Emacs in the ways you want (or not) are in emacs-devel. "This is how it is." To fulfill your goal, you will need to take your case to them sooner or later. Bring as many newbies as you like - that can only help the discussion, not hurt it, but bring the discussion to the place where the Emacs release is actually changed. That ain't here, any way you look at it. My aim is to help you bring such discussion in contact with the Emacs developers and deciders - not to exclude it from here. If you want people here to be aware of it, then a link here, even a periodic link, to a discussion at emacs-devel could be appropriate. I want to encourage you to add the discussion to emacs-devel; that's all. I really don't care much whether it is also here, but I respect that you do. It's not good to simply copy both lists, of course, but an occasional informative link here could help newcomers tune in. The question I think is, do you really want to change Emacs or not? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 8:37 ` Paul R 2008-11-17 15:45 ` Drew Adams [not found] ` <mailman.604.1226937124.26697.help-gnu-emacs@gnu.org> @ 2008-11-17 23:37 ` Alan Mackenzie 2008-11-18 7:52 ` Paul R 2 siblings, 1 reply; 39+ messages in thread From: Alan Mackenzie @ 2008-11-17 23:37 UTC (permalink / raw) To: Paul R; +Cc: help-gnu-emacs Hi, Paul! On Mon, Nov 17, 2008 at 09:37:49AM +0100, Paul R wrote: > Finally, I also think that not turning on something like ido or > iswitchb by default is a terrible default usability choice, and I hope > it is still time for core developpers to think about it again. There's a good reason. Emacs's philosophy is not to get in your way. Having to disable "helpful" features to get a comfortable working system is far, far worse than having to enable them. (Think of having to turn of Microsoft's "helpful" dancing paper clip, or their habit of insisting the first word of a sentence must be capitalised. AAARGGHHH!!!) There are lots of ways of switching buffers, none objectively the best. You've assumed the axiom of choice in your paragraph above; namely that there is some way of choosing a "best" way for each of the uncountably infinite options in Emacs. You give yourself away with the words "something like". ;-) > Paul -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 23:37 ` Alan Mackenzie @ 2008-11-18 7:52 ` Paul R 2008-11-18 13:48 ` Alan Mackenzie 0 siblings, 1 reply; 39+ messages in thread From: Paul R @ 2008-11-18 7:52 UTC (permalink / raw) To: Alan Mackenzie; +Cc: help-gnu-emacs Hello Alan, Alan> There are lots of ways of switching buffers, none objectively the Alan> best. You've assumed the axiom of choice in your paragraph above; Alan> namely that there is some way of choosing a "best" way for each of Alan> the uncountably infinite options in Emacs. You give yourself away Alan> with the words "something like". ;-) I used this words because any of them would do better than the current behaviour. This of course reflect mainly my opinion, but because I have some experience at teaching emacs to beginners, I can tell you it is a general feeling among them. Of course, you can argue that most student have no critisism and just like what the teacher like. That would be a valid point, but I honnestly have the feeling that it helps them a lot. I just noticed again than one can switch buffers from the menu. This is also an intuitive behaviour for beginners, indeed, but I would prefer to give them the right tools to use emacs more easily from the keyboard. Regards, -- Paul ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-18 7:52 ` Paul R @ 2008-11-18 13:48 ` Alan Mackenzie 0 siblings, 0 replies; 39+ messages in thread From: Alan Mackenzie @ 2008-11-18 13:48 UTC (permalink / raw) To: Paul R; +Cc: help-gnu-emacs Hi, Paul On Tue, Nov 18, 2008 at 08:52:14AM +0100, Paul R wrote: > Hello Alan, > Alan> There are lots of ways of switching buffers, none objectively the > Alan> best. You've assumed the axiom of choice in your paragraph above; > Alan> namely that there is some way of choosing a "best" way for each of > Alan> the uncountably infinite options in Emacs. You give yourself away > Alan> with the words "something like". ;-) > I used this words because any of them would do better than the current > behaviour. This of course reflect mainly my opinion, but because I have > some experience at teaching emacs to beginners, I can tell you it is a > general feeling among them. The remedy is in your own hands - set up one of these ways (_YOU_ have to chose it :-) in the .emacsen of the people you teach. But tell them you've done so, so that those it irritates can switch to a more pleasant (for them) way. My own way is to have the buffers I'm currently looking at each in its own frame (more or less), and I use F1, F2, ...., F11 to switch to the corresponding frame. Other than that, C-x b, C-x 5 b, and occasionally C-x 4 b do me just fine. Not everybody would like that, though! > Of course, you can argue that most student have no critisism and just > like what the teacher like. That would be a valid point, but I > honnestly have the feeling that it helps them a lot. If you were to set up some "better" buffer switching scheme, it would give you a good opportunity to emphasise to the beginner(s) that everybody is different (<off-stage>: "I'm not!" ;-) and each user needs to set up her Emacs to be efficient for _her_. > I just noticed again than one can switch buffers from the menu. This is > also an intuitive behaviour for beginners, indeed, but I would prefer > to give them the right tools to use emacs more easily from the > keyboard. C-x b, together with the use of alphanumeric keys, <tab>, <PageUp>, M-n and M-p? That doesn't seem all that awkward to me, certainly compared with the way other bits of software do it. Could it be you haven't sussed out all the flexibility of C-x b, or am I missing something important? > Regards, > Paul -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.543.1226877138.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.543.1226877138.26697.help-gnu-emacs@gnu.org> @ 2008-11-16 23:35 ` Richard Riley 0 siblings, 0 replies; 39+ messages in thread From: Richard Riley @ 2008-11-16 23:35 UTC (permalink / raw) To: help-gnu-emacs Ian Eure <ian@digg.com> writes: > On Nov 16, 2008, at 10:20 AM, Richard Riley wrote: > >> Ian Eure <ian@digg.com> writes: >>> >>> My objection is to the idea that you don't want star buffers in the >>> list. These are also used for interaction with external processes: >>> *ssh: host*, *SQL: foo*, *Twit-recent*, *compilation*, *shell*, >>> *Python*. It seems ill advised to exclude those from the list. >> >> The kind of user that might want to see them is clued in enough to >> use a >> prefix or customise their setup accordingly. >> > That's not the point. A behavior is being suggested which has a > serious usability negative. Your argument cuts both ways; anyone who > might use the existing mechanism surely is clued in enough to know how > to use it, so why bother changing it, either? > > Consider: > > 1. Edit stuff. > 2. Create a *shell* buffer, do work in the shell. > 3. Switch back to editing. > 4. Try to go back to the shell - but wait, it's gone! What happened? > > It's equally confusing. If you want to improve things, great, but > replacing one crappy behavior with a different crappy behavior is a > waste. Not really. The buffer list does get large. I use IDO and that works well enough. But you are arguing how it would be if you keep the shell as it is. Another way might be simply to have a regexp to show which buffers are included - in fact I would be surprised if it wasnt already there:-; I was merely idly agreeing with Xah that the default list of ALL buffers might not be right one. It should be a more advanced one. > > >> I must say I agree with Xah and the "well thats the way its always >> been" >> kind of reply is not constructive in the slightest. >> > Did you actually read my reply? Because I criticized the proposal on > it's merits, and never said anything remotely like that. I was not referring to your reply. I was referring to the thread. Your reply was fair and considered. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions [not found] ` <mailman.518.1226859137.26697.help-gnu-emacs@gnu.org> 2008-11-16 18:20 ` Richard Riley @ 2008-11-16 22:45 ` Xah 1 sibling, 0 replies; 39+ messages in thread From: Xah @ 2008-11-16 22:45 UTC (permalink / raw) To: help-gnu-emacs On Nov 16, 10:12 am, Ian Eure <i...@digg.com> wrote: > > Counting emacs's own buffers, those info, messages, scratch, > > completions, grep output, shell output, C-h f and friends output, > > dictionary lookup output, ispell output, man page output ... etc... > > these are typically looked once and not useful afterwards. Switching > > and cycling thru them are not much useful. > > I basically agree with this stuff. I doubt many hardcore Emacs users > choose to switch buffers this way, which requires using the mouse. And > the part of the behavior that is least useful is that the switch is > blind - you don't know what buffer you're going to get unless you know > the current state of the buffer-list. > > My objection is to the idea that you don't want star buffers in the > list. These are also used for interaction with external processes: > *ssh: host*, *SQL: foo*, *Twit-recent*, *compilation*, *shell*, > *Python*. It seems ill advised to exclude those from the list. what's *Twit-recent*? anyhow, you are right that including them would be good too. > > • Minor mode should not be displayed in mode line. It's confusing. For > > one reason, it by default selectively display only some of the minor > > modes currently on, and the selective process is not something people > > who intuitively understands. For the other reason, Emacs's technical > > concept of Minor mode is somewhat confusing. Most minor modes in > > practice are Preferences settings (Mac-speak) or Options (Windows- > > speak and Linux Desktops) from user point of view. > > Where would you suggest showing this information? Some minor modes > change Emacs' behavior significantly. For example: auto-fill-mode or > abbrev-mode. If these aren't in the mode line, where do you find this > information? perhaps in the Options menu. > >>> • Clicking on the major mode name should pop up a contextual menu to > >>> let user switch to major major modes. > > >> Switching a major mode is a very rare command, so having this at your > >> fingertips makes no sense, IMO. > > > switching between modes is not rarely used. I'd estimate it is used > > every other hour at least. > > Can you describe the use case where you do this? It sounds like you > have a configuration issue, honestly. > > I think the only time I manually switch modes is when I need to use > *scratch* for something, e.g. I'll switch to emacs-lisp-mode if I want > to eval some code, sql-mode if I want to write a query, etc. same here. switching to the right mode is often needed for those who uses *scratch* or creating a new file Ctrl+x Ctrl+f, or new buffer. in almost all modern editors, there are menu to switch to the rigth language mode. Providing a menu probably ease up learning curve for new users. (note that in Aquamacs this is done.) I think it is a frequently requested feature. A new user, who are not yet familiar with emacs M-x command and common mode names, has no way to know how to switch mode or what are available. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.536.1226871605.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.536.1226871605.26697.help-gnu-emacs@gnu.org> @ 2008-11-16 23:17 ` Xah 2008-11-17 20:39 ` Eli Zaretskii [not found] ` <mailman.623.1226954396.26697.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 39+ messages in thread From: Xah @ 2008-11-16 23:17 UTC (permalink / raw) To: help-gnu-emacs On Nov 16, 1:40 pm, Eli Zaretskii <e...@gnu.org> wrote: > Please explain how you deduce that the cursor percentage is shown. > Here's what I see (on MS-Windows, but that's the only GUI Emacs I can > access where I type this): as long as the first and last line shown by > the window don't move, I see the same percentage, no matter how I move > the cursor; but when I scroll the window with "C-u 1 C-v" (which > scrolls by one line without moving buffer position), the percentage > starts changing, even though cursor is on the same place in the > buffer. Ok, i think i know what you are saying. I had some misunderstanding in my previous post. Here's what i would suggest: according to (info "(emacs)Mode Line"), quote: « -CS:CH-FR BUF POS LINE (MAJOR MINOR)------ ... POS tells you whether there is additional text above the top of the window, or below the bottom. If your buffer is small and it is all visible in the window, POS is `All'. Otherwise, it is `Top' if you are looking at the beginning of the buffer, `Bot' if you are looking at the end of the buffer, or `NN%', where NN is the percentage of the buffer above the top of the window. With Size Indication mode, you can display the size of the buffer as well. *Note Optional Mode Line::. » what i am thinking is that code word “All”, “Top”, “Bot”, which are different than NN%, is less intuitive than if it always use the NN% format. i think it's perhaps even better if the percentage is simply the current line number divided by the total num of lines in buffer. > > > As for what it should do, I don't see why your preference is better > > > than the current one. Popping a menu requires another click to > > > actually select a buffer, whereas the current behavior does it in one > > > click. > > > typically, a user has several user buffers open, and as far as i guess > > many programers who use emacs extensively has like hundreds of buffers > > open. Cycling them one by one is not much useful. > > No one in their right mind will cycle buffers. This feature exists if > your buffer is one or two away. Anything more than that, you should > use the menu-bar's Buffers menu (or select the buffer by its name with > C-x b). So, when clicking on the buffer name, showing a menu is more useful than cycling buffer. > > For one reason, it by default selectively display only some of the > > minor modes currently on > > Perhaps because some minor modes decided not to announce themselves. > For example, in the buffer where I type this I have "Fly Abbrev Fill" > as the list of minor modes that I have turned on. Yes, so that's confusing. > > > > • Clicking on the major mode name should pop up a contextual menu to > > > > let user switch to major major modes. > > > > Switching a major mode is a very rare command, so having this at your > > > fingertips makes no sense, IMO. > > > switching between modes is not rarely used. I'd estimate it is used > > every other hour at least. > > Please provide some use-cases to back this up. FWIW, I almost never > switch the major mode in the same buffer, unless Emacs didn't switch > into the right one to begin with, and even then I only do that once in > a given buffer. those who use *scratch*, or create new buffer, or create new file... he may need to switch to the righ lang mode. Sometimes when such buffer is used as a scratch, programer may have more than one lang inserted into it, and may switch to different mode for the right syntax coloring. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-16 23:17 ` Xah @ 2008-11-17 20:39 ` Eli Zaretskii 2008-11-17 23:46 ` Alan Mackenzie [not found] ` <mailman.633.1226964831.26697.help-gnu-emacs@gnu.org> [not found] ` <mailman.623.1226954396.26697.help-gnu-emacs@gnu.org> 1 sibling, 2 replies; 39+ messages in thread From: Eli Zaretskii @ 2008-11-17 20:39 UTC (permalink / raw) To: help-gnu-emacs > From: Xah <xahlee@gmail.com> > Date: Sun, 16 Nov 2008 15:17:44 -0800 (PST) > > > > typically, a user has several user buffers open, and as far as i guess > > > many programers who use emacs extensively has like hundreds of buffers > > > open. Cycling them one by one is not much useful. > > > > No one in their right mind will cycle buffers. This feature exists if > > your buffer is one or two away. Anything more than that, you should > > use the menu-bar's Buffers menu (or select the buffer by its name with > > C-x b). > > So, when clicking on the buffer name, showing a menu is more useful > than cycling buffer. As I already said, I disagree: if I need to switch to a buffer that is just one buffer away in either direction, with the current behavior I get that in one click. With your suggestion, clicking on the buffer name would be the same as Buffers from the menu bar, and this duplication of functionality is a waste of scarce resources, IMO. > > > switching between modes is not rarely used. I'd estimate it is used > > > every other hour at least. > > > > Please provide some use-cases to back this up. FWIW, I almost never > > switch the major mode in the same buffer, unless Emacs didn't switch > > into the right one to begin with, and even then I only do that once in > > a given buffer. > > those who use *scratch*, or create new buffer, or create new file... > he may need to switch to the righ lang mode. Usually, creating a new file with C-x C-f already switches on the right mode. And even if Emacs somehow gets this wrong, it's a one-time event for that buffer. > Sometimes when such buffer is used as a scratch, programer may have > more than one lang inserted into it, and may switch to different > mode for the right syntax coloring. Is this frequent usage? I never use Emacs like that, but that's me. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 20:39 ` Eli Zaretskii @ 2008-11-17 23:46 ` Alan Mackenzie 2008-11-18 0:31 ` Lennart Borgman 2008-11-18 9:32 ` Kevin Rodgers [not found] ` <mailman.633.1226964831.26697.help-gnu-emacs@gnu.org> 1 sibling, 2 replies; 39+ messages in thread From: Alan Mackenzie @ 2008-11-17 23:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs Hi, Eli! On Mon, Nov 17, 2008 at 10:39:57PM +0200, Eli Zaretskii wrote: > > From: Xah <xahlee@gmail.com> > > Date: Sun, 16 Nov 2008 15:17:44 -0800 (PST) > > > > switching between modes is not rarely used. I'd estimate it is > > > > used every other hour at least. Not by me. > > > Please provide some use-cases to back this up. FWIW, I almost > > > never switch the major mode in the same buffer, unless Emacs didn't > > > switch into the right one to begin with, and even then I only do > > > that once in a given buffer. > > those who use *scratch*, or create new buffer, or create new file... > > he may need to switch to the righ lang mode. > Usually, creating a new file with C-x C-f already switches on the right > mode. And even if Emacs somehow gets this wrong, it's a one-time event > for that buffer. However, if I create a new buffer with C-x C-b foo.c, it starts in Fundamental Mode, not C Mode. Is there a good reason for this, or did it just happen? It irritates me quite a bit, but not quite enough to bring me to fixing it. ;-) > > Sometimes when such buffer is used as a scratch, programer may have > > more than one lang inserted into it, and may switch to different mode > > for the right syntax coloring. > Is this frequent usage? I never use Emacs like that, but that's me. "Here documents" inside shell scripts bug me, but I never change modes to get them to fontify and indent right. It would be great to have a solid "multiple mode" working (hi, Lennart!). -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 23:46 ` Alan Mackenzie @ 2008-11-18 0:31 ` Lennart Borgman 2008-11-18 9:32 ` Kevin Rodgers 1 sibling, 0 replies; 39+ messages in thread From: Lennart Borgman @ 2008-11-18 0:31 UTC (permalink / raw) To: Alan Mackenzie; +Cc: help-gnu-emacs On Tue, Nov 18, 2008 at 12:46 AM, Alan Mackenzie <acm@muc.de> wrote: > "Here documents" inside shell scripts bug me, but I never change modes to > get them to fontify and indent right. It would be great to have a solid > "multiple mode" working (hi, Lennart!). Noticed. It is on my big list. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 23:46 ` Alan Mackenzie 2008-11-18 0:31 ` Lennart Borgman @ 2008-11-18 9:32 ` Kevin Rodgers 2008-11-18 9:58 ` Alan Mackenzie 1 sibling, 1 reply; 39+ messages in thread From: Kevin Rodgers @ 2008-11-18 9:32 UTC (permalink / raw) To: help-gnu-emacs Alan Mackenzie wrote: >> Usually, creating a new file with C-x C-f already switches on the right >> mode. And even if Emacs somehow gets this wrong, it's a one-time event >> for that buffer. > > However, if I create a new buffer with C-x C-b foo.c, it starts in > Fundamental Mode, not C Mode. Is there a good reason for this, or did it > just happen? It irritates me quite a bit, but not quite enough to bring > me to fixing it. ;-) I think the reason is that auto-mode-alist applies only to file names. I suppose it is arguable whether that is a good reason or not, but "fixing" it to apply to buffer names would be a pretty far-reaching change. Maybe this would work for you: (defadvice switch-to-buffer (around interactive-normal-mode activate) "When called interactively to create a new buffer not visiting a file, temporarily bind `buffer-file-name' and call `normal-mode'." (let ((existing-buffer (get-buffer (ad-get-arg 0)))) ad-do-it (when (and (interactive-p) (null existing-buffer) (null buffer-file-name)) (let ((buffer-file-name (expand-file-name (buffer-name)))) (normal-mode))))) -- Kevin Rodgers Denver, Colorado, USA ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-18 9:32 ` Kevin Rodgers @ 2008-11-18 9:58 ` Alan Mackenzie 0 siblings, 0 replies; 39+ messages in thread From: Alan Mackenzie @ 2008-11-18 9:58 UTC (permalink / raw) To: Kevin Rodgers; +Cc: help-gnu-emacs Hi, Kevin! On Tue, Nov 18, 2008 at 02:32:00AM -0700, Kevin Rodgers wrote: > Alan Mackenzie wrote: > >>Usually, creating a new file with C-x C-f already switches on the > >>right mode. And even if Emacs somehow gets this wrong, it's a > >>one-time event for that buffer. > >However, if I create a new buffer with C-x C-b foo.c, it starts in > >Fundamental Mode, not C Mode. Is there a good reason for this, or did > >it just happen? It irritates me quite a bit, but not quite enough to > >bring me to fixing it. ;-) > I think the reason is that auto-mode-alist applies only to file names. > I suppose it is arguable whether that is a good reason or not, but > "fixing" it to apply to buffer names would be a pretty far-reaching > change. OK. It's one of these things which is just "so obviously" the only Right Thing. Like other such things, it's regarded differently by other people. > Maybe this would work for you: > (defadvice switch-to-buffer (around interactive-normal-mode activate) > "When called interactively to create a new buffer not visiting a file, > temporarily bind `buffer-file-name' and call `normal-mode'." > (let ((existing-buffer (get-buffer (ad-get-arg 0)))) > ad-do-it > (when (and (interactive-p) > (null existing-buffer) > (null buffer-file-name)) > (let ((buffer-file-name (expand-file-name (buffer-name)))) > (normal-mode))))) Hey, Kevin, you're a true gentleman! Many thanks! > Kevin Rodgers -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.633.1226964831.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.633.1226964831.26697.help-gnu-emacs@gnu.org> @ 2008-11-18 9:46 ` Fabrice Niessen 0 siblings, 0 replies; 39+ messages in thread From: Fabrice Niessen @ 2008-11-18 9:46 UTC (permalink / raw) To: help-gnu-emacs-mXXj517/zsQ Hello, >>> Sometimes when such buffer is used as a scratch, programer >>> may have more than one lang inserted into it, and may switch >>> to different mode for the right syntax coloring. >> >> Is this frequent usage? I never use Emacs like that, but >> that's me. > > "Here documents" inside shell scripts bug me, but I never > change modes to get them to fontify and indent right. It would > be great to have a solid "multiple mode" working (hi, > Lennart!). Wat I personally do, in such cases, and because I don't have any better solution (multiple major modes?) yet, is: o narrow my buffer (`C-x n n') to the code of the "here document", o change the major mode, o update my code, and o widen back my buffer (`C-x n w'). Though, I'd be interested as well by smarter solutions than this one... Best regards, Fabrice _________________________________________________________________________ Fabrice Niessen Search the Web with "My Google Search Tools" on http://www.MyGooglest.com ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <mailman.623.1226954396.26697.help-gnu-emacs@gnu.org>]
* Re: emacs mode line suggestions [not found] ` <mailman.623.1226954396.26697.help-gnu-emacs@gnu.org> @ 2008-11-17 22:09 ` Xah 2008-11-18 2:33 ` B. T. Raven 2008-11-18 4:11 ` Eli Zaretskii 0 siblings, 2 replies; 39+ messages in thread From: Xah @ 2008-11-17 22:09 UTC (permalink / raw) To: help-gnu-emacs On Nov 17, 12:39 pm, Eli Zaretskii <e...@gnu.org> wrote: > > From:Xah<xah...@gmail.com> > > Date: Sun, 16 Nov 2008 15:17:44 -0800 (PST) > > > > > typically, a user has several user buffers open, and as far as i guess > > > > many programers who use emacs extensively has like hundreds of buffers > > > > open. Cycling them one by one is not much useful. > > > > No one in their right mind will cycle buffers. This feature exists if > > > your buffer is one or two away. Anything more than that, you should > > > use the menu-bar's Buffers menu (or select the buffer by its name with > > > C-x b). > > > So, when clicking on the buffer name, showing a menu is more useful > > than cycling buffer. > > As I already said, I disagree: if I need to switch to a buffer that is > just one buffer away in either direction, with the current behavior I > get that in one click. With your suggestion, clicking on the buffer > name would be the same as Buffers from the menu bar, and this > duplication of functionality is a waste of scarce resources, IMO. you mentioned that normally cycling buffer is only useful when there are few buffers. So, the click to cycle behavior on the mode line is of limited use. what i'm saynig in response, is that if now we make the clicking on the mode line behavior to show list of buffers, this would widen the usefulness. after all, there's already a menu and keyboard shortcut for Next/ Previous buffer. So, the current behavior of clicking on the mode line to switch to next/previous buffer, is also, a duplication of functionality as far as duplication of functionalities is concerned. > > > > switching between modes is not rarely used. I'd estimate it is used > > > > every other hour at least. > > > > Please provide some use-cases to back this up. FWIW, I almost never > > > switch the major mode in the same buffer, unless Emacs didn't switch > > > into the right one to begin with, and even then I only do that once in > > > a given buffer. > > > those who use *scratch*, or create new buffer, or create new file... > > he may need to switch to the righ lang mode. > > Usually, creating a new file with C-x C-f already switches on the > right mode. And even if Emacs somehow gets this wrong, it's a > one-time event for that buffer. creating a new file is just one example. Others are using *scratch* or creating a new buffer. As i have already stated clearly in my previous post, in general, when user creates a new buffer for scratch purposes, switching mode is needed. It is not just about C-x C-f. Furthere, C-x C-f gets you the right mode only when you use the right file name suffix. When a user creates a new buffer for scratch purposes, he does not need to name the file with the right suffix. If he does, that's for the purpose of making it into the right mode. And if so, it is necessary only if he doesn't already have a easy or proper way to get the buffer into the right mode. In other words, the file suffix induced mode switching is a side effect. Of course, one may argue that user might just do Alt+x ‹mode name›. But remember the context is for those who are new to emacs, on intuitiveness, with regards to the behavior of clicking on mode line. In summary, i argued that clicking on the major mode section of the mode line's behavior is better if it just list available modes where user can switch. You argued no by saying that it's not often needed to switch mode. I argued it is needed, in several scenarios, summarized as when user needs a scratch buffer. Then you argued that find-file will get you the right mode with right suffix name. I argue now, that this disregards 2 other common methods of using a buffer for scratch purposes, namely, the *scratch* buffer and switch-to-buffer method, and furhter, find-file gets the right mode only when the user names the file with the proper suffix, and further, such is a side effect not a proper method, because for example, the suffix to mode correspondence is not always straightforward and known to vast majority of programers and especially when the language is not one of the top 10 popular ones. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 22:09 ` Xah @ 2008-11-18 2:33 ` B. T. Raven 2008-11-18 3:24 ` Xah 2008-11-18 4:11 ` Eli Zaretskii 1 sibling, 1 reply; 39+ messages in thread From: B. T. Raven @ 2008-11-18 2:33 UTC (permalink / raw) To: help-gnu-emacs Xah wrote: > On Nov 17, 12:39 pm, Eli Zaretskii <e...@gnu.org> wrote: >>> From:Xah<xah...@gmail.com> Date: Sun, 16 Nov 2008 15:17:44 -0800 >>> (PST) >>>>> typically, a user has several user buffers open, and as far >>>>> as i guess many programers who use emacs extensively has like >>>>> hundreds of buffers open. Cycling them one by one is not much >>>>> useful. >>>> No one in their right mind will cycle buffers. This feature >>>> exists if your buffer is one or two away. Anything more than >>>> that, you should use the menu-bar's Buffers menu (or select the >>>> buffer by its name with C-x b). >>> So, when clicking on the buffer name, showing a menu is more >>> useful than cycling buffer. >> As I already said, I disagree: if I need to switch to a buffer that >> is just one buffer away in either direction, with the current >> behavior I get that in one click. With your suggestion, clicking >> on the buffer name would be the same as Buffers from the menu bar, >> and this duplication of functionality is a waste of scarce >> resources, IMO. > > you mentioned that normally cycling buffer is only useful when there > are few buffers. So, the click to cycle behavior on the mode line is > of limited use. > > what i'm saynig in response, is that if now we make the clicking on > the mode line behavior to show list of buffers, this would widen the > usefulness. > > after all, there's already a menu and keyboard shortcut for Next/ > Previous buffer. So, the current behavior of clicking on the mode > line to switch to next/previous buffer, is also, a duplication of > functionality as far as duplication of functionalities is concerned. > >>>>> switching between modes is not rarely used. I'd estimate it >>>>> is used every other hour at least. >>>> Please provide some use-cases to back this up. FWIW, I almost >>>> never switch the major mode in the same buffer, unless Emacs >>>> didn't switch into the right one to begin with, and even then I >>>> only do that once in a given buffer. >>> those who use *scratch*, or create new buffer, or create new >>> file... he may need to switch to the righ lang mode. >> Usually, creating a new file with C-x C-f already switches on the >> right mode. And even if Emacs somehow gets this wrong, it's a >> one-time event for that buffer. > > creating a new file is just one example. Others are using *scratch* > or creating a new buffer. As i have already stated clearly in my > previous post, in general, when user creates a new buffer for scratch > purposes, switching mode is needed. > > It is not just about C-x C-f. Furthere, C-x C-f gets you the right > mode only when you use the right file name suffix. When a user > creates a new buffer for scratch purposes, he does not need to name > the file with the right suffix. If he does, that's for the purpose of > making it into the right mode. And if so, it is necessary only if he > doesn't already have a easy or proper way to get the buffer into the > right mode. In other words, the file suffix induced mode switching is > a side effect. > > Of course, one may argue that user might just do Alt+x ‹mode name›. > But remember the context is for those who are new to emacs, on > intuitiveness, with regards to the behavior of clicking on mode line. > > > In summary, i argued that clicking on the major mode section of the > mode line's behavior is better if it just list available modes where > user can switch. You argued no by saying that it's not often needed > to switch mode. I argued it is needed, in several scenarios, > summarized as when user needs a scratch buffer. Then you argued that > find-file will get you the right mode with right suffix name. I argue > now, that this disregards 2 other common methods of using a buffer > for scratch purposes, namely, the *scratch* buffer and > switch-to-buffer method, and furhter, find-file gets the right mode > only when the user names the file with the proper suffix, and > further, such is a side effect not a proper method, because for > example, the suffix to mode correspondence is not always > straightforward and known to vast majority of programers and > especially when the language is not one of the top 10 popular ones. > > Xah ∑ http://xahlee.org/ > > ☄ But if a user is interested in working with Emacs rather than just playing with it, she will know the suffix that will trigger the correct mode. So if there is a programming language Brainfsck, then it's mode might be switched to by visiting a file named scratch.ppp. If this worked correctly it would work faster than anything you could do with the mouse on the mode line. Fortunately (or maybe not) you are correct that suffix-mode correspondences aren't always intuitive. For instance, I press C-x b and then type in a new (temporary)buffer name like scratch.el * The buffer is created but it is in Text mode (my default) until I do either C-x C-w or M-x emacs-lisp-mode. But if I save it I now have an empty file with that name in my default directory, which I will eventually have to delete. It would be better (imho) if the buffer switched to the mode indicated by the buffer name suffix immediately after creation. But it may be that we are wrong about that since, in the context of the big picture, it may seem hokey to the developers to give a suffix to a temporary buffer name. * Just for the sake of example. Of course there already is a buffer *scratch* set to the correct mode Ed ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-18 2:33 ` B. T. Raven @ 2008-11-18 3:24 ` Xah 2008-11-18 4:58 ` B. T. Raven 0 siblings, 1 reply; 39+ messages in thread From: Xah @ 2008-11-18 3:24 UTC (permalink / raw) To: help-gnu-emacs On Nov 17, 6:33 pm, "B. T. Raven" <ni...@nihilo.net> wrote: > But if a user is interested in working with Emacs rather than just > playing with it, she will know the suffix that will trigger the correct > mode. You missed the point. When a programer work with multiple langs, and when he create a buffer for scratch purposes, there is a need to switch to switch mode. It is not playing with emacs. For example, i program in elisp and perl. So, say, i created a buffer xx for scratch purposes to code some elisp. Then, suddenly my contractor called and needed some code fixed quickly. I immediatly get to work, and i want to switch my xx buffer to perl mode, and start coding perl there. however, i'm emacs newbie, i dunno that the mode switching command. So, i click on the majo mode name in the buffer, get a list, then there i can switch. > So if there is a programming language Brainfsck, then it's mode > might be switched to by visiting a file named scratch.ppp. not quite sure what you mean. I'm guessing what you mean is that the suffix now may not correspond to the mode. Not so, because switching mode is a conscious decision, not something happens automatically. > If this > worked correctly it would work faster than anything you could do with > the mouse on the mode line. remember, the context is ease of use for those who just started to use emacs, and the context is about the the behavior of clicking the mode line. The argument in this subthread, is NOT about switching mode in general. For example, as most emacs users known, you simply switch mode by Alt+x ‹mode name›. So, my argument is that clicking on the major mode in the mode line should pop up a list of commonly used lang's modes. > Fortunately (or maybe not) you are correct that suffix-mode > correspondences aren't always intuitive. For instance, I press C-x b and > then type in a new (temporary)buffer name like scratch.el * The buffer > is created but it is in Text mode (my default) until I do either C-x C-w > or M-x emacs-lisp-mode. But if I save it I now have an empty file with > that name in my default directory, which I will eventually have to > delete. It would be better (imho) if the buffer switched to the mode > indicated by the buffer name suffix immediately after creation. > But it may be that we are wrong about that since, in the context of the > big picture, it may seem hokey to the developers to give a suffix > to a temporary buffer name. > > * Just for the sake of example. Of course there already is a buffer > *scratch* set to the correct mode > > Ed Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-18 3:24 ` Xah @ 2008-11-18 4:58 ` B. T. Raven 2008-11-18 6:54 ` Richard Riley 0 siblings, 1 reply; 39+ messages in thread From: B. T. Raven @ 2008-11-18 4:58 UTC (permalink / raw) To: help-gnu-emacs Xah wrote: > On Nov 17, 6:33 pm, "B. T. Raven" <ni...@nihilo.net> wrote: >> But if a user is interested in working with Emacs rather than just >> playing with it, she will know the suffix that will trigger the >> correct mode. > > You missed the point. When a programer work with multiple langs, and > when he create a buffer for scratch purposes, there is a need to > switch to switch mode. If he creates it then he will have to name it. Let the mode depend on the name. I can see (sort of) why assembler might need to be in a .c buffer but you certainly don't need text blocks from many different languages in the same temp buffer, do you? Why? On the off chance that you really do need all of them then it seems that some new mixed mode should be designed. > > It is not playing with emacs. > > For example, i program in elisp and perl. So, say, i created a buffer > xx for scratch purposes to code some elisp. Then, suddenly my > contractor called and needed some code fixed quickly. I immediatly > get to work, and i want to switch my xx buffer to perl mode, and > start coding perl there. This scenario seems very unworkmanlike to me. If a contractor needs code fixed, then that code is likely to be in a file with a suffix .pl or .perl or whatever. Why not just go to that file and then you would automatically be in the right mode. If you put elisp and perl in the same temp buffer you are going to have to segregate them later anyway, right? Why not do it now by creating a new temp buffer in the right mode? I don't know why you need one but I am not a programmer. > > however, i'm emacs newbie, i dunno that the mode switching command. > So, i click on the majo mode name in the buffer, get a list, then > there i can switch. > >> So if there is a programming language Brainfsck, then it's mode >> might be switched to by visiting a file named scratch.ppp. > > not quite sure what you mean. I'm guessing what you mean is that the > suffix now may not correspond to the mode. Not so, because switching > mode is a conscious decision, not something happens automatically. I was being cute and therefore obscure. Say the extension is .bfk rather than .ppp; it doesn't affect the argument. Anyway, deciding that you want only a temp buffer (in some mode) rather than one associated with a file is also a conscious decision. Most such decisions will be conscious unless they are side effects implicit in some other conscious decision(s). > >> If this worked correctly it would work faster than anything you >> could do with the mouse on the mode line. > > remember, the context is ease of use for those who just started to > use emacs, and the context is about the the behavior of clicking the > mode line. The argument in this subthread, is NOT about switching > mode in general. For example, as most emacs users known, you simply > switch mode by Alt+x ‹mode name›. So you are saying that the mode line should be not only informational but also executive. But that's what the menu is for. I find Eli's arguments more cogent. I suspect that your tastes derive from Redmond based software. De gustibus non est disputandum. Anyway I still would like to go to iswitchb via C-x b and enter a non-existent buffer name like scratch.el.abb and be in Emacs lisp major mode and abbrev minor mode. Of course this buffer name isn't a good name for a file but if you want this temp buffer saved you can do C-x C-w instead of C-x C-s. Maybe it's not a good idea though. We newbies tend to want more freedom than we can handle before the basics are mastered. > > So, my argument is that clicking on the major mode in the mode line > should pop up a list of commonly used lang's modes. > >> Fortunately (or maybe not) you are correct that suffix-mode >> correspondences aren't always intuitive. For instance, I press C-x >> b and then type in a new (temporary)buffer name like scratch.el * >> The buffer is created but it is in Text mode (my default) until I >> do either C-x C-w or M-x emacs-lisp-mode. But if I save it I now >> have an empty file with that name in my default directory, which I >> will eventually have to delete. It would be better (imho) if the >> buffer switched to the mode indicated by the buffer name suffix >> immediately after creation. But it may be that we are wrong about >> that since, in the context of the big picture, it may seem hokey to >> the developers to give a suffix to a temporary buffer name. >> >> * Just for the sake of example. Of course there already is a buffer >> *scratch* set to the correct mode >> >> Ed > > Xah ∑ http://xahlee.org/ > > ☄ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-18 4:58 ` B. T. Raven @ 2008-11-18 6:54 ` Richard Riley 0 siblings, 0 replies; 39+ messages in thread From: Richard Riley @ 2008-11-18 6:54 UTC (permalink / raw) To: help-gnu-emacs "B. T. Raven" <nihil@nihilo.net> writes: > Xah wrote: >> On Nov 17, 6:33 pm, "B. T. Raven" <ni...@nihilo.net> wrote: >>> But if a user is interested in working with Emacs rather than just >>> playing with it, she will know the suffix that will trigger the >>> correct mode. >> >> You missed the point. When a programer work with multiple langs, and >> when he create a buffer for scratch purposes, there is a need to >> switch to switch mode. > > If he creates it then he will have to name it. Let the mode depend on > the name. I can see (sort of) why assembler might need to be in a .c > buffer but you certainly don't need text blocks from many different > languages in the same temp buffer, do you? Why? On the off chance that > you really do need all of them then it seems that some new mixed mode > should be designed. Practically any web page in existence? mixture of xhtml, php, javascript etc. Mind you that web thingy, it will never catch on :-; nxhtml works well for that. I would certainly have used the scratch more if the language mode was a click away - now its second nature to do it using M-x. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: emacs mode line suggestions 2008-11-17 22:09 ` Xah 2008-11-18 2:33 ` B. T. Raven @ 2008-11-18 4:11 ` Eli Zaretskii 1 sibling, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2008-11-18 4:11 UTC (permalink / raw) To: help-gnu-emacs > From: Xah <xahlee@gmail.com> > Date: Mon, 17 Nov 2008 14:09:13 -0800 (PST) > > you mentioned that normally cycling buffer is only useful when there > are few buffers. Not necessarily when there are few buffers. It is also useful when I constantly switch between two or three buffers, even if there are 500 more. That makes them close to one another in the buffer list, so Next Buffer and Previous Buffer make sense. > Of course, one may argue that user might just do Alt+x ‹mode name›. No need to know the name of the mode: "M-x normal-mode RET" will invoke whatever mode is defined to handle the file of that name or with that contents (so you could, e.g., add a "-*- mode: FOO -*-" cookie and get Emacs to turn on that MODE). ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2008-11-18 23:25 UTC | newest] Thread overview: 39+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <mailman.215.1226562978.26697.help-gnu-emacs@gnu.org> 2008-11-14 23:18 ` emacs mode line suggestions Xah 2008-11-15 1:02 ` xahlee 2008-11-15 9:23 ` Eli Zaretskii [not found] ` <mailman.423.1226741023.26697.help-gnu-emacs@gnu.org> 2008-11-16 1:54 ` Xah 2008-11-16 18:12 ` Ian Eure 2008-11-18 9:39 ` Kevin Rodgers 2008-11-18 23:25 ` Xavier Maillard 2008-11-16 21:40 ` Eli Zaretskii [not found] ` <mailman.518.1226859137.26697.help-gnu-emacs@gnu.org> 2008-11-16 18:20 ` Richard Riley 2008-11-16 23:12 ` Ian Eure 2008-11-17 8:37 ` Paul R 2008-11-17 15:45 ` Drew Adams [not found] ` <mailman.604.1226937124.26697.help-gnu-emacs@gnu.org> 2008-11-17 16:11 ` Richard Riley 2008-11-17 18:53 ` Drew Adams 2008-11-17 19:10 ` Richard Riley 2008-11-17 19:57 ` Drew Adams 2008-11-17 20:53 ` Eli Zaretskii [not found] ` <mailman.621.1226951870.26697.help-gnu-emacs@gnu.org> 2008-11-17 21:42 ` Richard Riley 2008-11-18 0:55 ` Drew Adams [not found] ` <mailman.641.1226969742.26697.help-gnu-emacs@gnu.org> 2008-11-18 1:08 ` Richard Riley 2008-11-18 2:55 ` Drew Adams 2008-11-17 23:37 ` Alan Mackenzie 2008-11-18 7:52 ` Paul R 2008-11-18 13:48 ` Alan Mackenzie [not found] ` <mailman.543.1226877138.26697.help-gnu-emacs@gnu.org> 2008-11-16 23:35 ` Richard Riley 2008-11-16 22:45 ` Xah [not found] ` <mailman.536.1226871605.26697.help-gnu-emacs@gnu.org> 2008-11-16 23:17 ` Xah 2008-11-17 20:39 ` Eli Zaretskii 2008-11-17 23:46 ` Alan Mackenzie 2008-11-18 0:31 ` Lennart Borgman 2008-11-18 9:32 ` Kevin Rodgers 2008-11-18 9:58 ` Alan Mackenzie [not found] ` <mailman.633.1226964831.26697.help-gnu-emacs@gnu.org> 2008-11-18 9:46 ` Fabrice Niessen [not found] ` <mailman.623.1226954396.26697.help-gnu-emacs@gnu.org> 2008-11-17 22:09 ` Xah 2008-11-18 2:33 ` B. T. Raven 2008-11-18 3:24 ` Xah 2008-11-18 4:58 ` B. T. Raven 2008-11-18 6:54 ` Richard Riley 2008-11-18 4:11 ` Eli Zaretskii
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.