Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!brian
From: brian@ut-sally.UUCP (Brian H. Powell)
Newsgroups: comp.sys.mac
Subject: Anchor points and Arrow keys
Message-ID: <8481@ut-sally.UUCP>
Date: Tue, 14-Jul-87 16:18:43 EDT
Article-I.D.: ut-sally.8481
Posted: Tue Jul 14 16:18:43 1987
Date-Received: Thu, 16-Jul-87 06:48:43 EDT
Organization: U. Texas CS Dept., Austin, Texas
Lines: 59
Keywords: TextEdit selection ranges


     I'm trying to implement shift-arrow and cmd-shift-arrow (and probably
eventually option-shift-arrow) keys in a TextEdit window.  The details of how
these guys act are discussed in the User Interface chapter of IM-IV.  I'm
concerned about how to determine where the Anchor point is.  What would be
best is if the TE record had a field for it, but it doesn't.
     In case you don't see what the problem is, let me discuss it.  Suppose
the user uses the mouse to select a range of text sweeping the mouse from the
start of the selection to the end.  How does one know that the selStart field
(of the TE record) is the anchor point and the selEnd field is the active end?
Actually, one doesn't, and that's the problem.
     One solution (the "ideal" solution?) is to act like this:  (let the
carets beneath the line delimit the selection range)

	We start with a line with a selection made by the mouse:

Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner
		 ^		^

	and after a cmd-shift-left-arrow:

Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner
^				^

	and after a cmd-shift-right-arrow:

Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner
		 ^		^

	and after another cmd-shift-right-arrow:

Anton Nel, recent winner of the prestigious Naumburg Prize, and David Renner
		 ^							    ^

     In other words, it leaves the original selection there and works around
it.  Any comments?  This seems like the nice thing to do in this situation.

     Now about implementation...  I'm slowly resigning myself to the fact that
I'm going to have to keep track of the character that preceded the current
character, as well as where the selection range was when we started.  I can
use this information to help me decide how to collapse selections.  As a
pleasant side-effect, I can now implement the up & down arrows correctly (as
opposed to the way the 128K ROM TextEdit does it) where successive up/down
arrow movements stay as close as possible to the original cursor position.
(See IM-IV User Interface for that rule.)
     Any comments on this?

     Thanks for any assistance.

Brian H. Powell
		UUCP:	{ihnp4,seismo,ctvax}!ut-sally!brian
		ARPA:	brian@sally.UTEXAS.EDU

   _Work_					 _Not Work_
  Department of Computer Sciences		P.O. Box 5899
  Taylor Hall 2.124				Austin, TX 78763-5899
  The University of Texas at Austin		(512) 346-0835
  Austin, TX 78712-1188
  (512) 471-9536