emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-dat


From: Andy Piper
Subject: RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)
Date: Sat, 20 Apr 2002 14:48:52 -0700

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: address@hidden
> [mailto:address@hidden Behalf Of Kyle Jones
> Sent: Saturday, April 20, 2002 2:27 PM
> To: Michael Toomim
> Cc: Miles Bader; Eli Zaretskii; address@hidden; address@hidden;
> address@hidden; address@hidden
> Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more
> up-to-date)
>
>
> Michael Toomim writes:
>  > Miles Bader wrote:
>  > > "Eli Zaretskii" <address@hidden> 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".
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]