hm, there is already a folding action in the View menu.
I understood Dominik so, not to add a context menu to the icon border, but to add the action to the context menu of the "edit range".
Whatever, as said I'm not in the mood for that, and it should be done in a 2nd patch, when needed.
But a context menu on the icon border would I very much dislike. Middle click is not so handy and perform atm "paste to begin of line"

• Add docu to header, not full happy with
• Add desired adjustment checks
• Make toggleFoldingInRange more action friendly
  • Add first try to unfold range itself into toggleFoldingInRange
  • Be a smart ass, minimize if nesting in mouseReleaseEvent
• Fix to eager toggleFoldingInRange, don't fold else part when written on one line } else {

Oh, may that fit too?
Bug 352868 - Folding for all nodes (not just top-level) and/or siblings to current

A possible improvement could be to add slots to make the folding accessible by some keyboard action, but I'm not in the mood for that now.
Bug 343060 - global folding code keyboard shortcuts

This patch supersedes D20565

• Adjust only on token based folding

Yes! A short test looked very promising.
Will play a little more, because had done some changes to this patch here :-/

Looks to me a call to KateLayoutCache::updateViewCache may help at some point.
But have no idea where to place and with which parms.
In KateLayoutCache::displayViewLine is "limit=0" on second call.

Did anyone tried this patch?
While coding my focus was only on behavior while enter text. Now I notice that the folding is "broken" in a way that the view jumps to the bottom :-S

To relieve the maintainer it's droped now.
But I still have the feeling there could be something improved at these "Read-Only Stuff"

• Rebase on master

• Rebase on master to keep it compile
• Not further investigated if changes by D19163 needs more tweeks here

I spend a couple of time for this stuff.
Would be nice someone else could try it or do some investigation with tools I'm not familiar with, and don't want to be atm. Without feedback I will push it in the next few days.

In D20264#448583, @dhaumann wrote:

I think KateViewInternal::updateView is called for cursor blinking for instance. May that be an issue?

• Use unicode code point QChar constructor
• Due to comment by @cfeck remove fallback/config hint and...
• Init in header as const
• Add hint about different char sizes

Diff on top of D20425/D20431

Diff on top of D20425, not sure if depend on

Fix this Bug 398240 - Files appear twice in project view for some git projects ?
https://bugs.kde.org/show_bug.cgi?id=398240

a good compromise could be to put the "Bookmark" menu under the "Tools" menu.

I dislike tool tips :-(
Dolphin has only very few, and these are useful :-)

• Enhance the test by checks for proper cursor position

Edit: The issue is located here...

TextBlock::insertText(...)
...
        // special handling if cursor behind the real line, e.g. non-wrapping cursor in block selection mode
        else if (cursor->m_column < textOfLine.size()) {
            cursor->m_column = textOfLine.size();
        }
...

In D19446#442303, @loh.tar wrote:

Feature or bug? Select in block mode from right->left on a single line after last char a block. The brackets are exchanged )( and placed at the end of the block

Hmm, I think this counts as a bug.

Have trouble to reproduce now. Was that fixed somewhere? Qt? Strange.

• Bring back call of view->slotTextInserted

• Ensure the new added brackets will not be part of the selection when selection was done from right->left
• Enhance autotest

• Set proper start/end column independent from selection direction.

• QCOMPARE also the selection in tests

Feature or bug? Select in block mode from right->left on a single line after last char a block. The brackets are exchanged )( and placed at the end of the block

Hmm, I think this counts as a bug.

• Add some auto tests

• Rebase on master

As you see, not only the menu is changed, so I update this diff for your approval.

• Ensure the view jumps not back when user scrolls around
• Don't reload while user scrolls
• Fix missing connect to auto reload slot when enabled by modOnHdHandler
• Change menu

Could the "view_auto_follow" be implemented in a second review after this is commited?

This patch looks similar to D12295
My suggestion to the issue D19608

In D18793#421367, @ahmadsamir wrote:

In D18793#420599, @loh.tar wrote:

Fix this patch also Bug 382213 ?

No, it doesn't fix it.

I had recently submit a patch which was also affected by RTL text D19621. Should this patch here be accepted I can upload my current state of the mentioned playing, which works similar as that D19621. It's for me very frustrating to test because I never know what is to be expect or what currently happens. Your Qt report make it even worse.

In D19771#432157, @ngraham wrote:

In D19771#431727, @loh.tar wrote:

Not answered are the questions about the removed label

The idea is that we don't need a label if there's appropriate placeholder text.

For me is your distinction between Find/Search not very intuitive. But OK, in terms of HIG may that somehow a wanted subtlety. Filter on the other hand is something else, yes, and here not fitting. So "Find..." in both cases.

Here the link to the mentioned asyle stuff
https://community.kde.org/Policies/Kdelibs_Coding_Style#Artistic_Style_.28astyle.29_automatic_code_formatting
But there is still "--align-pointer=name" missing

This patch is the byproduct of some playing with RTL text, Bug 385694.
But a sane solution may need some more effort, so I tend to not offer my current state of that playing.

So the change in Search and replace need to be reverted.

Coming from D19771. For me is that HIG also confusing...

• Use new sig/slot style
• Move/Use KToggleAction in document as suggested
• Fix not working throttle logic
• Increase delay to 3sec
• Remove unneeded extra option "Follow"

OK. I spend some time again, but give up now.
I've got the feeling that these key event handling is not very well engineered.
May someone else take a closer look for some better solution, or at least try this patch, if it breaks some other functionality.

hm, it may better to avoid to call that function at all in case of Ctrl-F (?) Will take a look.

currently I find only very few time :(

I see, sorry to bother you...once more

• Assume you add "qDebug() << keyEvent;" on top of this function
• For whatever reason is by Ctrl-F this code running with

KateVi::Completer::completerHandledKeypress: QKeyEvent(KeyPress, Key_Enter)

• When you you hint return it looks like this...

KateVi::Completer::completerHandledKeypress: QKeyEvent(KeyPress, Key_Return, text="\r")

• ...and the search bar disappears now

• Fix autotest by add QTest::qWait(0)

• Fix cursor position after undo...harr
• Improve readability
• More code comments
• Autotest still looks good

Cursor is wrong placed after undo

I'm confused. Can't see how that has worket before this patch. I tend to add a cursor info to the m_dragInfo struct. Reset to that position just before editStart()

Just to be on the safe side: Does this also work, if you have two views visible showing the same document, and then the message appears?

As said, poor tested., but what needs to be taken care? Normally these messages works well, so no idea why now not.

Ok with me.

• Add actions to View menu
• Contains some garbage lines
• Still poor tested
• One issue may/is that in case of multible views/windows the actions only get synced after an reload event :-/

So, then I assume you would be pro this patch.

me wrote:

2. Please test with right to left text layout, and mixed text layout.

Can't say what is to be expect in such case, so test is difficult for me

• Add autoReloadThrottle
• Add some var settings/signal which looks missed, pls compare to onModOnHdReload()
• not sure if that static single shot make sense
• pretty untested

• Consider RTL text

bth, I'm not sure about the title, if that's true

Just my 2Cents

• Add autotest

2. Please test with right to left text layout, and mixed text layout.

• Do nothing in persistent selection mode