Created attachment 111920 [details] screenshot of kate with wrapped lines, the scrollbar preview and the mini map If word wrap is enabled the preview and the mini map still display the unwrapped version, this also results in a miscalculation of the mini map sliding window. See attached screenshot.
True, the text preview should use the same visual word wrap if dynamic word wrap is enabled. The layout cache should support this already.
Btw, the minimap is a representation also of how the scrollbar works. The scrollbar always scrolls by real lines, never by dynamically wrapped lines. Also, the minimap is just there to give the user a hint about the document contents, so I don't think the scrollbar contents needs to be wrapped (in fact, it would be wrong because of the real-line scrolling). So the minimpa-part is a wont-fix.
We just discussed that again: The text preview does not have the same width as the text view itself anyways, so proportions do not match. Dynamically wrapping lines may be more confusing than helping here. For now, this is a wont-fix. Maybe we will reconsider in the future. Or you provide a patch so we can try this out. :-)
I am reopening this bug, because I think this is wrong from a usability POV for the following reasons: 1) The scrollbar preview should at least show the correct region of the text, that is shown in the window. However, if the wrapping is not displayed in the preview, the region is to large (see screenshot). Changing the preview window height would be even more confusing during scrolling. 2) Even if the scroll behavior is "by line" one should consider changing this. For very long lines (that are longer the the complete kate window) it is otherwise impossible to display the whole line with word wrap enabled! The scroll behavior was changed recently in Bug 256561 for wheel and touchpad scrolling. Thus, the preview does not match this scrolling behavior anymore. How do you display "wrapped line scrolls" in this case? In the bug it is also mentioned, that it was already possible before this change to scroll by a wrapped line with the shortcut ctrl+up/down. 3) Its just confusing to have two different representations of the same text. As one is unable to actually read the text is the preview, one actually depends on the line length representation for orientation, i.e., the visual outer hull of the text. If this is different from the preview, the preview is nearly useless.
1) To me the displayed region looks correct. 2) The first part of this paragraph I don't understand, sorry. The second part is inaccurate, since the change only applies to wheel scrolling; the scrollbar still scrolls by real lines, and this will most probably never change. You'd otherwise need to layout all the lines when opening a document, which you do not want to do. 3) For the same reason, it IMO is not possible to paint wrapped lines in the scrollbar. It will break the 1:1 correspondence between height and scroll position.
Ok, I can see the point for very long lines as in your screenshot, so I will reopen for now. (May I suggest, though, that you wrap your lines from time to time? It's good practice anyways, especially when having the file version controlled. Then, looking at the diff, not the entire paragraph changed, but only parts of it. But maybe that is not your use case.)
I respect your choice about whether this is fixable. However, I try to explain myself, to avoid misunderstandings. @Sven Brauch: 1) The blue rectangle in the preview is much larger than the displayed "edit area", i.e., the real editor. 2) Consider a line, that is very very long. If it is such long, that it does not fit in the whole edit area, it is impossible to scroll to the end of the line with "per line scrolling" of the scroll bar. Furthermore, a "wrapped line scroll" (e.g., by ctrl+up/down) will not always change the scroll bar position (i.e. the scroll bar is jumpy). That's why I proposed to change that scroll bar behavior as well 3) that's why I suggested to change that scrolling behavior as well (see point 2) @Dominik Haumann: I agree, that very long lines should be avoided. But sometimes you just have files from other people, converted texts from LibreOffice/Word (where one paragraph is represented by a line) or you have scientific content (such as DNA-strings, etc).
Same problem here with KDE Frameworks 5.59.0.
My use case: I paste a long line (many kilobytes) from a software debug log output, then try to scroll it. Because of this bug, I cannot scroll using the scrollbar. I can scroll with PgUp/PgDown or with mouse wheel, but it's slow (max. 30 pages/second). And because the scrollbar preview height is tiny, I cannot see at what percentage I am currently in the file: close to the beginning, or somewhere is the middle of the file, etc. The scrollbar was usable for this particular use case before the scrollbar previous was introduced. Thus it is a regression.
(In reply to Alexander Potashev from comment #9) > Because of this bug, I cannot scroll using the scrollbar. I can scroll with > PgUp/PgDown or with mouse wheel, but it's slow (max. 30 pages/second). And Also, I cannot use PgUp/PgDown if I'm about to check matching brackets: I need to set the text cursor position to a bracket and keep it unchanged, and pressing PgUp/PgDown would break it. In this case the only option is scrolling with mouse wheel, and it's just 3 lines per rotation - very time consuming.