GNOME Bugzilla – Bug 149785
Caret reading by word in Evolution fails to read the first word of a new line when crossing a line boundry
Last modified: 2004-12-22 21:47:04 UTC
1. Launch Evolution 1.4.6 2. Open the Default e-mail message (or some other with blank lines, images, etc.) 3. Run Gnopernicus 4. Make sure Caret navigation is on (F7), and that you have a text caret 5. From the top of the e-mail message, press down arrow repeatedly. 6. When you get to a line with lots of text (e.g. the first line of the default message, starting with "Welcome to Ximian Evolution...", use Ctrl-right-arrow to read by word. 7. Keep going past the last word of the line and onto the next word of the second line. Instead of reading the first word of that new line as it should ("workgroup" in my case), it reads the entire line, as if the user had pressed down-arrow instead of ctrl-right-arrow. Note: this may be related to Evolution bug #62763 - see: http://bugzilla.ximian.com/show_bug.cgi?id=62763 and also to Gnopernicus bug #149784
I am not sure if this is really a bug ... In Gedit, I observe the same behavior. Reading word by word, the first word of a new line is not reported, but the whole new line is reported instead. If the difference between new_offset and old_offset is bigger that 1, gnopernicus does not know if it is a an 'up/down' navigation or a 'word by word' navigation, because the events comming from keys and objects are not time ordered. In such cases, if the old_offset and new_offset are in different lines, the new line is reported else the word is reported.
Alexandra - are you saying that this bug, 149785 is not a bug, or evolution bug #62763 is not a bug, or...? Gedit behaves as Evolution does (behavior described in evolution bug #62763), and I believe a bug is already filed against Gedit for that. I understand Gnopernicus' logic, and that logic is flawed as you note: Gnopernicus is not distinguishing between a by-word that crosses a line boundry and a by-line move. I think Bill has some ideas as to how to do this without sniffing the keystrokes (as should now be do-able with XEvIE). Perhaps he might comment?
I was talking about this bug(# bug 149785), saying that,_in this moment_, from gnopernicus point of view this is not a bug, but a current behavior (gnopernicus has this behavior on all the applications, for every multiline text).
I agree with Alexandra that when moving from one line to another there's no way for gnopernicus to know whether the movement was due to a "next word" or "next line" command; in some cases the text-caret move events will be indistinguishable for the two cases. It may be possible to improve this behavior by extending the gnopernicus logic thus: when gnopernicus is notified that the caret has moved to a new line, gnopernicus can check to see if the caret has moved by only one word or not. In other words, gnopernicus can check the previous & new offsets against the results of a getTextAtOffset(text, WORD,...) call, and in this way, distinguish between "line" navigation and "word" navigation. Note that checking "column" offsets in the previous/new line _won't_ work, because it will fail at the ends of lines of uneven length, and also will fail for proportional fonts. So in order to tell line-by-line movements from word-by-word movements, any gnopernicus logic would have to call getText{At,Before,After?]Offset and compare the word boundaries to the caret movement it just received.
Created attachment 30849 [details] [review] proposed patch Proposed patch to report only the word (and not the entire line) when user navigates word-by-word and caret moves to a new line inside the same paragraph.
This patch fixes also bug #149784. Please test it and let me know if I should apply it and close the two bugs.
It works for me. I tested the patch in evolution and gedit.
Patch applied in CVS.