Project

General

Profile

Bug #9452

EDITOR: incorrect last space in line behavior

Added by Vladimir Tsichevski over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

editor.p Magnifier (859 Bytes) Vladimir Tsichevski, 12/11/2024 01:10 PM

9452.png (3.71 KB) Vladimir Tsichevski, 12/11/2024 01:13 PM

9452-FWD.png (5 KB) Vladimir Tsichevski, 12/11/2024 01:17 PM

History

#1 Updated by Vladimir Tsichevski over 1 year ago

The test example editor.p.

The text wrapped, so jumps over is at one line, and a lazy dog. at the next.
Set caret after the r in the jumps over, as shown here:

press Right.

In OE, there is no space after r visible, so the caret moves to the beginning of the next line.
In FWD there is a space at the end of the line, so the caret moves right, as shown here:

This holds for the last space character in a line, which fills the editor completely horizontally.
If we delete this space and insert it back, the caret is positioned after the space, so the space becomes visible, but it "disappears" again after we move the caret.

The SCREEN-VALUE contains the space as expected.

This feature is quite strange, and needs to be explained. Shall we implement this?

#2 Updated by Vladimir Tsichevski over 1 year ago

Additionally, in FWD, the caret can move out from the view on the right and get thus invisible.

This can be demonstrated with the uast/demo/demo_widgets.p, where a variable width font is used for editor.

The issue is the same both for WEB and Swing.

#3 Updated by Greg Shah over 1 year ago

The behavior in #9451-1 would not be a priority unless a customer explains how this is a user problem. So, for now we will not implement it.

in FWD, the caret can move out from the view on the right and get thus invisible

This is a real issue and should be fixed but not necessarily right now.

#4 Updated by Vladimir Tsichevski over 1 year ago

Greg Shah wrote:

The behavior in #9451-1 would not be a priority unless a customer explains how this is a user problem. So, for now we will not implement it.

I found that the problem is really a bit more serious. This happen for every wrapped line: the single space between the two words at the wrap point does not exist from the user point of view.

And now this got quite explainable.

Also, in FWD, the extra space can make the line wider than the editor, and the contents can scroll event if WORD-WRAP is FALSE, which is not expected.

#5 Updated by Vladimir Tsichevski over 1 year ago

Vladimir Tsichevski wrote:

And now this got quite explainable.

The editor model looks simpler now: every visible line break consumes exactly one original text character: either a space or a newline character.

Also available in: Atom PDF