emacs mode line suggestions

emacs mode line suggestions

[Xah]

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/

☄

Re: emacs mode line suggestions

[xahlee]

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/

☄

Re: emacs mode line suggestions

[Eli Zaretskii]

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

Re: emacs mode line suggestions

[Xah]

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/

☄

Re: emacs mode line suggestions

[Ian Eure]

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

Re: emacs mode line suggestions

[Kevin Rodgers]

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

Re: emacs mode line suggestions

[Xavier Maillard]

   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

Re: emacs mode line suggestions

[Eli Zaretskii]

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

Re: emacs mode line suggestions

[Richard Riley]

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.

Re: emacs mode line suggestions

[Ian Eure]

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.

Re: emacs mode line suggestions

[Paul R]

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

RE: emacs mode line suggestions

[Drew Adams]

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

Re: emacs mode line suggestions

[Richard Riley]

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

RE: emacs mode line suggestions

[Drew Adams]

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

Re: emacs mode line suggestions

[Richard Riley]

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

RE: emacs mode line suggestions

[Drew Adams]

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

Re: emacs mode line suggestions

[Eli Zaretskii]

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

Re: emacs mode line suggestions

[Richard Riley]

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

RE: emacs mode line suggestions

[Drew Adams]

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

Re: emacs mode line suggestions

[Richard Riley]

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

RE: emacs mode line suggestions

[Drew Adams]

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

Re: emacs mode line suggestions

[Alan Mackenzie]

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

Re: emacs mode line suggestions

[Paul R]

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

Re: emacs mode line suggestions

[Alan Mackenzie]

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

Re: emacs mode line suggestions

[Richard Riley]

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.

Re: emacs mode line suggestions

[Xah]

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/

☄

Re: emacs mode line suggestions

[Xah]

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/

☄

Re: emacs mode line suggestions

[Eli Zaretskii]

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

Re: emacs mode line suggestions

[Alan Mackenzie]

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

Re: emacs mode line suggestions

[Lennart Borgman]

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.

Re: emacs mode line suggestions

[Kevin Rodgers]

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

Re: emacs mode line suggestions

[Alan Mackenzie]

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

Re: emacs mode line suggestions

[Fabrice Niessen]

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

Re: emacs mode line suggestions

[Xah]

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/

☄

Re: emacs mode line suggestions

[B. T. Raven]

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

Re: emacs mode line suggestions

[Xah]

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/

☄

Re: emacs mode line suggestions

[B. T. Raven]

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/
> 
> ☄

Re: emacs mode line suggestions

[Richard Riley]

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

Re: emacs mode line suggestions

[Eli Zaretskii]

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