From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "B. T. Raven" Newsgroups: gmane.emacs.help Subject: Re: emacs mode line suggestions Date: Mon, 17 Nov 2008 20:33:15 -0600 Message-ID: References: <15962952-6180-41bd-abce-1b919aa55807@v13g2000pro.googlegroups.com> <39353809-6edf-4b7e-aae2-e0dd4d614c61@a26g2000prf.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1226976053 25018 80.91.229.12 (18 Nov 2008 02:40:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2008 02:40:53 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 18 03:41:53 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L2GXH-0008Qj-VV for geh-help-gnu-emacs@m.gmane.org; Tue, 18 Nov 2008 03:41:52 +0100 Original-Received: from localhost ([127.0.0.1]:41921 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2GW9-0002YI-F5 for geh-help-gnu-emacs@m.gmane.org; Mon, 17 Nov 2008 21:40:41 -0500 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.sysmatrix.net!news.sysmatrix.net.POSTED!not-for-mail Original-NNTP-Posting-Date: Mon, 17 Nov 2008 20:33:11 -0600 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Original-Newsgroups: gnu.emacs.help In-Reply-To: Original-Lines: 106 X-Usenet-Provider: http://www.giganews.com Original-NNTP-Posting-Host: 65.45.140.22 Original-X-Trace: sv3-iBDAdqwzrQTwNs+jPFO+rMcy9v36nQ3SU+LE7Rhjo/1EcXItSK4/PyIyfGO0VjZz8za1kXnkoXqBBSr!T2vN74tt/81bG2/9bU+badYkdfrauq0seYpaSw7AbptZod6g3wnKANgdI6Hz8KwEsVRJ32F0voJr!DY3RVojpUWTRVAf7XPtIoZzbTbpvDg== Original-X-Complaints-To: abuse@sysmatrix.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Original-Xref: news.stanford.edu gnu.emacs.help:164553 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:59887 Archived-At: Xah wrote: > On Nov 17, 12:39 pm, Eli Zaretskii wrote: >>> From:Xah 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