Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325806

Summary: SWT StyledText with WordWrap on doLineEnd moves the caret after the line break character
Product: [Eclipse Project] Platform Reporter: Hugo Corbucci <nightao>
Component: SWTAssignee: Scott Kovatch <skovatch>
Status: RESOLVED INVALID QA Contact: Scott Kovatch <skovatch>
Severity: minor    
Priority: P3 CC: eclipse.felipe, skovatch
Version: 4.0   
Target Milestone: ---   
Hardware: Macintosh   
OS: All   
Whiteboard:
Attachments:
Description Flags
Patch to maintain line ends before their breaks in wrapping situations none

Description Hugo Corbucci CLA 2010-09-20 18:19:27 EDT 
Build Identifier: 20100617-1415

When navigating through wrapped text on the StyledText, the behavior of using arrows and the one from moving to the end of the line are not the same.

If the caret is set (through mouse click or arrows) to the end of the wrapped line, hitting right arrow will move it to the position before the first character of the next line.

If the caret is set (through doLineEnd triggers) to the end of the wrapped line, hitting right arrow will move it to the position after the first character.

On the first cast, the caret will be shown before the "space" used as a line break. On the second, it will be shown after that "space".

The natural behavior is to copy the first.

Reproducible: Always

Steps to Reproduce:
1. Use any snippet to create a StyledText with SWT.WRAP.
2. Add a lot of text to create a wrapped line.
3. Move the caret to the start of the logical line (0,0)
4. Hit Cmd+Right Arrow (or whatever triggers the doLineEnd() methods on StyledText)
5. The caret will be after the space character at the end of the wrapped line. Press right arrow and it will jump after the first character.
Comment 1 Hugo Corbucci CLA 2010-09-20 18:33:07 EDT 
Created attachment 179289 [details]
Patch to maintain line ends before their breaks in wrapping situations

Very simple verification that checks whether the visual line is breaking to another visual line or if it is the last one.
If it is not the last one, shows the previous offset as lineEnd.
Comment 2 Scott Kovatch CLA 2010-09-21 19:40:16 EDT 
Thanks for the patch! It looks good to me, but I'll leave it for Felipe to review when he gets back from paternity leave.
Comment 3 Scott Kovatch CLA 2010-10-13 18:47:38 EDT 
Verified this works on Mac and Windows, so I'm checking it in. Thanks for the patch!

Fixed > 20101013.
Comment 4 Felipe Heidrich CLA 2010-10-14 09:22:33 EDT 
I removed the patch, the old behaviour was the correct one. Please use notepad as reference (I also compared to TextEdit, the old behaviour is correct on the Mac too).
Comment 5 Scott Kovatch CLA 2010-10-14 11:40:28 EDT 
(In reply to comment #4)
> I removed the patch, the old behaviour was the correct one. Please use notepad
> as reference (I also compared to TextEdit, the old behaviour is correct on the
> Mac too).

I stand corrected. The new behavior looked good, but you're right, it's not consistent with TextEdit. Sorry about that...
Comment 6 Hugo Corbucci CLA 2010-10-14 11:47:05 EDT 
I agree it is not like TextEdit but it sure feels wrong.
It is a behavior that only triggers on this specific action whereas all other actions trigger the other behavior. Is it not possible that this is just a bug on TextEdit that nobody really cares about?
It looks like, from a usability point of view, going to the end of the line should work like it does when you go to the end of a non-wrapped line.
Unless you consider this is a way to give feedback to the user that this line is wrapped. If that is the case, the feedback is quite weak.

Anyway, I did not knew the policy was to just follow Notepad's behavior. Sorry about that then.
Comment 7 Felipe Heidrich CLA 2010-10-14 12:31:16 EDT 
>Unless you consider this is a way to give feedback to the user that this line
>is wrapped. If that is the case, the feedback is quite weak.

Huh ?
The current behaviour is consistent with the native behaviour on Windows and Mac. 
That *is* the best feedback possible IMO, it means StyledText is behaving the way (the majority of) users expect. If this is really a problem for your application I can help to write code to override it in your app.


> Anyway, I did not knew the policy was to just follow Notepad's behavior. 

Not always, but when it goes to cursor navigation on windows Notepad is a good references (it is native text editor).
Comment 8 Hugo Corbucci CLA 2010-10-14 12:49:00 EDT 
OK. Can't really think of any better way to provide this kind of feedback.

It is just in our case, it is useless to provide such feedback because the user only uses a wrapped styled text so he pretty much knows lines are wrapped thanks to other factors.

We already have that patch applied in our app so we are fine about it. It just felt like something to be contributed back. Sorry it was not.

Thanks for the clarifications.