Re: basic question: going back to dired

[Tim X]

William Case <billlinux@rogers.com> writes:

> Hi all;
>
> 2¢
>
> On Sat, 2008-07-26 at 14:38 +1000, Tim X wrote:
>> "Juanma Barranquero" <lekktu@gmail.com> writes:
>> 
>> > On Thu, Jul 24, 2008 at 14:36, Tim X <timx@nospam.dev.null> wrote:
>> >
>> >> But don't forget its not just a comp sci term. In fact, comp sci
>> >> borrowed it from "normal" english. In my comp sci days, also in the 80s,
>> >> it still had the more generalised term that fits with how emacs uses
>> >> it.
>> >
>> > As would have lots of other terms. That's what I'm saying: "buffer"
>> > seems like the perfect match for Emacs
>> > data-structures-for-temporary-storage-under-whatever-name because
>> > we've been using it that way for 25+ years, not because it is the
>> > only, or more fitting, or more appropriate term.
>> >
>> > This conversation (not specifically with you Tim, I'm talking about
>> > the thread) goes nowhere. I said that I'm not proposing to change
>> > anything, but at the same time I *don't* believe there's anything
>> > sacred on the terms used in Emacs today. They are the best just
>> > because of long use and long familiarity. Which does not necessarily
>> > apply to newbies.
>> >
>> 
>> Which is not that far from my position. Most of my comments are related
>> to Xah and others who believe it should be changed. I'm not arguing it
>> shouldn't be changed because its sacred or anything. My point is that I
>> a) don't believe its as bad as some like Xah argue and b) nobody has
>> come up with any alternatives that don't lose us more than they gain and
>> c) I'm not convinced that changing all the terminology would actually
>> change the number of new users who give up and don't bother because I
>> don't believe the terminology is the main thing that makes new users
>> give up. 
>> 
>> Tim
>> 
>
> I have heard and read this and similar conversations on the Emacs user
> list and several other applications mailing lists over the last 3 years.
>>From my personal experience both sides of the argument are right.  
>
> New users find the terminology, extremely confusing and off putting.  It
> takes a considerable amount of time to build up the concepts and
> vocabulary to begin to understand how Emacs works; how to find your way
> around 'help info'; and how to understand basic elipse variables and
> functions.  On the other hand, the terminology used by Emacs is more
> specific and accurate so that once a user becomes experienced, it is
> much easier to find an answer and/or describe a problem with specialized
> terminology.
>
> With open source software, both points of view can be accommodated.  I
> believe that the point of FOSS is that applications can be amended and
> augmented so that all perspectives can be included. There is no need for
> "my way or the highway".
>
> As a case in point, "shortcut keys" should be included in the glossary
> and the various indexes.  They simply need to be linked to the info
> section on "key binding".  The actual section on key binding merely
> needs an introductory sentence or two explaining why the term "key
> binding" is used in Emacs and why it is a better term for how Emacs
> works than the more common term "shortcut key".  Similarly the section
> on "buffers" could be linked to "page", "window" and "file" with a
> forwarding link to the sections that deal with how these terms
> themselves (page,window and file) are used in Emacs.
>
> As I think about it, only about 10 -15 terms would need such synonyms.
> For the purists, I would like them to cast their minds back to the first
> time they used Emacs.  The concepts behind the various terms was never
> too difficult to grasp, but surely you remember the hours wasted and
> utter frustration that you must have had in the beginning just trying to
> find a way into the program and trying to execute the simplest command
> when NOTHING was familiar.

Actually, I didn't find it an issue at all. In fact, it was the very
first program I learnt after losing my sight over 10 years ago - before
that, I was a VI user. I switched to emacs because of the wonderful
emacspeak package. I'm also no genius and don't have any special ability
or great skill. However, I do have a process that has always served me
well with anything new, whether it be a new dvd player, television,
microwave or computer. The first thing I do is read the documentation
and if there is a tutorial, I run through it. This is what I did with
emacs and I found it to have the best and clearest tutorial and manual
of any software Ive ever used that has been put together prety much by
volunteers.

I have no issue with anything you have suggested, apart from the fact it
is largely done. If you look at the current emacs manual (CVS emacs -
not sure about older manuals), you will find it already has most, if not
all, your suggestions. Furthermore, many of the emacs maintainers have
frequently asked for contributions or for users to identify parts of the
manual they found confusing or lacking in some way. Despite all the
people who like to criticise emacs' terms, few seem to be prepared to
actually address whatever problems they see by contributing to the
documentation. This is probably my main issue (if I actually had one,
but I don't really). 

For example, a quick I search of the glossary for some of the terms
being mentioned in this thread came up with the following -

Keyboard Shortcut
     A keyboard shortcut is a key sequence (q.v.) which invokes a
     command.  What some programs call "assigning a keyboard shortcut,"
     Emacs calls "binding a key sequence."  See `binding.'

Buffer
     The buffer is the basic editing unit; one buffer corresponds to
     one text being edited.  You can have several buffers, but at any
     time you are editing only one, the `current buffer,' though
     several can be visible when you are using multiple windows (q.v.).
     Most buffers are visiting (q.v.) some file.  *Note Buffers::.

Frame
     A frame is a rectangular cluster of Emacs windows.  Emacs starts
     out with one frame, but you can create more.  You can subdivide
     each frame into Emacs windows (q.v.).  When you are using a window
     system (q.v.), all the frames can be visible at the same time.
     *Note Frames::.  Some other editors use the term "window" for this,
     but in Emacs a window means something else.

Window
     Emacs divides a frame (q.v.) into one or more windows, each of
     which can display the contents of one buffer (q.v.) at any time.
     *Note Screen::, for basic information on how Emacs uses the screen.
     *Note Windows::, for commands to control the use of windows.  Some
     other editors use the term "window" for what we call a `frame'
     (q.v.) in Emacs.

Face
     A face is a style of displaying characters.  It specifies
     attributes such as font family and size, foreground and background
     colors, underline and strike-through, background stipple, etc.
     Emacs provides features to associate specific faces with portions
     of buffer text, in order to display that text as specified by the
     face attributes.  *Note Faces::.

Syntax Highlighting
     See `font lock.'

Font Lock
     Font Lock is a mode that highlights parts of buffer text according
     to its syntax.  *Note Font Lock::.

Line Wrapping
     See `filling.'

If anyone knows of terms they have encountered that are not obvious and
are not in the glossary, then write up the definition and submit it for
inclusion in the manual. 

Tim


-- 
tcross (at) rapttech dot com dot au