Subject: Re: patch -- bug 10
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Mon Jan 31 2000 - 21:56:40 CST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 30 Jan 2000, Paul Rohr wrote:
> At 09:04 AM 1/30/00 -0600, Robert Sievers wrote:
> >At 11:43 PM 1/29/00 -0600, sam th wrote:
> >>This VERY trivial change fixes bug 10. I am not entirely sure why someone
> >>would have written the code the way it was, so I may have changed
> >>something important.
>
> I originally wrote the code to do all the keyboard-driven navigation, in
> particular getDocPosFromPoint(). Bob and I never agreed on a spec for the
> behavior he wanted, so I didn't implement anything.
>
> I too haven't looked at Sam's patch, but I suspect it will break more than
> it fixes. Here's why.
>
> The existing EOW logic is used for *at least* two different purposes. One
> is to extend selections forward or backword one word (via Ctrl-right-arrow
> and Ctrl-left-arrow). The other is double clicks.
I think this is one of the major sources of our problem. As far as I can
tell, these two applications take into consideration different ideas about
the end of the word. Thus, the code they use should be seperate.
>
> >The bottom line is that bug #10 treads on some thin ice; trying to
> >anticipate what people want. If I double click then erase, I want to
> >delete the space, and if I double click then underline, I don't. It's a
> >dangerous road to walk down, because doing so results in software that
> >tries to read your mind. Looking back on it, I almost wish I wouldn't have
> >reported the problem in the first place.
>
> IIRC, Bob's bug report was that in some cases he wanted the trailing space
> at the end of a bunch of words to look like it was selected, but to not be
> affected by some editing operations. To my knowledge, nobody has done
> enough reverse-engineering to fully specify the desired behavior in ways
> which minimize other side effects.
>
> >Having said all that, I am anxious to check out the patch after shaw has a
> >chance to look at it and check it in.
>
> Actually, I'd prefer that we *not* include any "mind-reading" patches in
> this area for 0.7.8. OK?
>
> Paul
>
Since this appears contentious, I agree that it should NOT be in 0.7.8.
That said, here is the result of my investigation into this problem:
Here is WordPerfect for Linux's behavior:
On double-click, only the word appears selected. If you double-click on
an area of whitespace, the whitespace, and nothing else is selected. If
you apply formating to the selected to the selected word, only the word is
affected. If you delete the word, the word and the space following it are
deleted. This behavior does not wrap accross line breaks, soft or hard.
WordPerfect also treats tabs differently than spaces. If a tab is in the
midst of spaces or other tabs, and the double-click is on the tab, only
the tab is selected. If a space is double clicked, any whitespace,
including any intervening tabs, are selected.
For ctrl-arrow, the behavior is much simpler. The cursor moves to the
beginning of the next or previous word, or to the end of the file, if
there is no next word. This behavior is the same for tabs, and wraps
across all kind of newlines.
This is what I think Abiwords behavior should be:
We should duplicate most of WP's behavior. However, the differing
behavior on tabs should be avoided. Also, I like having ctrl-right arrow
go to the end of the current word rather than the beginning of the next.
I currently cannot get AbiWord to display reproducible behavior on this
front :-), so if someone could post what we currently do, that would be
appreciated.
sam th
sytobinh@uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4lll6t+kM0Mq9M/wRAsqnAJsFnzskdSO3LvD3OwHsohstl4axjQCfdscX
4vZMvxv7KE5jWb4GUuvI2cI=
=MCJ2
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b25 : Mon Jan 31 2000 - 21:56:37 CST