- 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.
Jul 21 2019
In D22595#499060, @dhaumann wrote:They have some more sophisticated tooltip that may be of interest in case the tooltip is not nice/good enough over time.
Jul 17 2019
LGTM, thank you!
Jul 16 2019
Also here, looks good to me, but I would wait for feedback from somebody else in addition. Thank you for working on this!
Independent of anything else I think this is a very sensible change, and seems like an oversight / bug.
I'm not sure if this solves the right problem.
Jun 10 2019
Why did you replace the registry query by a fixed path?
May 30 2019
Great to have this fixed, thank you!
Apr 26 2019
I guess the intention of the highlight delay is that when you move your mouse across the border, the view doesn't flicker. The 150ms does this well enough for me, I never see a flicker at least ;)