- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
May 24 2020
May 23 2020
May 17 2020
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.
May 5 2020
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?
Apr 3 2020
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.
Mar 25 2020
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?
Mar 7 2020
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.
Looks good, thanks! Yes, it's an improvement.
Jan 25 2020
Ok, done ;)
If you want I can integrate these changes and submit your patch, should I? Thanks a lot for your contribution.
Jan 24 2020
I'm sorry, updateView is the wrong function to call, you need updateDirty. I tried it out, like this it works:
Jan 23 2020
Then it seems like the line is not tagged correctly. Maybe try tagLines(note.position.line(), note.position.line())? I think the column being the same is not what the function being called expects.
Jan 22 2020
My guess is right now the view updates when the cursor blinks, so that's why it updates after a short moment (of varying length, though, if you look at the video). Since the line is tagged dirty, it gets repainted correctly, but too late.
Hm, yeah, looking at the code I think you might need to call updateView() in case a focus in or out happened. Can you try if that makes a difference?
Is the video the new behaviour? It still looks a bit weird to me, there is a slight delay between the mouse entering the area and the highlight changing.