Ok, I see, there is an extra request for the new hl test file.
Then let's approve this one.

Done!

Fix the blank text issue by alway setLineWidth.

Clean up the code a little bit and adding comments. Also fix a small bug if m_fontHeight has
big difference with m_fontMetrics's height.

In D25339#651701, @cullmann wrote:

Hmm, after applying this patch, for me, no text is visible at all.
By selecting a bit stuff, one at least sees an outline (CMakeLists.txt of ktexteditor toplevel dir).

In D25339#651701, @cullmann wrote:

Hmm, after applying this patch, for me, no text is visible at all.
By selecting a bit stuff, one at least sees an outline (CMakeLists.txt of ktexteditor toplevel dir).

Hmm, after applying this patch, for me, no text is visible at all.
By selecting a bit stuff, one at least sees an outline (CMakeLists.txt of ktexteditor toplevel dir).

I appreciate work on this issue.
I am not sure about how well this "hack" will solve the issue, thought.
I will give it a try here in any case.

+1, looks great.

Add a screenshot to demostrate the change.

Fix the handling when layout formats has background.

In D25339#563937, @cullmann wrote:

Actually, I could live with:

1. All lines are a bit higher, for me that makes reading even easier. But the rendering shall have no glitches.
2. Some lines have different heights. But I assume this is hard to implement at the moment.

handle the range with multiple lines.

Try to fill the gap if we increase the line height with representitive char.

See https://phabricator.kde.org/D28870

There is a more recent version of that file. How to proceed? By creating a new review request for that file with a diff? Or is there a way to associate it with this review request?

Thanks ;=) Even with test.

Change looks reasonable, but could that testfile be added to our autotests directory? (or the file we have there extended)
The current auto test file is autotests/input/highlight.lgt I assume.

Yes, please push, thanks!

When it comes to Zoom, I would only expect it adapts to Global zoom settings again only once if I have reset my manual zooming to Default again.

This feature is already implemented in kwrite. The default undo/redo shortcuts in Kate are Ctrl+E / Ctrl+Shift+E.

Patches naturally get more attention than feature requests in bug reports, because even if in the feature request everyone agrees it's a nice idea you still have to find somebody to actually do it -- which is often not the case ;) and then it's just wasted time to discuss it in the first place.

• "There is already a way to do this on KTextEditor". The existing code seems to update the position stack only after editing a document but I will give it a try, thanks . It is a feature I needed for a long time and according to the Bug 409940, I'm not the only one, I just never took the time to dig into it. The "delete" and "page end" keys are too close on my keyboard...

Thanks for the fix + regression test!

Cool +1 ;=)
Thanks for the contribution.
We use that at company, nice to have.

The 10 line limit also seems kind of arbitrary to me. KDevelop has a similar navigation feature and navigates by "contexts". A similar concept exists in KTextEditor in terms of the folding ranges; maybe that could be used to classify "meaningful" cursor moves to navigate between?

I am currently not convinced for several reasons:

1. There is already a way to do this on KTextEditor level, see: https://github.com/KDE/ktexteditor/blob/master/src/document/katedocument.h#L406
2. I believe this should be a plugin, since the current implementation makes the current code more complex, and it's a feature we have not needed for > 15 years.

Thanks for the feedback, I managed to reproduce this using "go to definition" and will investigate.
I only tried to manage long jumps (page end, mouse click, etc.): pressing 77 times the up arrow was not meant to add any item to the undo stack but reading the code, I realized that it actually adds 7 items of 11 lines jumps. This is probably not what we want.
It is possible to discard small jumps by comparing the new position to the last *view* position instead of the last *undo stack* position. Any suggestion ?

Interesting idea. I don't know if I've ever used another editor with this feature, but I thought I ought to give it a try before judging. However I'm not able to get it working consistently. Sometimes moving the cursor more than 10 lines adds an item to the undo stack, sometimes it doesn't.

Ok ;=)

True, guess I copied too large parts during my fix-up of this.

First let's have this, the current state is bad ;=)

Thanks yes, maybe you can add a comment to the skipOffset, Christoph :)

Let me try to explain the skip offset idea (it's been years since I came up with this in GeSHi :) )

I guess this is OK, but the concept of a "skip offset" is a bit fuzzy to me.

For the example from the bug this makes the difference between ~30 seconds on a 4 Ghz machine to << 1 second ;=)

Better, but VHDL hl is still very slow, need to take a deeper look into it :/

Yes, I will fix the issues and then commit this as one thingy.
Thanks for taking a look :=)
My colleague was very unhappy with the VHDL performance :P
The highlighting shouldn't take as long as a hardware simulator.

I guess in a followup commit the reported issues will be fixed? :-)

remove useless output of stray azOffset var

Zoom is like all view stuff local, yes, I assume that is often not wanted.
But that is a orthogonal issue.
The same could be said for "dynamic word wrap", very seldom you want to set that for one view.
On the other side, for the global config, one has the settings dialog, same for "zoom", aka font size.

And btw., thanks a lot for taking care!
The vimode for sure has more need for love, if you have time ;=)

I think, one issue is, that <down> and <up> don't work that way in the test framework.
I reformulated the test with \down and \up and moved the asserts to verifies.
This works for me, will push this, please take a look if that is ok for you, too.

Yes, my case.

I will try to take a look as soon as I have time, if nobody else is faster.
Just to confirm: Your newly added test case doesn't pass or some other test case randomly fails?

I added a unit test, but I do not know why it is failing. Actually I do not know if I've added it correctly at all. Help is very necsasary.

• Add unit-test

The intimidating one :)

I am not sure where I should add it. Is it supposed to be a new pair of bug418486 .h/.cpp files? Or should the test reside inside keys.cpp in big intimidating 500 line wide MappingTest function?

Thanks!

Almost good, please fix + ship.

I like the patch, but please add a unit test before we commit this. See https://github.com/KDE/ktexteditor/tree/master/autotests/src/vimode
Could you add one? :)

I guess we can give this a try. As I understand, though, with this patch you will never be able to use e.g. a global zoom once you change the zoom of a view. This was different before this patch.

In case my last comment was mistakable, I fixed this:

1. Create a document with just one long line that wraps over two printed pages. I this case, I am not able to print only the selected text properly.

Hmm, yes, seems to work again.
Let's close this then again.

Seems in https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5.12/314/ the test passed again?

Highlight the {{bbox}} Overpass Turbo placeholder.

In D27912#623891, @brauch wrote:

I also don't understand this. Even if the painting somehow changes, e.g. because some painter state is set which wasnt set before (which I do not see to be the case here), that should not affect the line layout, as that is computed separately.

Very strange.

I also don't understand this. Even if the painting somehow changes, e.g. because some painter state is set which wasnt set before (which I do not see to be the case here), that should not affect the line layout, as that is computed separately.

FAIL!  : InlineNoteTest::testInlineNote() Compared values are not the same
Actual   (newCoordCol04): QPoint(51,1)
Expected (coordCol04)   : QPoint(33,1)

I have node idea why the test would be failing. It complains that a coordinateToCursor changed. My idea what could cause this that an inlineNote is inserted at not the exprected place so column 4 shifts to the right. However the change in the painting order shouldn't cause this as far as I understand it. To make matters worse the test passes for me locally. I would need help here to invesitagte or I would revert this for the moment.

In D27912#623871, @cullmann wrote:

Hi, could it be that killed the inline notes autotest?

https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5.12/313/

Hi, could it be that killed the inline notes autotest?

Thanks for working on this.
Badly scaled stuff is a real eyesore...