Created attachment 172762 [details] screenshot of break in the middle of operator when there's plenty of space, but > sticks to following character SUMMARY It's nice to have syntax highlighting with colors, but the interpretation needs to go deeper by controlling where lines break in wrapping mode. STEPS TO REPRODUCE For example, look at where Kate breaks something like "myobject->fieldname" for a C/C++ code file. OBSERVED RESULT It sees a breaking point after the hyphen (-) and nowhere else. EXPECTED RESULT It should see breaking points before the hyphen (-) and after the greater-than (>), but not between them, because "->" should be treated as a word that should stay together. I'm attaching two screenshots, each with the same text, but different fonts. The first line is just to show the width of the line. The second shows the bad wrapping behavior. The third line is the same as the second, but with a space between the ">" and the "i", which allows a break where there should be one anyway. The first screenshot is with the default "Hack" font. The second is with the popular JetBrains Mono font, which has a ligature for the operator "->". As you can see, the first half of this ligature gets cut off on the left side.
Created attachment 172763 [details] screenshot with same text, but using font that has "->" ligature
Hmm, we do to prefer to wrap at word boundaries. I don't see that we can have more fine grained control with Qt over this, if that is wanted, one must report that upstream to Qt. Did you alter the options to allow wrapping anywhere? e.g. 'Disregard word boundaries for...'? If yes, one might try to disable that, if not, I don't see that we will work on this.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
(In reply to Christoph Cullmann from comment #2) > Hmm, we do to prefer to wrap at word boundaries. I don't see that we can > have more fine grained control with Qt over this, if that is wanted, one > must report that upstream to Qt. Did you alter the options to allow wrapping > anywhere? e.g. 'Disregard word boundaries for...'? If yes, one might try to > disable that, if not, I don't see that we will work on this. No, I did have the 'Disregard word boundaries for dynamic wrapping' option checked. I guess I don't know enough about the internals of how lines are wrapped. If you think this is something to report upstream, then exactly what type of widget are we dealing with, and what are the options used for its creation? Why I don't think it's something that could be reported upstream is because it's language dependent, and syntax highlighting is a feature of Kate, not Qt, right? When it comes to other methods of determining words and word breaks, I know that Kate has a way of messing with that. For some examples: If you double-click on a "word" it selects the word. Without any special syntax highlighting , a leading # on a word is selected along with the word. But with syntax highlighting for Python, it is not, because the hash just indicates a comment; it is not part of the first word in the comment. Similarly, with syntax highlighting for C, if you double-click #include only the letters "include" are selected, whereas the hash would also be selected without the syntax highlighting. If you press the right or left arrow keys while holding down the Ctrl key, it moves the cursor one "word" at a time. With syntax highlighting of C or Python, the cursor will move over a hash character (#) and any whitespace that follows it in one move. But without any special syntax highlighting, the cursor will (rather oddly) stop between the hash character and any whitespace that follows it. Are you telling me that Kate has control over what constitutes a "word" for double-click selection and for cursor movement but not for wrapping? That just seems odd.
We use QTextLayout to layout that. We can there just choose between https://doc.qt.io/qt-6/qtextoption.html#WrapMode-enum None of that options fit your needs. If you want a additional one, that needs to be added there as an additional enum entry + implemented in Qt. If that has happened one can re-open this bug to let us use it.