🚀 go-pugleaf

I can't believe all these people coming out in defense of emacs's
screwy scroll-up/down nomenclature.
I am a big fan of emacs, and yes, I've read the excuses given in the
elisp manual for why they're named the way they are...
but it's so darn counter-intuitive to me, I just can't believe that
all you people are really being honest when you say things like:

In article <FRIEDMAN.93Jan8021040@nutrimat.gnu.ai.mit.edu> friedman@gnu.ai.mit.edu (Noah Friedman) writes:
> Secondly, there is no correct definition of "scroll up" or "scroll down",
> because the direction of scrolling depends on your frame of reference.
> There's no particular reason to choose one frame of reference over another;
> some people find one more intuitive, others another.

There's GOT to be a reason to choose one frame of reference over another.
(If there isn't, then you've got to admit vi is at least as right as
emacs.)
[The above GOT is meant to express my personal frustration, not a logical
necessity...]

   Ok, here's a good reason for preferring vi's way over emacs's: when
you're in a scrolled window in a GUI and you click on the down-arrow
in the scrollbar, what happens?  You move down through the document!
The same if you drag the block in the middle of the scrollbar
downward.  Do any of you think this is ambiguous or counter-intuitive?
How about the PageUp/PageDown keys on many keyboards?  How about the
up-arrow key -- what word-processor ever used it in any way to do
what scroll-up does?  Would you expect Shift-UpArrow to move to the
beginning of the document, or the end?

   It seems to me that there's a very strong convention of moving
"down" meaning moving to a later part in the text; i.e. the observer
is moving, not the text.

Ok, how's this for an "origin of intuition" about this subject.

   In our day-to-day experience, when we want to look at a different
part of something, do we more often move relative to that thing, or
move that thing?  I say we move ourselves, or at least move our eyes
(frames of observation) much more often than we move the thing.
Looking through a telescope or binoculars.  Movies, TV.

    When reading a book, sure we turn pages, but when reading a page
(and reading a text file in emacs is like reading a single page -- or
many pages attached top-to-bottom) we move our eyes down the page.
Have you ever seen someone stare at one spot (fixed relative to their
head) and move the book upward as they read each page?  Ok, I'm being
a bit silly but on with the point.

    The only counter-examples are when we have a piece of
observational equipment that's large and hard to move compared to the
subject, such as a microscope or microfiche reader.  (Please, no
cracks about Emacs's size. ;^) This happens rarely and is
counter-intuitive.  Remember the first time you used one of these
devices?  Didn't you, at first, mistakenly move the slide or
microfiche in the opposite direction from the way you wanted to?  I
know I did... am I crazy?  Of course after a couple of seconds you got
used to it.  But we're talking about what's *intuitive* here.

   Obviously, on the surface, when we scroll through a file in emacs,
the graphic depiction of the window is standing still on the monitor
(and visually, the text moves, relative to the monitor).  But that
doesn't mean the window isn't moving; it just means that the window,
the monitor, and the user aren't moving relative to each other.
   On the conceptual level, the text is an object in an abstract space.
It still exists even when we save it in a file and leave emacs,
destroying the window.  The window exists to observe the text; the
text does not exist for the sake of the window.  Moving the text
around in this space doesn't make sense... it's irrelevant.  It has
no effect (going on the assumption that the text exists independent
of the window, and not vice versa.)  Our purpose is not to change the
location of the text; we just want to see different parts of it.
   Consider what happens when we view the same buffer in two different
windows, and we scroll one of them.  The text can't be moving, because
if it were, it would appear to move in both windows.  (Or would you
argue that scroll-up means "Move text and all other windows showing
this buffer up" ??!)  There is one buffer, and one of the windows is
moving relative to it.

   Finally -- and this would be the strongest point for any diehard
relativist who's still not convinced that it's the window that's
moving and not the text -- note that other commands for moving around
in the text are named as, well, just that: ways of moving around in
the text, not moving the text around.  It is confusing to make the
names of most commands refer to how the frame moves, but make the
names of a couple of commands refer to how the text moves -- *even if*
the latter paradigm were just as intuitive.

   For example, beginning-of-buffer moves the frame to the beginning
of the buffer.  In isearch-forward, you
  "Type ESC to exit, leaving point at location found."
See, the point is moved to a location in the text.  And our frame
follows the point.  forward-char, next-line, forward-word, forward-sexp,
end-of-line, etc. all refer to how the point moves, not to how the text moves.
(The words "up" and "down" are not the issue here -- the issue is whether
it is the text or the frame that is moving.)
Documentation string for set-window-point:
"Make point value in WINDOW be at position POS in WINDOW's buffer."
Not:
"Make point value in WINDOW's buffer be at position POS relative to WINDOW."

Why should moving the point be labelled opposite to moving the window?
They're analogous concepts.  The window surrounds the point.  The window
shows a large region of the text; the point indicates a single position
in the text.
   Usually when I hit down-arrow, the cursor goes down a line,
relative to both the text and the monitor.  When the cursor is at the
bottom of the screen and I hit down-arrow, the cursor moves down and --
why should I suddenly switch paradigms and say no, the cursor says still
but the text moves up?

In fairness to the writers of emacs, let me quote from the elisp manual:
>    Some people have urged that the opposite convention be used: they
> imagine that the window moves over text that remains in place.  Then
> "down" commands would take you to the end of the buffer.  This view
> is more consistent with the actual relationship between windows and
> the text in the buffer, but it is less like what the user sees.  The
> position of a window on the terminal does not move, and short
> scrolling commands clearly move the text up or down on the screen. 
> We have chosen names that fit the user's point of view.

I argue that the user's intuition is not as shallow as how dots are moving
on the screen.  Intuition deals with objects and their relationships,
whether seen or implied.

To put it all in perspective...
I'm not obsessed with this issue.  (Really... it's just late at night!)
I'm not lobbying for emacs to be changed.  I'm certainly not claiming
that emacs is inferior -- it's one of my favorite programs of all time.
(And that's why I care.)
I just think that for the sake of intuitiveness and consistency,
the names scroll-up and scroll-down should have been chosen the other
way.
I'm not demanding that you all agree with me either.  But I hope I've
communicated *why* I think there are very definite reasons for preferring
one frame of reference over another.

Lars Huttar                          3
huttar@hp750.itg.ti.com      ||   _______           ____      ||
(Opinions herein are not     ||:  |  |  |   |   |   |  |   | :||  Mars
necessarily those of TI.)    ||  _| _| _|  _|  _|  _| _|  _|  ||