https://bugs.kde.org/show_bug.cgi?id=372040
--- Comment #15 from RJVB <rjvber...@gmail.com> --- I agree that a fix would involve moving this algorithm to its own thread though if that's all that is done we will probably see the same kind of behaviour I had in an early version of my workaround. In that I simply called QCoreApplication::processEvents() and then continued the headerfile scan. That also unblocks the GUI thread (just like moving the scan to a background thread would), but it also meant that user actions could queue a new unknown declaration problem. As a result I'd get a series of solution propositions that would pop up in rapid succession, and in practice that happened more frequently and was more annoying than I expected. Hence the idea of bailing out of an ongoing scan. In theory you'd only have to do that for certain event types: keyboard strokes, anything that changes the focus (text cursor but also mouse pointer?), probably mouse right-clicks and maybe a few I've overlooked. It's probably less work to implement a configuration option to disable this particular feature when it proves to be more of a PITA than useful. Examples would be headers on remote/slow media, but also projects with "enough" files that include headerfiles not available on the editing host (e.g. a remote source directory configured to build on the remote host). -- You are receiving this mail because: You are watching all bug changes.
