@ngraham Nate? Your opinion to the question?

I would recommend also hiding the blinking insertion point while text is selected.

• Fixes to pass autotests

• *hmpf* forgot may last cleanup change

• Add KateDocumentTest::testAutoBrackets

• Add option "Enable Auto Reload" to ModOnHdPrompt
• Allow also auto reload for not read-only files
• Only auto reload when doc is unmodified
• Only reload when no reload is in progress, may that not enough to avoid mentioned lock up?

• The new button is slightly dangerous placed for my taste but with intend not nearby the normal reload button
• No other way to disable that setting than to close/open the file
• The reload is only triggered when the application has the focus, but that may be an intended behavior

Could we get only changes 1. and 2. first?

• Consider multi line pattern
• Remove notes from Test Plan

Regarding icon, tooltip and save action, see also https://phabricator.kde.org/D17730#392331

• Use signal KTextEditor::DocumentPrivate::readWriteChanged to update icon

• Enable ViewTest: ScrollPastEndOfDocument

********* Start testing of KateViewTest *********
Config: Using QtTest library 5.12.1, Qt 5.12.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 8.2.1 20181127)
PASS   : KateViewTest::initTestCase()
PASS   : KateViewTest::testScrollPastEndOfDocument()
PASS   : KateViewTest::cleanupTestCase()
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 162ms
********* Finished testing of KateViewTest *********

Well, when it is important to be compatible, then may that needed. OTH would it be so terrible to break it?

either extra key or "CamlCase" the key we use for the command-line/kate: var line

Semi-relatedly: can we make this little bottom-left corner icon not not have a hover effect if it's not clickable, and have a tooltip when you hover over it so you can figure out what it means? It appeared recently and I found myself very confused by it due to those issues.

• Fix 399014 in a way that should be reviewed!
• Fix also 306745
• Autotest looks good

Um, this patch sucks, sorry! Will try again or re-open bug report :-/

Not showing the toolview on the start of a new build and just showing the toolview if you try to start a new build when a build is already running is too magic behavior for my taste.

Surprising quickly commited. There was some questions.

In favor of D19491

There is some reason why I came to this idea. ATM is that thought not so sharp present :-/
But it was related to the auto-reload patch and the lock icon in the bar.

The batch processing approach is sane.

I would like to expand this patch by "auto reload when file is empty"
Sometimes I have the case that a session is opened where some files are gone due to work on a different branch. Switching the branch then caused to ask unneeded.

You will notice that not all possible switch cases are checked. Should you like this patch in general I will review this depending on D19511.

Ah, r.toEditorRange().isValid() is the trick, yes, would work.

Hm, who is passing an invalid range here?

Sorry when I'm wrong, but it sounds to me that this bug is somehow relatated or maybe a solution, there is patch offered.
Bug 328837 - Add configurable line height to katepart

@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?

I quote myself from D19367 TEST PLAN Potential TODOs:

• Is "Fixed in" the right term and number?
• I noticed that the cursor jumps one line where I would expect not to move, but I don't use vi-mode

• Don't trigger onIncPatternChanged when update search history
• Only save search history on some change

To my surprise are two test fail.
SearchBarTest::testFindNextIncremental()
SearchBarTest::testSetMatchCaseIncremental()
Doing the same by hand looks OK...hm

• Fix my test chunkSize to some real value

Fix this patch also Bug 382213 ? - do not do auto-brackets when block mode is enabled
Well, bad title/request. I would expect that each line get the bracket.

Personally I would avoid doxygen style or multiline comments in code and prefer //

For my taste is that hint not really right/useful. That should not be shown when the document begin/end was wrapped but when the initially staring point reached.

I think that may also fix the case example in https://bugs.kde.org/show_bug.cgi?id=398731

Just my 2Cents

For my taste is that hint not really right/useful. That should not be shown when the document begin/end was wrapped but when the initially staring point reached.

• Remove '-w_accents -variant_0' and such from dict-code to keep it small and clean
• Fix to show correct dict when cursor is at end of a range
• Add signal caretChangedRange to ViewPrivate, much less overhead this way to update the info button

For my taste is that hint not really right/useful. That should not be shown when the document begin/end was wrapped but when the initially staring point reached.

• Do not wrap in some cases with block selection
• Auto wrap once wrapped line again also when static wrap is disabled

Fix mentioned misplaced cursor.
The reason was a special treatment for past-end-of-line cursors. The fix changed/fixed also that now the cursor is moved by one not two positions in this case.

• Add autotest
• Don't wrap twice when static wrap is set to avoid bad result

Have other still issues with this patch?

Contrary to my announcement to use an enum as key I chosed the string for maximum simplicity.
Yes, this way you notice a typo only at runtime, but in any case you have to know how some stuff has to be written. An enum key offer not only complile time checks but also to use QVector instead of QHash which may be more perfomand but need some more effort when add new stuff and probably longer longer keys, prefixed by namespace.

Here a link how it is done in Kate/KTextEditor
https://cgit.kde.org/ktexteditor.git/tree/src/view/kateviewinternal.cpp#n2710

I suggest:

• rebase on master

• Move to correct function

• Apply nullptr check
• Add non preferred dict to menu chose by user
• Reorder actions
• Remove gone "Spellcheck Selection" action

In D17599#397449, @shubham wrote:

2. Remove "Cancel" button

In D18116#403838, @cullmann wrote:

Just to be sure:

We can apply D18117 and don't need to change here anything or?

• Revert all
• Add TODO KF6 note to header
• Update Summary

For my taste could be "Spelling (from cursor)" the only offered action (logic). Always to check from the start is rarely useful, but I guess no one like that idea.

• Move logic into document
• Tiny docu fix + cosmettic

I often struggle with QtCreator but I can't remember what happens there, sorry.

My observations:

also don't change the behavior of wordwrapping that is used by the view compared to what we would get by calling wordwrap on the document directly

If you want to get this behavior for Markdown

There is an enum KSyntaxHighlighting::Theme::TextStyle::Operator but I can't find a function to test for that.
Beside that I guess it would not work anyway. If it's an operator or not need a call to some "update highlight" to investigate the context.

the selection becomes wrapped in two ? - is that right?

• Update 'What's This' hint to reflect new behaviour and to be more precise
• Update 'What's This' hint of dyn wrap too to be more precise
• Update/clear Summary

• Use std::unique_ptr for the cursor
• Oops!? Use 'if' instead of unneeded 'while' loop which also avoid 'goto'

• const QChar as value, not reference
• Add , ; - + ^ ° § & just for completeness

• Don't set m_openingErrorMessage in KateBuffer::openFile
• m_openingErrorMessage is now nowhere set

• Only set "no success" when doc is empty
• Remove unneded stuff

> A really new file would be closed too.

So, well, yes, without to change the logic in D18116 (but still apply that to remove unneded text) it work as needed.

• if we just keep the code in ktexteditor as is
• we should just set openSuccess to false if we have an doc->openingError() and the document is empty

m_dictionaryGroup->checkedAction() might be null.