From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Newsgroups: gmane.emacs.help Subject: Re: basic question: going back to dired Date: Thu, 31 Jul 2008 06:37:46 -0700 (PDT) Organization: http://groups.google.com Message-ID: <0f5062bf-bca9-4355-8942-951805ed7ec6@b2g2000prf.googlegroups.com> References: <66d0c5e3-95d3-4c9b-a602-273375d6cf1f@j22g2000hsf.googlegroups.com> <9bc17528-8ea9-49f7-8e9d-07f5ede91415@p31g2000prf.googlegroups.com> <87bq0e1bmu.fsf@jehiel.elehack.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1217511715 17818 80.91.229.12 (31 Jul 2008 13:41:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jul 2008 13:41:55 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jul 31 15:42:45 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 1KOYQJ-0008Rn-H8 for geh-help-gnu-emacs@m.gmane.org; Thu, 31 Jul 2008 15:42:31 +0200 Original-Received: from localhost ([127.0.0.1]:48821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOYPP-00041z-25 for geh-help-gnu-emacs@m.gmane.org; Thu, 31 Jul 2008 09:41:35 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!b2g2000prf.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 137 Original-NNTP-Posting-Host: 24.6.97.120 Original-X-Trace: posting.google.com 1217511467 27704 127.0.0.1 (31 Jul 2008 13:37:47 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Thu, 31 Jul 2008 13:37:47 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: b2g2000prf.googlegroups.com; posting-host=24.6.97.120; posting-account=bRPKjQoAAACxZsR8_VPXCX27T2YcsyMA User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.22, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:160738 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:56085 Archived-At: Hi Michael, I think your post is well thought out. I don't totally agree though. Most terminology issues is simply a habituation. If you look at arbitrary software apps and terms, and think about it detail, there are all sort of illogicalities. For example, what's a Tab? What's a mouse? What the heck is a Desktop, Folder? Of course they all work by analogy, but superior technical terms exists for them. (e.g. Tab can be buffer, mouse should be pointing device, desktop should be file manager, folder should be dir) However, you don't see people complain about the term Tabs in FireFox, or mouse, or Folder in Apple circles, or Desktop in Mac/Windows/KDE/ Gnome. The term buffer works great, but again consider from a outsider's point of view. Apple's Xcode, Microsoft's VisualStudio, Eclispse and JavaBeans IDE for java. These are major IDEs for programing. They don't use =E2=80=9Cbuffer=E2=80=9D. BUT THEY ARE BUFFERS!! The point is not about logical quality in the term, but more about standard terminologies and universal adoption. I think, that emacs's manual, can benefit by replacing the term buffer in most places. All right, i don't want to push this point. Let's drop it then. How about we focuse on Keybinding vs Keyboard shortcut? Perhaps that is more easier to accept among emacsers. There are quite a lot technically questionable terms in emacs too. For example, kill-ring-save, kill-region, yank, kill-buffer. Why kill? death? Wouldn't delete or remove be better in some technical sense? kill-buffer can be close-buffer or remove-buffer. kill-ring- save could be kill-ring-append, kill-ring-push, kill-ring-add. And why kill-ring? It's not really circular as in The Lord Of The Ring, nor is it like mathematician's algebraic structure =E2=80=9Cring=E2=80=9D. How abo= ut text- depository or data-depository instead of kill-ring? Wait, better is buffer for kill-ring. After all, as so many emacsers insists here, buffer is rather the correct technical term as it is a temp storage! Also, note the sense of kill in kill-region and kill-buffer are incompatible. kill-region pushes text, while kill-buffer doesn't. So there, there is a inconsistency!! Egadz, emacs is trying to dumb me down. There's no ends when we start to exam the logicality of terminologies, may it in be computer software, or scientific jargons. A major force in the shaping of terminology is just historical happenstance. So, changing some criticial user-level terms in emacs manual so that they are more universally recoginzed, would be beneficial because it fixes one of the problem people complaints about emacs learning curve. Yet, choose changes that are easy to do and doesn't hurt emacs in ANY WAY. This is why, i think for example, switching the term keybinding to keyboard shortcut in emacs manual would be a improvement. (not for example, in elisp manual, because lots of lisp functions are tied to old terms, and programing is one level deep then using emacs. Programs understands things like obsolete functions and baggage in the language. Again, some says this creates inconsistency, but i don't think so in practice. If we nitpick we always will find inconsistency. Hell, in Perl and unix, there's almost nothing that is consistent.) Xah =E2=88=91 http://xahlee.org/ =E2=98=84 On Jul 31, 5:28 am, Michael Ekstrand wrote: > Xah writes: > > In this thread, i suggest that the term =E2=80=9Cbuffer=E2=80=9D could = be changed to > > =E2=80=9Ctab=E2=80=9D, =E2=80=9Cfile=E2=80=9D, =E2=80=9Cworkspace=E2=80= =9D or something similar, and =E2=80=9Ckeybinding=E2=80=9D can > > be changed to =E2=80=9Ckeyboard shortcut=E2=80=9D in any context that's= not about > > assiging a keyboard shortcut. > > I should probably know better than to dip my oar in the water here, but > I think that the term "buffer" cannot and should not be changed to any > of "tab", "file", or "workspace", largely by virtue of the fact that it > is not equivalent to any of the above. > > It is not a tab. If you have "tabs" going in Emacs (which XEmacs seems > to support in some fashion), or are in some other editor with tabs, they > are equivalent Emacs' "windows", not buffers. You could view the same > buffer in multiple tabs. What then? > > It is not a file. Sure, many buffers are backed by files. But a large > number of the buffers I use (SVN/CVS/HG status buffers, dired buffers, > Gnus mail summary/group list buffers, the buffer in which I'm writing > this e-mail if it weren't for the fact that I'm using nnml, so each > message is a file, and I could go on) are not directly corresponding to > files. So to use the term "file" instead of "buffer" would also be > incorrect. Think of Info buffers for another example -- one buffer > views, in turn, pieces of many different files. > > Finally, it is not a workspace. Etymologically, workspace is the most > viable alternative presented, but the term workspace as commonly used by > other editing systems does not apply. In Eclipse, for example, > "workspace" is a collection of projects, views, and settings -- one > working context. In my limited and dated experience with Visual Studio, > it uses the term similarly. This would be somewhat equivalent to an > Emacs session, but definitely not a buffer. > > A "buffer" is a useful term referring to a text chunk, or perhaps > alternatively an entity manipulable via a window. If we replace it with > any of the suggested replacement terms, we have a term which ceases to > accurately describe the item referred to. Yes, it's a new term. But > Emacs is a complex, technical tool, and expecting users to do some > learning (even of terminology) is a reasonable thing. I would also > argue that introducing (and defining!) a new term for a new concept > facilitates better and easier understanding of the editor than applying > a familiar term to something that it doesn't accurately describe. > > Remember as well, though, that most other editors don't even have the > concept that Emacs calls a "buffer" -- they let you edit files in tabs > and/or windows ("frames") possibly collected into workspaces. Why > should we apply one of their terms inaccurately to a concept that they > don't even possess? > > If we want to banter about confusing terminology, there are some > reasonable targets ("window" and "frame" vs. "pane" and "window", for > example), but even there, the costs involved in changing are > significant. > > - Michael > > -- > mouse, n: A device for pointing at the xterm in which you want to type.