Hi - this isn't a proposal for a fix, but as a keen user of the preview plug-in, I thought I'd mention my workaround - which is good enough to make it usable, which is what I want to be able to avoid having to switch tools for text creation/editing.

Made some mockups, showing the various colors, some KDE apps can include.

This is the Qt issue similar to the one in KTextEditor:
https://bugreports.qt.io/browse/QTBUG-71489

I just stumbled upon this bug (issue #1) recently and it is quite annoying. I believe this is a bug in Kate, and not in Qt and it triggers with the space character. So, if you are writing a line which hits the border and wraps, it wont have this issue unless the last character before the wrap was a space.

I think the solution we have in current master is ok enough.

This was done in https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/20!

At the moment no idea how to fix that without regressions.

I think we went with the solution in https://phabricator.kde.org/D29789, could we close this?

Oh jeez, I love it.

;=) Actually, I just missed this request, sorry.

Should I understand this is not desired and that I should abandon it?

This is equivalent to: https://invent.kde.org/frameworks/syntax-highlighting/-/merge_requests/1

This is moved to https://invent.kde.org/frameworks/syntax-highlighting/-/merge_requests/2

• Fix extensions and unit tests

I put it all in the README. I also corrected the repository, I had not noticed that this repository was already in GitLab!

• Add collaboration guide in the README file

I think it makes sense to have just "Raku", the world at large (like me) only recognizes Perl 5 as Perl .P

I think this is very good thing to have.
But perhaps we just should add that to the README.md that is prominently shown on e.g. https://invent.kde.org/frameworks/syntax-highlighting
The README anyways already contains a "Adding unit tests for a syntax definition" that could be replaced with this.

Hmm, looks better for me, too.
Let's go with this at the moment.
If it creates issues, we can still revert it again.
Thanks for taking care of this.

Hmm, consider though that a configuration option should be something that gives a choice to the user. It shouldn't be necessary to set a config option in order to make the program behave correctly.

In D29789#672335, @dhaumann wrote:

I like this patch. In fact, I observed over the past years again and again that sometimes, especially if chinese or similar letters are included, the baseline is wrong in Kate, leading to much more overpainting that needed.
If this patch fixes this, then I'm all for it. Or let's put it like this: The current implementation is wrong, this patch looks less wrong than the current state :-)

+1

I like this patch. In fact, I observed over the past years again and again that sometimes, especially if chinese or similar letters are included, the baseline is wrong in Kate, leading to much more overpainting that needed.
If this patch fixes this, then I'm all for it. Or let's put it like this: The current implementation is wrong, this patch looks less wrong than the current state :-)

This is my another try as an alternative solution to D25339. Actually this works surprisingly good IMHO, at least for CJK users for most cases.

Actually I was trying to use this approach in the patch because I was afraid that variable line height may need to estimate the whole document height to make scroll work correctly.

Sure, thanks for the improvement!

Hmm, right, didn't think about that :(
Guess if we want to have this, we need to improve the read/writeConfig functions.

In D27844#671380, @dhaumann wrote:

I suggest to revert, and send a notification with the change to kde-distro-packager@kde.org to avoid that many users break their configuration.

I suggest to revert, and send a notification with the change to kde-distro-packager@kde.org to avoid that many users break their configuration.