Xiang Fan authored
When the current cursor's row gets deleted, GTK will move the cursor to the next row, and when setting the cursor it also selects the new cursor's row, thereby triggering selection signals. The new cursor will soon be deleted again and the loop repeats. Since clear() removes all entries, those selections are useless but they take up most of the time in clear(). For example, when a search returns a large list, exiting from the search view would make nautilus hang. At the time simply removing the cursor solves the problem, but to be future-proof in case GTK does anything fancy with the current selection, this commit also removes the selection. Because GTK internally seeking the cursor takes time, only blocking the selection signal like everywhere else will not remove that overhead.