<table><tr><td style="">loh.tar added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D17459">View Revision</a></tr></table><br /><div><div>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>That always leads to evil things, like e.g. what happens if you press the X button of the view/window during that.</p></blockquote>

<p>I assume you have read that article a longer time ago and have these paragraph regarding <tt style="background: #ebebeb; font-size: 13px;">Manual event processing</tt> in mind.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>This approach has significant drawbacks. For example...</p></blockquote>

<p>There are three listed</p>

<ol class="remarkup-list">
<li class="remarkup-list-item">you can't distribute computing power among different tasks</li>
<li class="remarkup-list-item">makes the application react with delays to events</li>
<li class="remarkup-list-item">the code is difficult to read and analyze</li>
</ol>

<p>I can't see any hint in the whole article that would avoid to choose some action. It's all about keeping the GUI snappy. And that is always done by enter the event loop.</p>

<p>I think the points 1+2 are not important here. Point 3 do I not understand, at least the "read" part, but I think we have here not much more to analyze than if the Cancel-button works or not.</p>

<p>The S&SR process is not broken in some unclear state. There will only probably remaining matches not replaced.</p>

<p>You mean what happens e.g. when the user continue to edit while the S&R is running. I have just tried it with our good known fat file. It's funny. You can scroll, edit and almost watch how it progress.</p>

<p>There may the need to add some blocking for that. Is it possible to flag the document as "read only" without to break the started S&R?</p>

<p>There may the need to block other things too, like your mentioned view/window close.</p>

<p>One hint there was that timers are not fire without the event loop. I have tried this, and yes, no effect to check if a single shot timer isActive() or not. So I updated/fix the modulo check slightly because I noticed a lag in some cases. But may still not the best solution.</p>

<p>ATM is my conclusion: Your suggested re-design may fix probably responsive lags but not the problem to block ugly actions. Because this whole patch is only in rare cases really needed I would like avoid the effort to re-design the logic.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R39 KTextEditor</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D17459">https://phabricator.kde.org/D17459</a></div></div><br /><div><strong>To: </strong>loh.tar, KTextEditor, VDG, cullmann<br /><strong>Cc: </strong>cullmann, abetts, kwrite-devel, kde-frameworks-devel, KTextEditor, hase, michaelh, ngraham, bruns, demsking, sars, dhaumann<br /></div>