https://bugs.kde.org/show_bug.cgi?id=448765

            Bug ID: 448765
           Summary: With a dynamic word wrap and a line long enough to
                    overflow the view, view doesn't scroll when needed
           Product: kate
           Version: Git
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: kwrite-bugs-n...@kde.org
          Reporter: o...@geek.co.il
  Target Milestone: ---

SUMMARY
If a line is so long that with "dynamic word wrap" it fills the window, if the
cursor needs to move to a point on the same line that it outside the current
view window, the view doesn't scroll and the text cursor goes out of the view
and is no longer visible.

I can reproduce this with using the END key or with the find in file function,
but not with the HOME key...

STEPS TO REPRODUCE
1. Open kate and make the window relatively small.
2. Enable "dynamic word wrap"
3. Open a file with at least one line that is long enough to fill the entire
window and overflow it by a bit.
4. Move the text cursor to the beginning of the long line.
5. Press END once, the cursor will move to the end of the current display line
(on the right side of the window at the same height as the beginning of the
line, but not at the "end of line" character).
6. Press END again.

OBSERVED RESULT
The text cursor disappears from the view, the view is otherwise unchanged.

EXPECTED RESULT
The view should scroll so that the real end of the line of text (the location
of the "end of line" character) should move into view and text cursor
positioned at the real end of the line.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 5.24.80
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3

ADDITIONAL INFORMATION
Interestingly enough, the behavior of viewing the end of the line and pressing
HOME twice is fine - the cursor is moved to the real beginning of the text line
and the view is scrolled upwards as expected.

The same behavior can be seen with the "Find in file" functionality: press
CTRL+F and enter text that can only be found towards the end of the line in the
part that isn't visible in the view.

The cursor will disappear and no match will be shown in the view. When manually
scrolling, the found matches can be seen highlighted with the text cursor at
the end of the first match. Even if the first few characters typed in the
search box can be found at the beginning of the line, the view will not
automatically scroll when these first matches are eliminated from the search
due to more text being typed, though the view *will* automatically scroll when
pressing F3.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to