Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!ucsd!ucbvax!SLC.COM!marcs
From: marcs@SLC.COM (Marc San Soucie)
Newsgroups: comp.windows.x.motif
Subject: Re:  MOTIF 1.1.0 Bug - XmText
Message-ID: <9011161714.AA06984@servio.SLC.COM>
Date: 16 Nov 90 17:14:06 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 35

I wrote:

>   One Line Description:
>
>       'next-page' and 'previous-page' do not move the insertion cursor
>
>   Full Description:
>
>       Using the above actions (via their default bindings to osfPageDown and
>       osfPageUp) in a multi-line text widget with gobs of text, the text in the
>       viewport moves, but the cursor does not. A subsequent cursor motion causes
>       the widget to jump back to the original position of the insertion cursor.

Shap Shapiro wrote:

> Gee, I do not know that I would classify this as a bug. I seem to remember
> that this is the standard behavior on the word processing applications I have
> used on the Mac, and I wouldn't be surprised if the same help for PM on PC's.
> Just because a user is scrolling, is it really the correct thing to do to move
> the insertion cursor to some arbitrary spot? I do not have really strong
> feelings about this, but once I got used to it on the Mac, it seemed like the
> correct behavior.

I can't understand how one could get used to this. If I hit next-page a bunch
of times, and I'm looking at text in the middle of the buffer, how am I
supposed to start editing that text? Am I supposed to reach over, grab the
mouse and click on the spot I want to modify? Phooey! Whether it's Mac-standard
or not, it's unfriendly behaviour. No WP package *I*'ve ever used does this,
and no incarnation of vi or emacs does either. Text widgets are *supposed* to
be keyboard-driven. By definition. By nature. By Divine Law. If I have to be
grabbing at mice just to move around through the text, we're all in trouble.

    Marc San Soucie
    Portland, Oregon
    marcs@slc.com