help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs mode line suggestions


From: Xah
Subject: Re: emacs mode line suggestions
Date: Mon, 17 Nov 2008 14:09:13 -0800 (PST)
User-agent: G2/1.0

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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]