Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Wed, Jul 23, 2008 at 12:25, Tim X <timx@nospam.dev.null> wrote:
>
>> so what? I'm not trying to be argumentative, but what does it really
>> matter if new users have a bit of a learning curve?
>
> You talk about "a bit of a learning curve". I worry about the people
> who simply leaves Emacs behind. I know people who are happy users of
> Emacs, who do know almost nothing of it and would not even have used
> it, had not I customized the font-lock colors to their liking.
>

But what does it really matter if some people just leave it behind? 

>> Why should emacs
>> appear to be just like any other text editor?
>
> There's a difference between "appearing to be just like any other text
> editor" and "using common terms for common things". Emacs certainly is
> not the only one to use windows, but it is the only one calling them
> "frames", AFAIK.
>
>> While probably sounding
>> provocative, how many new uses who are not prepared to learn emacs
>> terminology are actually going to contribute anything? If they don't
>> contribute anything, what does it matter if there is only 1 a year or
>> 100 a week?
>
> In my view, the goal of free software is giving the users freedom, not
> blackmailing them into contributing. Emacs has a Windows port because
> it has been deemed useful to the free software cause, even if only a
> tiny fraction of them will ever contribute.

There is no blackmail here. You don't have to use it and you don't have
to contribute. Just because I'm not arguing to change things to get new
users doesn't mean any form of blackmail - thats just emotional
dribble. What free software does is give everyone the opportunity to use
it and change it how they want. There is nothing stopping Xah or anyone
else from taking emacs and changing the interface and manual
references to terms they don't like to ones they do. However, it seems
most would prefer to just talk than do and there seems to be this
expectation it will somehow happen. . 
>
>> Taking things in another direction, could it not be that as emacs is
>> significantly different in approach, functionality and extensibility
>> than nearly all other editors, might not a different terminology
>> actually help new uses grasp that this is not just another editor?
>
> Even if it is so significantly different, common things are common
> things. It would be silly to call files with another name just to make
> the point that Emacs is different, for example.
>

You mean like calling directories folders? 

The point is, emacs didn't adopt its current terminology to be
different. It adopted the current terminology because it was amongst the
first to offer such functionality and at the time, there was little
consensus on what to use. I don't have an issue with updating
terminology if we can be assured the new terminology doesn't make the
situation worse AND we don't lose clarity or end up with terms that are
even less concise and prone to increased confusion. 

I'm am also not convinced there really is a problem here - or at least a
problem that would in fact be solved by changing the terms. consider the
use of buffer. Xah argues this was used because of computer science
geeks. However, at the time it was adopted, buffer was the better known
and used term. It is also not a term unique to computing science nor was
it created by computer scientists. Like many of the terms used in
computing, it was borrowed from somewhere else (consider other terms
like cache). If we look at the more general meaning of buffer, it
actually makes sense. For example, here are some definitions of buffer
from some dictionaries -

>From The Collaborative International Dictionary of English v.0.48 [gcide]:

  buffer \buff"er\ (b[u^]f"[~e]r), v. t. (Chem.)
     to add a buffer[5] to (a solution), so as to reduce unwanted
     fluctuation of acidity.
     [PJC]

Maybe Emacs used it to represent a "stable" representation that doesn't
fluctuate i.e. underlying file, process, etc may be changing the
contents frequently?

>From The Collaborative International Dictionary of English v.0.48 [gcide]:

  Buffer \Buff"er\ (b[u^]f"[~e]r), n. [Prop a striker. See
     {Buffet} a blow.]
     1. (Mech.)
        (a) An elastic apparatus or fender, for deadening the jar
            caused by the collision of bodies; as, a buffer at the
            end of a railroad car.
        (b) A pad or cushion forming the end of a fender, which
            receives the blow; -- sometimes called {buffing
            apparatus}.
            [1913 Webster]

Hmmm. could be a theme emerging here in which a buffer is something that
protects/cushions/pads against jarring/sudden/unwanted change/impact
i.e. prvides a stable representation. 

     4. A good-humored, slow-witted fellow; -- usually said of an
        elderly man. [Colloq.] --Dickens.
        [1913 Webster]

Well, given the emacs doctor (M-x doctor), the age (for a software
package) and the fact computers are pretty witless......

     5. (Chem.) a substance or mixture of substances which can
        absorb or neutralize a certain quantity of acid or base
        and thus keep the degree of acidity or alkalinity of a
        solution (as measured by pH) relatively stable. Sometimes
        the term is used in a medical context to mean {antacid}.
        [PJC]

Ah, that stability theme again....

     7. any object or person that shields another object or person
        from harm, shock, or annoyance; as, the President's staff
        is his buffer from constant interruptions of his work.
        [PJC]

Now this is getting close to how I think of the emacs 'buffer'. It
protects me by allowing me to throw away changes when I realise I've got
it wrong, it shields me from the shock of finding out the file is from
DOS and all the line endings are wrong and eliminates my anoyance at
having to find a conversion utility before I can edit it comfortably.

>From WordNet (r) 3.0 (2006) [wn]

      2: a neutral zone between two rival powers that is created in
         order to diminish the danger of conflict [syn: {buffer zone},
         {buffer}]

That damned stability theme again...

and if we look at the definition in the on-line dictionary of computer
science, we get 

     1. An area of memory used for storing messages.  Typically, a
     buffer will have other attributes such as an input pointer
     (where new data will be written into the buffer), and output
     pointer (where the next item will be read from) and/or a count
     of the space used or free.  Buffers are used to decouple
     processes so that the reader and writer may operate at
     different speeds or on different sized blocks of data.

well, that does seem to describe emacs buffers - they are a section of
memory, they have pointers (even a think referred to as point) and if we
slightly generalise and consider the computer as one party and the human
as the other, they also handle the mismatch of speeds and size of blocks
that can be processed comfortably and with few errors!

Seems quite reasonable to me.

I won't go into as much detail regarding windows. However, note that all
the windows I grew up with had a window frame, that even in operating
systems like MS Windows, they refer to the point where the title and
iconify/minimise/maximise buttons live as the window frame. 

Turn things around the other way. Firefox refers to the whole thing as a
window and when they have multiple display areas within the display
window, they are called tabs. Emacs has multiple windows within a
frame. Which terminology is more consistent? Sure, you couuld argue
emacs possibly could have called the windows panes and called the fringe
the frame, but is it really that hard a concept to get? Is the
terminology so alien that one reading of the manual page wouldn't be
enough to explain it?



>> There could be an argument that making users learn from scratch and with
>> different terminology will help because it makes them adopt a new
>> mindset and stops them from comparing it to what they already know?
>
> I think there are people who prefer to learn from scratch, and others
> who really do it better if they have something to base on.
>

Agreed. So, what now? Do we have to try and cater for everyone? Do we
adopt terminology which may be proven wrong or which could likely become
outdated in the future anyway? Do we put effort into trying to stay
in-sync with evolving terminology trends or do we put energy into just
pushing the boundries of what can be done conceptually and technically? 

I vote for the latter.

Tim


-- 
tcross (at) rapttech dot com dot au