Number: 427

Date: 31-Mar-84 15':29':29

Submitter: Sannella.PA


Subject: Selecting w/ CNTR key can cause strange behavior

Lisp Version: 

Description: '
Date': 24 Mar 84 13':08 PST'
Subject': TEdit': Selection problems'
To': TEditSupport'
cc': 3LispSupport↑,'
TEdit-System-Date':  1-Mar-84 13':54':34'
Lisp-System-Date':  1-Mar-84 14':24':22'
Machine-Type': Dorado'
As well as the strange (and improper) selection behaviour that comes from holding the right mouse button down and moving the mouse around a bunch (which Greg and I talked about yesterday), I have encountered the following':'
1. Putting down the control key, in the midst of extending a selection (i.e., while the right button is down), which out to have no visible effect, but which should prepare you to delete the current selection, in fact sometimes changes the selection quite radically, usually changing its boundaries in some striking way.  '
2. Playing with the above tends to lead to': multi-piece selections (i.e., more than one continuous region blacked out on the  screen); occurences of "non-numeric arg" errors; and cases where the display doesn''t correspond to the underlying text anymore (so that a redisplay changes what is seen substantially -- if you don''t do so, you can trash the file).'
As well as these bugs, there is currently an incompleteness regarding the interaction between the control and mouse selection.  I take it the algorithm for selection is meant to be the following (I suppose I would argue for it, if it is not the intended one).  I will try to use the terminology used in, but with a simpler notion of selection.  Note that the following doesn''t delete with shift-selection, or with cursor positioning; the real algorithm must of course be much more complex than this.'
a. Let {i1, i2} delimit regions of text, where the i''s are the positions of the initial and final character in that selection.  Let k range over selection kinds (we currently support character, word, line, and paragraph types).  Let x always be the position of the character underneath the mouse pointer.  And let D be a flag, 0 or 1, which we will set depending on the state of the CTRL key.'
b. Describe the appropriate mouse behaviour in terms of two selections': "temporary" and "current", called TS and CS, respectively. '
c. When the left or middle button is depressed, let TS be {i1, i2, k, p}, where the i''s delimit the region of the character (or word or line or paragraph) pointed at, k is the appropriate kind, and p (point) is right or left, depending on whether x is nearer the right or left end of the object type (the "cursor" is presumaby moved to the p end of that object).  As the mouse moves around, TS is adjusted accordingly (underlining if D = 0, reverse video if D = 1 [see (h)]).  '
d. When the left or middle button is released, CS is made to be TS; plus see (i).'
e. When the right button is depressed, TS is defined as follows':   If CS = {c1, c2, k, p}, let z = (c1 + c2)/2. If k = character, define TS = {x, c2, k, left} if k < z, and {c1, x, k, right} if k > z.  If k is something else, then substitute the right hand end of the object under x for x if x > z, and the left hand end if x < z.'
f. As the mouse moves around with the right button depressed, adjust TS as appropriate': if p is left, and if x grows > c2, then let TS = {c2'', x, k, right}, where c2'' is the left end of the object of type k whose right end was c2; similarly, if p is right, and if x becomes < c1, then let TS = {x, c1'', k, left}, where c1'' is the right end of the object of type k whose left end was c1.'
g. When the right button is released, define CS to be TS [just like (d)]; plus see (i).'
h. If, at any point, CTRL is depressed when a button is depressed (independent of which was depressed first), set D = 1.  If CTRL is released when a button is depressed, set D = 0.'
i. When buttons are released, if D = 1, then set up a process to watch the control key, and when it is released, delete CS.'
I think this is what one would naturally expect.  Note that (f) has the consequence that in one "push" of the right button (no matter how much it is then moved around), you can modify the current selection considerably, but must always retain a minimum of one object from what the current selection before the button was depressed.  To be more drastic you have to let go of the right button and use it again.  This accords with standard practice on the first use of the right button; seems it might as well always apply.'
So.  The current behaviour is radically different from that spec''ed in (f), as discussed with Greg yesterday.   It is even different if you select a word, push the right button down without moving the mouse, move one word to the right and back again.  Once you cross line boundaries, it gets quite spectacular.'
Also, just pushing down control, as noted above, changes the TS (and then the CS).'
Also, if you want to delete a region that is already selected (a CS), you currently have to use the right button first, and then push control (and then let up on the right button, and then let up on control).  I.e., if you push down control before pushing down the right button, nothing happens at all, which is an unnecessary restriction.  Under (h), the order of the first two of these shouldn''t matter.  '
Hope this is helpful!  If you would argue for a different algorithm I would be interested in discussing it.'


Test Case: 



Attn: sybalsky, nuyens

Assigned To: 



System: Text

Subsystem: TEdit



Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 


Frequency: Everytime

Impact: Annoying

Priority: Perhaps

Status: Open

Problem Type: Design - UI

Source Files: