all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "B. T. Raven" <nihil@nihilo.net>
To: help-gnu-emacs@gnu.org
Subject: Re: emacs mode line suggestions
Date: Mon, 17 Nov 2008 20:33:15 -0600	[thread overview]
Message-ID: <saOdnbNHisD1tL_UnZ2dnUVZ_hudnZ2d@sysmatrix.net> (raw)
In-Reply-To: <f43ce835-1064-4ce1-9de2-9d59d5456d06@v16g2000prc.googlegroups.com>

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


  reply	other threads:[~2008-11-18  2:33 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.215.1226562978.26697.help-gnu-emacs@gnu.org>
2008-11-14 23:18 ` emacs mode line suggestions Xah
2008-11-15  1:02   ` xahlee
2008-11-15  9:23   ` Eli Zaretskii
     [not found]   ` <mailman.423.1226741023.26697.help-gnu-emacs@gnu.org>
2008-11-16  1:54     ` Xah
2008-11-16 18:12       ` Ian Eure
2008-11-18  9:39         ` Kevin Rodgers
2008-11-18 23:25           ` Xavier Maillard
2008-11-16 21:40       ` Eli Zaretskii
     [not found]       ` <mailman.518.1226859137.26697.help-gnu-emacs@gnu.org>
2008-11-16 18:20         ` Richard Riley
2008-11-16 23:12           ` Ian Eure
2008-11-17  8:37             ` Paul R
2008-11-17 15:45               ` Drew Adams
     [not found]               ` <mailman.604.1226937124.26697.help-gnu-emacs@gnu.org>
2008-11-17 16:11                 ` Richard Riley
2008-11-17 18:53                   ` Drew Adams
2008-11-17 19:10                     ` Richard Riley
2008-11-17 19:57                       ` Drew Adams
2008-11-17 20:53                       ` Eli Zaretskii
     [not found]                       ` <mailman.621.1226951870.26697.help-gnu-emacs@gnu.org>
2008-11-17 21:42                         ` Richard Riley
2008-11-18  0:55                           ` Drew Adams
     [not found]                           ` <mailman.641.1226969742.26697.help-gnu-emacs@gnu.org>
2008-11-18  1:08                             ` Richard Riley
2008-11-18  2:55                               ` Drew Adams
2008-11-17 23:37               ` Alan Mackenzie
2008-11-18  7:52                 ` Paul R
2008-11-18 13:48                   ` Alan Mackenzie
     [not found]           ` <mailman.543.1226877138.26697.help-gnu-emacs@gnu.org>
2008-11-16 23:35             ` Richard Riley
2008-11-16 22:45         ` Xah
     [not found]       ` <mailman.536.1226871605.26697.help-gnu-emacs@gnu.org>
2008-11-16 23:17         ` Xah
2008-11-17 20:39           ` Eli Zaretskii
2008-11-17 23:46             ` Alan Mackenzie
2008-11-18  0:31               ` Lennart Borgman
2008-11-18  9:32               ` Kevin Rodgers
2008-11-18  9:58                 ` Alan Mackenzie
     [not found]             ` <mailman.633.1226964831.26697.help-gnu-emacs@gnu.org>
2008-11-18  9:46               ` Fabrice Niessen
     [not found]           ` <mailman.623.1226954396.26697.help-gnu-emacs@gnu.org>
2008-11-17 22:09             ` Xah
2008-11-18  2:33               ` B. T. Raven [this message]
2008-11-18  3:24                 ` Xah
2008-11-18  4:58                   ` B. T. Raven
2008-11-18  6:54                     ` Richard Riley
2008-11-18  4:11               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=saOdnbNHisD1tL_UnZ2dnUVZ_hudnZ2d@sysmatrix.net \
    --to=nihil@nihilo.net \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.