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

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

Ok, happy with that, thanks!

Changed config key to dynamic-word-wrap-anywhere as suggested by @cullmann .

Hmm, not sure.
Given we have everywhere at the moment the dynamic/static word wrap wording, I would rather stick with that.

In D27238#609494, @cullmann wrote:

I am ok with this.
Thought I would like to have a more consistent name for the config key.
We have already "dynamic-word-wrap", I would like "dynamic-word-wrap-anywhere" better than the abbreviated "dyn-wrap-anywhere"

I am ok with this.
Thought I would like to have a more consistent name for the config key.
We have already "dynamic-word-wrap", I would like "dynamic-word-wrap-anywhere" better than the abbreviated "dyn-wrap-anywhere"

A complementary (also related to dynamic wrapping) change is tracked under D27285.

I think this patch looks good.

Ok with this... Thanks. A note " Since 5.6x would be nice".

In D26321#585381, @cullmann wrote:

I am ok with this , but in the long run, we want to change the behavior of the view's config interface to just dispatch to the internal config interface like for the document.
You missed to add the line-count to KTextEditor::ViewPrivate::configKeys()

Add "line-count" to KTextEditor::ViewPrivate::configKeys()

I am ok with this , but in the long run, we want to change the behavior of the view's config interface to just dispatch to the internal config interface like for the document.
You missed to add the line-count to KTextEditor::ViewPrivate::configKeys()

D24245 - support for passing Unix file descriptors in KAuth.

Wouldn't it be better to avoid creation of a temporary file by opening an original file for writing in the helper and passing the file descriptor back to the main process?

Given the big KDevelop & Kate share plugins stuff never took off, I think we shall keep them just in kate.git, this will allow to do even more "experimental" stuff in the future like having some extra interfaces for Kate specific stuff that doesn't need to keep BC.

Given we use setAttribute(Qt::WA_StaticContents); I think using this additional attribute is fine.

According to the documentation they should both achieve the same effect. However, Qt::WA_OpaquePaintEvent takes precedence if both are used.

Looks good. Still, can the same be achieved with setAutoFillBackground(false)?

KateIconBorder::paintBorder seems to take care to paint the complete background,

Hmm, I thought one can enable that safely, if the widget paintEvent paints the full background anyways itself.
I think that should be ok for the iconborder but must take a look myself again ;=)

In T11064#188214, @dhaumann wrote:

I second Christoph's comment.

The idea for Themes is as follows:

• themes provided by the installation are read-only
• If you want to create a new theme, you copy an existing one and give it a unique new name

I second Christoph's comment.

Actually, before one starts to touch this for such things, I would like to have the KTextEditor stuff ported to use the "themes" as provided by KSyntaxHighlighting.

We close this in favor of the other patches.

@loh.tar The line edit in the search bar was once used before the floating message widgets in the view even existed. I guess it's legacy and possibly can be removed?

You don't mean the widget through which you enter the pattern to search on I hope?

@loh.tar The line edit in the search bar was once used before the floating message widgets in the view even existed. I guess it's legacy and possibly can be removed?

@neundorf With this we are back to where we came from. Interesting to see how history repeats, and repeats, and repeats... Accepting this change means a wont-fix to your wish to move it to the center.

I quote myself from D19367 TEST PLAN Potential TODOs:

I'm in favor of this. Ever since the message was moved to the middle of the screen, it's annoyed me by covering up the search result itself. If the bottom-right corner is considered too hidden, maybe it should be horizontally centered, and moved up 50 pixels or so from the bottom of the view? But anything's better than covering up the found matches. :)

In T10480#176816, @nicolasfella wrote:

This sounds like an excellent topic for the upcoming privacy sprint (T8622). @mgerstner any chance you can attend it?

This sounds like an excellent topic for the upcoming privacy sprint (T8622). @mgerstner any chance you can attend it?

Then I will apply this.

I'm in favor!

Well, giving it a try and merge should be postponed ubtil tomorrow: dfaure tags today, so we would then have 1 month of internal testing.

Should we give this some try and merge it?

@brauch, @kfunk what do you say?

can you please rephrase the title of this review to make it understandable?

can you please rephrase the title of this review to make it understandable? "Remove all" - what do you remove? All what?

Change to a single setter for match_cs and exact_match_cs to avoid restriction on call order of functions

Your perception is clear, we have always some result to navigate in, make sense.

In T10279#173063, @loh.tar wrote:

But I'm not sure if "navigate up/down/left/right" in some list should be done by a shortcut where you jump "free" in some text like in Kate or a Web-Browser.

What do you think of the described idea to have a universal "next match" feature and shortcut?

In D17443#392442, @loh.tar wrote:

Um, can't find here a hint that this is try to follow some "defined standard", like CUA. https://en.wikipedia.org/wiki/IBM_Common_User_Access

"...all major Unix GUI environments/toolkits, whether or not based on the X 
Window System, have featured varying levels of CUA compatibility.." 
"The current major environments, GNOME and KDE, also feature extensive CUA 
compatibility..."

Web-search list some KDE docs for Krusader or Gwenview but so far no "master page".

Particularly I ask me why the S&R plugin should use own shortcuts when there is F3/Shift-F3 already defined (at least here and there listed as Standard) I would prefer that the default short cuts always works, independent what was the initial search tool.

But probably I once again misunderstood something :-)

In D17932#392060, @thomassc wrote:

Thanks for reviewing. Regarding the question about which models would have an insensitive exact match, and which ones have sensitive exact matches:

• An example for case-insensitive exact matches might be plain text, or a hypothetical case-insensitive programming language. For example for plain text, one might want to treat words like "Question" and "question" as exact matches, which will make the completion widget close itself when it shows one of them and the user types the other. This is the current behavior for the word completion in KWrite / Kate.
• An example for case-sensitive exact matches would be a case-sensitive programming language like C++. If the user typed "m_var" but the variable is actually called "m_Var", then the completion widget should not hide itself, since it might still be useful to replace the typed text with the completion item that has different case.

Update according to Milian's comments

Thanks for reviewing. Regarding the question about which models would have an insensitive exact match, and which ones have sensitive exact matches:

Hey there, sorry for the long delay. In general, I think your suggestions are very sane - most notably preferring exact case matches over fuzzy matches is a good thing to have!

Perhaps some KDevelop people have feedback, given they use that mostly ;=)

Try to be smart