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.

Seems this change has some sideeffects I did not experience when I played with this, but which are now uncovering as it hits people usinjg KF 5.70 :
config seems to write any settings, also the ones inherited from global defaults, as view-specific settings, and when reading them in again on session restart, they all become view-specific overrides, thus no longer influencable by global settings. Is that due to some other change elsewhere, or did I just completely miss this?

@cullmann could you integrate this?

Good catch :) please commit

Thanks for the patch! I had not noticed the problem before :)

Ah right, that's still here.

What about ktexteditor?

Kate patches are at https://invent.kde.org/kde/kate/-/merge_requests, BTW.

In D25339#666832, @cullmann wrote:

Looking at the code, might it make more sense to just move away from the fixed height we have?

I assume the lineHeight usages in the renderer are easy to replace with the proper "height()" of the individual lines of the layout.

see e.g. here for a start of using the right heights inside the renderer.

In D25339#666877, @rjvbb wrote:

Looking at the code, might it make more sense to just move away from the fixed height we have?
It isn't used that often and in most cases one could just query the height of the current line.

I'd be all for that, provided it doesn't introduce any regressions in the rendered result nor in rendering time.

It could be trickier to implement than you think though?

Looking at the code, might it make more sense to just move away from the fixed height we have?
It isn't used that often and in most cases one could just query the height of the current line.

Same here ;=) Thanks a lot for the work on all this issues!

Looks fine for me, thanks for improvement!

Looking at the code, might it make more sense to just move away from the fixed height we have?
It isn't used that often and in most cases one could just query the height of the current line.
That would solve this issue without needing any hacks for the rendering I think.

the code can be smart

In D25339#665827, @xuetianweng wrote:

[...]

As for higher line, it might not as bad as you thought as it actually might improve readability for many people.

I agree with this statement :). Thanks to this diff I found out where the line height can be manipulated; the way the code computed it, fontHeight was 34 (IIRC), I've hardcoded it to 40 and I very much prefer reading text that way.

In D25339#665432, @rjvbb wrote:

With "we've ever seen" you do mean that lineheight only changes when a line that requires it scrolls into view?

Though line height won't shrink during the edit phase, it will back to the actual value upon save.

Have you tried to reset the max. lineheight on each redraw (I presume the scrollbars could give you a signal that a view scroll/jump was initiated, if need be).
Something tells me that it'd be nicer if lineheight always is as small as possible. Imagine you're using a smallish window to edit a document that just has some of these "offending", much higher characters at the bottom. If it gets into view only once, lineheight increases and it's as if you lose a lot of screen estate until you save the document. Now I mustn't be the only one who often doesn't save for a while, esp. when doing things like moving blocks of text around, and it's exactly in that kind of scenario where having to save to get a more space-efficient rendering back can be very annoying.

As long as you can determine the max. lineheight required for the view that's about to be drawn before the view is actually drawn there should be no glitches. You'd just see a jump in lineheight and there would probably be an interesting problem to tackle with edge cases where the higher glyphs fall outside the view area because of the increased lineheight, but that's something your current implementation cannot avoid completely either. As to the changing lineheight: I think users will understand why it happens and get used to it. It's comparable to what you see in graphics programmes that show cursor co-ordinates next to the cursor; that indicator has to jump when it would get "pushed out" of the view, and that doesn't even feel weird.

I presume your new approach would work not just for CJK characters, but also for anything else that changes the lineheight. That's and advantage but could also lead to regressions for some (who never use CJK characters or who, like me, wouldn't care how they display because they can't read them anyway). Emoticons come to mind; here too I don't really care if they get cut off. Scrap that, I *really* don't care if they are...

This new version does not cause a lineheight regression for me (after backporting it to 5.60.0). However, contrary to what I thought it does not react to emoji

With "we've ever seen" you do mean that lineheight only changes when a line that requires it scrolls into view?

I'm not sure if this is the right way to do it or it might cause any glitch, but here we go. Upon line rendering, update the maximum height we've ever seen.

Use actual line height instead of representitive character.

In D25339#665351, @xuetianweng wrote:

... or you could give me some hint on that?

Too bad I can't; it's been no more than a month since I began my study into KDE applications. I'd love to test out if someone provides a genius solution, though.

In D25339#663915, @fakefred wrote:

I second the as-an-option proposal. Hey, why not automatically increase the line height when CJK characters are detected?

In D25339#663915, @fakefred wrote:

I second the as-an-option proposal. Hey, why not automatically increase the line height when CJK characters are detected?

I second the as-an-option proposal. Hey, why not automatically increase the line height when CJK characters are detected?

In D25339#663833, @rjvbb wrote:

doesn't it give you US-ASCII canonical representations of every possible glyph?

Yes, but look at the traditional meaning of a text editor, which typically means "plain text" editor. KTextEditor's design decision to use a single lineheight puts it squarely in that domain - to reply in style: It's "TKextEditor", not "KRichTextEditor" (and even less "KWordProcessor") ...

I'm starting to think that we need an option for enabling/disabling this change/feature. I would not want to have the extra space between the lines, but at the same time I can see that actually not seeing the whole character is not an acceptable situation...

In D25339#663322, @rjvbb wrote:

but that's hardly the domain of application for a text editing framework.

In D25339#663462, @rjvbb wrote:

This patch is only needed when mixing a main Latin1 (like) alphanumeric font with occasional glyphs from a font that have a different, taller height?

This patch is only needed when mixing a main Latin1 (like) alphanumeric font with occasional glyphs from a font that have a different, taller height?

In D25339#563370, @xuetianweng wrote:

And what I'd like to point is, for CJK users, it is uncommon for them to select a single font to cover all the characters, because such fonts are really rare. People usually select one latin only font and just let system (fontconfig) select the fallback for them.

I can't speak for the special cases where this change would improve matters, but for me it introduces a clear regression (waste of vertical space: 12 lines less) in a basic ascii code editing context. Font used is Ubuntu Mono 10pt.

So I tested this, great improvements regarding line height can be seen:

I tried the current version.
For me this looks OK now.
Thought I would like to have more people trying this out before we merge.
Some volunteers?