The change was submitted in the original pull request

Sorry for late answer...

I guess there was some kind of arcanist mistake when this became a separate review request and not an update to D21024 (Rudimentary xml/html parser for symbolviewer plugin)

Good addition :)

This is not an issue on Windows (yet?) as the whole konsole plugin is disabled on Windows.

That particular class is yours :)

My name does not need to be in there since I have not touched that file yet ;)

I do not have strong opinion about the with of the line, it just hit me that it might become a bit narrow...

So to get nice icons on buttons we need to "setAttribute(Qt::AA_UseHighDpiPixmaps);", but that blurs the previews -> devicePixelRatioF() for preview images.

Please fix the copyright owner and date of the files before committing.

Same ignorant question here as for libksane... Why do we need the HighDpiPixmaps in skanlite? The images get the dpi settings from the scanner setting...

Now I must show my ignorance... why do we need this devicePixelRatio in ksanevewer/selectionitem?

Sorry, I thought i had answered, but I had forgotten to do it.

Yes I also have a memory that there was a bug report about it, but I can't find it now....

This differential does three things

This is a good improvement idea for libksane. :)

In D18966#414955, @trufanov wrote:

Kåre, could you comment my reply?: https://phabricator.kde.org/D18966#411134

The idea is sane :)

Can you also return false in setOptVal() in case the scanning is ongoing? (and the corresponding note in the doxygen comments)

The idea is good. Could we have setOptVals() return -1 and setOptVal() false if the scanning is ongoing and the delayed setting of the value implemented in Skanlite?

OK this can go in.

Just these minor adjustments and we are there.

Sorry, busy month... new project at work and got a new computer to configure....

I think the selection if we save through the PNG 16bit/color or QImage version should be done in Skanlite.cpp not in savePng().

Please commit!

In T10317#173688, @mmustac wrote:

1. Yes the "more option" button is a bit far away. At some point it actually was at the right of all the options. That is a real possibility

Sorry for the late response. A lot of real life activities....

My personal taste would be to only have a small tool-tip saying: See the "Add.." context menu entry for regular expression help.

1. These buttons are different than the other buttons in that they modify the UI of the toolview but not the search. So mixing them is maybe not the best? One could think about moving them to the right side of the other buttons and have some type of separator between...

I would be OK with the addition of F6 and Shift+F6 to the Search plugin, but I think it would be good to have a plan for all the shortcuts and update all at once....

I'm not entirely sure removing the feature of having the lookup word in the menu is an improvement, but I just noticed that the feature is broken and only works when a word is selected.

I'm OK with this repaint() and if you want I'm also OK with having the processEvents() until we move the actual saving to a separate thread.

I really like the idea! :)

But this all is to just re-paint one time before we freeze for the time it takes to save of the file? Would it be better in the long run to think about moving the saving to a thread?

I'm OK with parent->repaint()

I have not had the time to review this properly sorry :(

Besides the processEvents() I'm OK with this! :)

Adding as a warning message in the view could be another review and needs comments from others first

Hmm... this is only done for local paths. If we only support this feature for local paths it would be much simpler to just use QDir::mkpath(), but it would be nice if it worked for remote folders too...

@dhaumann OK the limit is too low for Kile that is clear. Visual Studio Code is limiting the highlighting on a line to 10000 characters.

The new limit is now limiting the number of characters highlighted on a line. It is only the rest of the line that is not highlighted. This is IMO nicer as you don't see the non-highlighted part at the beginning of the line. The highlighting makes it a bit slower, so I decreased the limit to 512.

Disable highlighting after [limit] characters on a line in stead of the whole line.

I think this is fine, but let Christoph and Dominik decide if we want style fixing commits.

@shubham I'm wondering about the original issue that you try to fix with this review request. Why do we need a dialog that warns that there are multiple documents open in Kate when we close it?

Sorry Christmastime is a bit busy...

Changing the next/previous slots to go to the items with line numbers would be a good change.

I'm not sure why you have to move the setFocus() call to the beginning of the function... your comment says something about selection...

I think one magic build name is not the best way to enable auto-hiding.

Sorry, I was a bit busy when this review came and then I forgot about it :(

Wouldn't it be better to make it possible to configure the current CppCheck in stead of adding a new one?

@zetazeta I'm not sure the highlighting length limit is worth an option as the editing of the document is not effected. I it is just a bit inconvenient that the highlighting disappears...

@dhaumann: You are right, the highlighting of the document still takes place and it is only KateRenderer that stops using the highlighting info for all lines longer than 1024 characters. All shorter lines are highlighted.

• Use a bit different config key to force a value reset for the limit.
• Fix reading the config value.
• Update the line-highlight disabled info message and position.

There is not much else we can do than just have a dummy like this, with the current state of the twain wrapper.

Sorry! This problem has totally passed me by before this... I'll have a look.

The highlighting limit is now returned in a function in KateRenderer as it is used also in katedocument.cpp for the warning/information message.

Add a message to inform about why the lines are not highlighted.
Add a note about disabled highlighting to the wrapped lines warning.
Increase the default line length limit to 100 000 characters per line.

Now I committed to master. Should I back-ported it to 18.12?

I guess there are no objections to commit this :)

OK, I have used this patch actively for a week now, and I have not noticed any regression... ;)

Remove unneeded temporary

I agree, we need to do something about the line length limit (that only wraps the lines at the limit when opening the file).

It is maybe not optimal to "hide" a bug fix among a bunch of code cosmetics, but the fix is good :)