From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Ekstrand Newsgroups: gmane.emacs.help Subject: Re: basic question: going back to dired Date: Thu, 31 Jul 2008 07:28:09 -0500 Organization: Aioe.org NNTP Server Message-ID: <87bq0e1bmu.fsf@jehiel.elehack.net> References: <66d0c5e3-95d3-4c9b-a602-273375d6cf1f@j22g2000hsf.googlegroups.com> <9bc17528-8ea9-49f7-8e9d-07f5ede91415@p31g2000prf.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1217538911 18457 80.91.229.12 (31 Jul 2008 21:15:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jul 2008 21:15:11 +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 23:16:01 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 1KOfUW-0007J3-ER for geh-help-gnu-emacs@m.gmane.org; Thu, 31 Jul 2008 23:15:20 +0200 Original-Received: from localhost ([127.0.0.1]:45417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOfTb-0000dS-RC for geh-help-gnu-emacs@m.gmane.org; Thu, 31 Jul 2008 17:14:23 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!goblin1!goblin.stu.neva.ru!newsfeed.straub-nv.de!news.k-dsl.de!aioe.org!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 58 Original-NNTP-Posting-Host: N8w1zDuSd4zhmZ454raJDg.user.aioe.org Original-X-Complaints-To: abuse@aioe.org Cancel-Lock: sha1:XR7qZ6hfPhQFaDB7SNLWnzY6bFM= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Original-Xref: news.stanford.edu gnu.emacs.help:160736 X-Mailman-Approved-At: Thu, 31 Jul 2008 17:14:06 -0400 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:56102 Archived-At: Xah writes: > In this thread, i suggest that the term “buffer” could be changed to > “tab”, “file”, “workspace” or something similar, and “keybinding” can > be changed to “keyboard shortcut” 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.