From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Andy Piper" Newsgroups: gmane.emacs.devel Subject: RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: Sat, 20 Apr 2002 14:48:52 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: References: <15553.56593.407791.923999@ice.wonderworks.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1019339484 10793 127.0.0.1 (20 Apr 2002 21:51:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2002 21:51:24 +0000 (UTC) Cc: "Miles Bader" , "Eli Zaretskii" , , , , Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16z2lQ-0002ny-00 for ; Sat, 20 Apr 2002 23:51:24 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16z35S-00018j-00 for ; Sun, 21 Apr 2002 00:12:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16z2lE-0006fA-00; Sat, 20 Apr 2002 17:51:12 -0400 Original-Received: from rwcrmhc51.attbi.com ([204.127.198.38]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16z2jK-0006WX-00; Sat, 20 Apr 2002 17:49:14 -0400 Original-Received: from TSUNAMI ([12.232.15.85]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020420214913.UUFY1143.rwcrmhc51.attbi.com@TSUNAMI>; Sat, 20 Apr 2002 21:49:13 +0000 Original-To: "Kyle Jones" , "Michael Toomim" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <15553.56593.407791.923999@ice.wonderworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2886 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2886 I think the issue is not so much that Emacs uses weird terminology but that Emacs uses different terminology to a hundred other editors. Seems like we're arguing for Esperanto rather than words that are actually in the dictionary. andy > -----Original Message----- > From: xemacs-design-admin@xemacs.org > [mailto:xemacs-design-admin@xemacs.org]On Behalf Of Kyle Jones > Sent: Saturday, April 20, 2002 2:27 PM > To: Michael Toomim > Cc: Miles Bader; Eli Zaretskii; link@pobox.com; bradym@balestra.org; > xemacs-design@xemacs.org; emacs-devel@gnu.org > Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more > up-to-date) > > > Michael Toomim writes: > > Miles Bader wrote: > > > "Eli Zaretskii" writes: > > > > > >>As for buffers, I disagree that it's unused in the context used by > > >>Emacs. I've seen several editors that do the same. > > > > > > > > > And anyway, buffers are _not_ the same as `files' or `documents', and > > > indeed, the name quite accurately describes what it does (and > > > corresponds directly to the concept of a buffer you say > you're used to > > > doing OS work). Sometimes there's a one-to-one > correspondence between > > > buffers and files, but quite often there's not. Once a user learns > > > about this, he can use this advantage. > > > > The term "buffer" means nothing to a new emacs user, even if > > they thoroughly understand the dictionary definition of it. > > > > It would make much more sense to new users if they were just > > called files or documents, since that's what they are to > > newbies, and learning what a buffer is is a big hurdle one > > has to jump over when learning emacs. > > It's a hurdle that one has to jump with any editor in which you > edit a copy of a file and commit changes only by "saving" them. > If people have trouble with this concept then this is just one of > those things they will have to learn because editing a buffer is > in fact what is happening. If you don't understand the buffer > concept then you'll wonder why your edits don't take effect in > the filesystem as soon as you type them. Is their anyone using > computers today who doesn't understand the concept of an edit > buffer, even if they don't know the term "buffer"? If not, then > it's just a matter of them learning a new word. People who won't > learn a new word display a breaktaking intellectual bankruptcy > that's far beyond our ability to change. > > I know the pain of which you speak. Recently I've started learning > how to use the Gimp and a lot of the terms (or the way the terms are > used) are new to me. But that isn't surprising because I don't do > digital image processing for a living. I don't expect the Gimp's > authors to change their terminology to suit me, an ignoramus. What > I want is that whatever terms they use be used consistently within > the application so that time spent learning the terms isn't wasted. > > That's the goal we should strive for. We should use terminology > that's familiar to normal practitioners of the art and we should > use it consistently. This does not mean saying "lepidoptera" > instead of "butterfly", this means saying "butterfly" instead of > "bug". >