From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: basic question: going back to dired Date: Wed, 23 Jul 2008 19:46:38 +1000 Organization: Rapt Technologies Message-ID: <87vdyx0w75.fsf@lion.rapttech.com.au> References: <4884DC7F.6060406@gmail.com> <819feff4-76e3-4bf8-9ece-7b47f099efc2@j22g2000hsf.googlegroups.com> <87hcaiiatp.fsf@bzg.ath.cx> <86r69laodc.fsf@timbral.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216809886 6531 80.91.229.12 (23 Jul 2008 10:44:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Jul 2008 10:44:46 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jul 23 12:45:35 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 1KLbqg-0002ET-4E for geh-help-gnu-emacs@m.gmane.org; Wed, 23 Jul 2008 12:45:34 +0200 Original-Received: from localhost ([127.0.0.1]:53720 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLbpm-00034g-NQ for geh-help-gnu-emacs@m.gmane.org; Wed, 23 Jul 2008 06:44:38 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!flpi089.ffdc.sbc.com!prodigy.net!news.astraweb.com!border1.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:CL9cthZDADiWDVqvB2KNKA0Skg0= Original-Lines: 138 Original-NNTP-Posting-Host: b6a3e3f3.news.astraweb.com Original-X-Trace: DXC=]:AF1hBUAPb<^_jE4S2b@oL?0kYOcDh@jIGb]mONgOijP@8f`@g3odhRTFYYW29Y\jaTABLbQ17fh Original-Xref: news.stanford.edu gnu.emacs.help:160494 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:55842 Archived-At: Evans Winner writes: > "Juanma Barranquero" writes: > > I'm not for or against changing Emacs' terminology. I > think it would be a huge amount of work. But I don't > understand why some people reacts as if the very idea is > flawed. There's nothing sacred in "buffer" and > "keybinding" and "minibuffer", just history. The change > should be susceptible to rational (if perhaps a bit > pointless) discussion, because it is not hard to find > good arguments for it; "frame/window" vs "window/pane" > is a good example. > > The issue is not history or short-term convenience for new > users but precision. Emacs does not use workspaces or > panes, but buffers. A user who wants to write a little code > to do something useful needs to know that essentially the > same function that is used to open a file and write text in > it manually is what is used to create any buffer, even one > that never displays anything, has some processing go on in > it and then vanishes--that the display of data in a buffer > is a separate thing from the data structure itself; or why > some buffers are associated with files and others, like > completion buffers have no file associated with them, and > how to write programs that take advantage of the same > functionality. > This is a critical point and an example of Xah's simplistic 'broad but shallow' understanding that is all too common with much of what he writes. The point he (and some others) miss is that 'buffer' is NOT the same as workspace. As you point out, buffers are central to how emacs operates and are not synonymous with a workspace. There are a number of situations where any number of the suggested replacements would It hink be more confusing than the current use of the term buffer. I have nothing against updating the terminology, but only if the new terminology is able to have the same level of accuracy as the existing one. To date, I've not seen any suggestions which would make things more accurate and precise. On the contrary, most of the suggestions are less precise and more likely to cause confusion. I also disagree with classifying emacs as just a text editor. If anything, it is primarily a programmers editor. At least it is far more powerful and better suited in that task than as a text editor for just plain text (as in word processing). I know that it can do both very well, but lets face it, the focus is primarily for the sorts of tasks programmers are more likely to do. As such, I find the claim that its terminology is too programmer centric to be rediculous. I would have to admit I don't really care if the non-programmer user finds it difficult. There are plenty of other editors out there that would probably be better suited to their needs anyway. In fact, I think its only when you have an interest in programming and related activities that you will really benefit from the extensibility of emacs. If your just editing basic text and not interested in learning a little elisp in order to customize things to your specific needs, your likely not to appreciate the possibilities available and less likely to care. Worse yet, you likely to find emacs confusing and lacking in the functionality of other systems that are probably better suited to your needs. I don't get why some people, after discovering emacs, feel they need to modify it so that the rest of the world gets converted to the church of emacs. Likewise, I don't have an issue with anyone who believes that the only true editor is VI or textmate, or Crisp or whatever. The wonderful thing about this whole area is therre is a huge amount of choice. Far more important than pointless debates regarding terminology is the benefits that groups like the FSF have given us - not cheap/free software, but the free an open sharing of knowledge and the necessary technical infrastructure that can allow any of us with the desire and drive to develop what we feel is the best/better system. With things like the GPL, you don't even have to start from scratch. You can take the sources and build/modify/extend them how you want. Instead, what we seem to be getting morer of are often ill conceived and rather shallow philosophical rants about what is wrong rather than anything of real substance. Xah produces miles of poorly expressed ideas that are usually very shallow. Sometimes, there is some glimmer of original thought buried in there and although rare, sometimes there are some half decent ideas. However, his unwillingness to participate in genuine debate and his frequent tactic of reverting to personal insult whenever anyone disagrees with his point of view and his obvious insecurity at being criticised means that the good ideas remain under developed and never hit maturity. Much of what he has done that does have some real beneficial content seems a bit misguided as well. for example, he appears to have put a lot of effort into re-formatting the Emacs on-line manual. However, such manuals are livinig artifacts and need to be kept up-=to-date with the developments of emacs itself. While I personally don't see what his version of the manual has that the built-in version hasn't, I suspect that in the long-term, he will find keeping it in sync and up-to-date too labor intensive and his on-line version will just become another repository of out-of-date emacs information that is likely to be morer misleading than helpful in the long-term. > A person who has been told that he is working with > ``windows'' (meaning buffers in Emacs) is thus conceptually > crippled if he wants to do something that could be done with > buffers other than using them as windows. Xah Lee has > written about the danger of excessive use of jargon in > computer work and I generally agree with him, but even more > dangerous is the use of metaphor. A metaphor, like > ``workspace'' only tells you as much about a thing as the > inventor of the metaphor wanted you to know, but makes it > impossible to extend your understanding past that. > > If the term keybinding ought to be changed to anything it > should be rather something like input-binding (since > function execution can be triggered by any form of input, > not just keyboard presses) than ``shortcut'' or whatever > such woozy nonsense. Yep, I personally don't find any of the suggested alternatives to key-binding as clear and accurate. for example, 'short cut' only tells you that a certain key combination is a shorthand version of entering the command in the mini-buffer (or is that mini-workspace!). It doesn't really reinforce the point that binding an action to a key can be used for many things and is not just for creating convenient 'short cuts'. For me, the term key binding means that I can bind actions to a key and that those actions are not restricted to simple convenience short-cuts. I can use the concept to create a whole new interface paradigm that is only limited by my imagination. If on the other hand, I had only been told that you can associate a short-cut to a key, while I wold have found it simple and straight-forward, I probably would only have used the facility to create convenience short-cuts for common commands to cut down on my typing. I could easily have misse the subtle difference and the idea that what I can actually do is really a lot more. Tim -- tcross (at) rapttech dot com dot au