home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / editors / 3184 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  8.5 KB

  1. Xref: sparky comp.editors:3184 alt.religion.computers:941 alt.religion.emacs:509
  2. Newsgroups: comp.editors,alt.religion.computers,alt.religion.emacs
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.dseg.ti.com!ief!ief!huttar
  4. From: huttar@hp750.itg.ti.com (Lars Huttar)
  5. Subject: Re: scroll up/down
  6. Sender: usenet@ief.itg.ti.com (Mr. USENET)
  7. Message-ID: <HUTTAR.93Jan9042626@hp750.itg.ti.com>
  8. In-Reply-To: friedman@gnu.ai.mit.edu's message of 8 Jan 93 02:10:40
  9. Date: Sat, 9 Jan 1993 04:26:26 GMT
  10. Distribution: inet
  11. References: <SHIBUYA.93Jan7195820@chute.bl.applicon.slb.com>
  12.     <FRIEDMAN.93Jan8021040@nutrimat.gnu.ai.mit.edu>
  13. Nntp-Posting-Host: iefhp750.itg.ti.com
  14. Organization: IEF Development, Texas Instruments Inc., Plano Texas
  15. X-Disclaimer: This message was written by a user at Texas Instruments Inc.
  16.               The opinions expressed within are those of the user and not
  17.               necessarily those of Texas Instruments.
  18.                                                      
  19. Lines: 141
  20.  
  21.  
  22. I can't believe all these people coming out in defense of emacs's
  23. screwy scroll-up/down nomenclature.
  24. I am a big fan of emacs, and yes, I've read the excuses given in the
  25. elisp manual for why they're named the way they are...
  26. but it's so darn counter-intuitive to me, I just can't believe that
  27. all you people are really being honest when you say things like:
  28.  
  29. In article <FRIEDMAN.93Jan8021040@nutrimat.gnu.ai.mit.edu> friedman@gnu.ai.mit.edu (Noah Friedman) writes:
  30. > Secondly, there is no correct definition of "scroll up" or "scroll down",
  31. > because the direction of scrolling depends on your frame of reference.
  32. > There's no particular reason to choose one frame of reference over another;
  33. > some people find one more intuitive, others another.
  34.  
  35. There's GOT to be a reason to choose one frame of reference over another.
  36. (If there isn't, then you've got to admit vi is at least as right as
  37. emacs.)
  38. [The above GOT is meant to express my personal frustration, not a logical
  39. necessity...]
  40.  
  41.    Ok, here's a good reason for preferring vi's way over emacs's: when
  42. you're in a scrolled window in a GUI and you click on the down-arrow
  43. in the scrollbar, what happens?  You move down through the document!
  44. The same if you drag the block in the middle of the scrollbar
  45. downward.  Do any of you think this is ambiguous or counter-intuitive?
  46. How about the PageUp/PageDown keys on many keyboards?  How about the
  47. up-arrow key -- what word-processor ever used it in any way to do
  48. what scroll-up does?  Would you expect Shift-UpArrow to move to the
  49. beginning of the document, or the end?
  50.  
  51.    It seems to me that there's a very strong convention of moving
  52. "down" meaning moving to a later part in the text; i.e. the observer
  53. is moving, not the text.
  54.  
  55. Ok, how's this for an "origin of intuition" about this subject.
  56.  
  57.    In our day-to-day experience, when we want to look at a different
  58. part of something, do we more often move relative to that thing, or
  59. move that thing?  I say we move ourselves, or at least move our eyes
  60. (frames of observation) much more often than we move the thing.
  61. Looking through a telescope or binoculars.  Movies, TV.
  62.  
  63.     When reading a book, sure we turn pages, but when reading a page
  64. (and reading a text file in emacs is like reading a single page -- or
  65. many pages attached top-to-bottom) we move our eyes down the page.
  66. Have you ever seen someone stare at one spot (fixed relative to their
  67. head) and move the book upward as they read each page?  Ok, I'm being
  68. a bit silly but on with the point.
  69.  
  70.     The only counter-examples are when we have a piece of
  71. observational equipment that's large and hard to move compared to the
  72. subject, such as a microscope or microfiche reader.  (Please, no
  73. cracks about Emacs's size. ;^) This happens rarely and is
  74. counter-intuitive.  Remember the first time you used one of these
  75. devices?  Didn't you, at first, mistakenly move the slide or
  76. microfiche in the opposite direction from the way you wanted to?  I
  77. know I did... am I crazy?  Of course after a couple of seconds you got
  78. used to it.  But we're talking about what's *intuitive* here.
  79.  
  80.    Obviously, on the surface, when we scroll through a file in emacs,
  81. the graphic depiction of the window is standing still on the monitor
  82. (and visually, the text moves, relative to the monitor).  But that
  83. doesn't mean the window isn't moving; it just means that the window,
  84. the monitor, and the user aren't moving relative to each other.
  85.    On the conceptual level, the text is an object in an abstract space.
  86. It still exists even when we save it in a file and leave emacs,
  87. destroying the window.  The window exists to observe the text; the
  88. text does not exist for the sake of the window.  Moving the text
  89. around in this space doesn't make sense... it's irrelevant.  It has
  90. no effect (going on the assumption that the text exists independent
  91. of the window, and not vice versa.)  Our purpose is not to change the
  92. location of the text; we just want to see different parts of it.
  93.    Consider what happens when we view the same buffer in two different
  94. windows, and we scroll one of them.  The text can't be moving, because
  95. if it were, it would appear to move in both windows.  (Or would you
  96. argue that scroll-up means "Move text and all other windows showing
  97. this buffer up" ??!)  There is one buffer, and one of the windows is
  98. moving relative to it.
  99.  
  100.    Finally -- and this would be the strongest point for any diehard
  101. relativist who's still not convinced that it's the window that's
  102. moving and not the text -- note that other commands for moving around
  103. in the text are named as, well, just that: ways of moving around in
  104. the text, not moving the text around.  It is confusing to make the
  105. names of most commands refer to how the frame moves, but make the
  106. names of a couple of commands refer to how the text moves -- *even if*
  107. the latter paradigm were just as intuitive.
  108.  
  109.    For example, beginning-of-buffer moves the frame to the beginning
  110. of the buffer.  In isearch-forward, you
  111.   "Type ESC to exit, leaving point at location found."
  112. See, the point is moved to a location in the text.  And our frame
  113. follows the point.  forward-char, next-line, forward-word, forward-sexp,
  114. end-of-line, etc. all refer to how the point moves, not to how the text moves.
  115. (The words "up" and "down" are not the issue here -- the issue is whether
  116. it is the text or the frame that is moving.)
  117. Documentation string for set-window-point:
  118. "Make point value in WINDOW be at position POS in WINDOW's buffer."
  119. Not:
  120. "Make point value in WINDOW's buffer be at position POS relative to WINDOW."
  121.  
  122. Why should moving the point be labelled opposite to moving the window?
  123. They're analogous concepts.  The window surrounds the point.  The window
  124. shows a large region of the text; the point indicates a single position
  125. in the text.
  126.    Usually when I hit down-arrow, the cursor goes down a line,
  127. relative to both the text and the monitor.  When the cursor is at the
  128. bottom of the screen and I hit down-arrow, the cursor moves down and --
  129. why should I suddenly switch paradigms and say no, the cursor says still
  130. but the text moves up?
  131.  
  132. In fairness to the writers of emacs, let me quote from the elisp manual:
  133. >    Some people have urged that the opposite convention be used: they
  134. > imagine that the window moves over text that remains in place.  Then
  135. > "down" commands would take you to the end of the buffer.  This view
  136. > is more consistent with the actual relationship between windows and
  137. > the text in the buffer, but it is less like what the user sees.  The
  138. > position of a window on the terminal does not move, and short
  139. > scrolling commands clearly move the text up or down on the screen. 
  140. > We have chosen names that fit the user's point of view.
  141.  
  142. I argue that the user's intuition is not as shallow as how dots are moving
  143. on the screen.  Intuition deals with objects and their relationships,
  144. whether seen or implied.
  145.  
  146. To put it all in perspective...
  147. I'm not obsessed with this issue.  (Really... it's just late at night!)
  148. I'm not lobbying for emacs to be changed.  I'm certainly not claiming
  149. that emacs is inferior -- it's one of my favorite programs of all time.
  150. (And that's why I care.)
  151. I just think that for the sake of intuitiveness and consistency,
  152. the names scroll-up and scroll-down should have been chosen the other
  153. way.
  154. I'm not demanding that you all agree with me either.  But I hope I've
  155. communicated *why* I think there are very definite reasons for preferring
  156. one frame of reference over another.
  157.  
  158. Lars Huttar                          3
  159. huttar@hp750.itg.ti.com      ||   _______           ____      ||
  160. (Opinions herein are not     ||:  |  |  |   |   |   |  |   | :||  Mars
  161. necessarily those of TI.)    ||  _| _| _|  _|  _|  _| _|  _|  ||
  162.