Re: basic question: going back to dired

["Juanma Barranquero" <lekktu@gmail.com>]

On Thu, Jul 24, 2008 at 14:17, Tim X <timx@nospam.dev.null> wrote:

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

Well, it matters to me. At least when I see people that I *know* will
benefit from using Emacs.

I don't have to look far. At work, there's people doing daily tasks
with Perl scripts and a very old (circa 1985, perhaps older) non-free
MS-DOS text editor, MultiEdit. If they used Emacs (and a couple
hundred lines of elisp code I could write for them), they would save
*lots* of pain (believe me when I say that: I wrote the Perl scripts
and know pretty well the data workflow). But there's no way in the
world that they will invest the time to adapt to Emacs, because it is
too far removed from what they're used to. In despair, I've even had
pipe dreams of writing a limited emulation of MultiEdit 3.0 in Emacs
22.

Their fault? Of course. Still...

> 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.

Sorry if I offended you. What I meant is that whether people will
contribute or not bears no relation to whether we should try to make
Emacs easier to learn or not for newbies.

> You mean like calling directories folders?

You won't see me defending that choice, though FWIW I think that's
Apple at work, not Microsoft.

> 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 know.

> 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.

Window vs. frame is an example. Not that I'm proposing changing it, of course.

> 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 -

Yes, it makes sense, but it was stretching a metaphor (even if it
predates Emacs). Moreover, I see two partially contradictory defenses
of "buffer":

  - that it is obviously a good term, whose meaning is quite easy to
grasp from previous meanings
  - that it is a concept more-or-less specific of Emacs and so it
helps newbies to realize that they are not dealing with files or
workspaces or anything like that.

> 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.

Curious. I wouldn't consider stability as *the* defining factor of
Emacs buffers; temporary buffers are about fast, non-persistent
storage, not stability, for example.

>     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!

I think that's conflating the program's view of buffers with the human
one. I've never thought of buffer's contents as messages, and they are
not FIFO queues for data.

> 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?

According to current trends, Firefox. If we started Emacs from
scratch, I bet we would call the frame "window", and the windows,
"tabs" (or "panes", depending of the specific details of the user
interface).

> Is the
> terminology so alien that one reading of the manual page wouldn't be
> enough to explain it?

Do you find difficult to use Windows (if you use it at all) because
the directories are, from the desktop POV, called "folders"? I'd bet
the answer is not, still you joked about because you think it is the
wrong term.

> 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?

As opposed to the terminology we use now, that has not become
outdated, you mean?

> I vote for the latter.

I'll abstain.

  Juanma