gryf/pentadactyl-pm
1
0
Fork 0
mirror of https://github.com/gryf/pentadactyl-pm.git synced 2025-12-24 00:02:27 +01:00
Code Issues Projects Releases Wiki Activity

make :open foo<tab> faster on certain hardware/OS configurations

Browse Source 
(where foo is a completion which might take up to 20 seconds to return all results)
Still very, very buggy.
This commit is contained in:
Martin Stubenschrott
2009-01-07 20:54:09 +01:00
parent 9b53463bbb
commit 16ea6a79d9
1 changed files with 24 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
common/content/ui.js
View File

@@ -388,7 +388,30 @@ function CommandLine() //{{{
{
function done() !(idx >= n + context.items.length || idx == -2 && !context.items.length);
while (context.incomplete && !done())
liberator.threadYield(true, true);
{
// threadYield(true, true) would be better, but it does not return on my
// machine until all awesomebar completions were reported, making
// :open foo<tab> nearly unusable, if the first 2 foo-completions would
// be there fast, but it takes up to 20 sec to find more foo-completions
//
// The strange thing is, I tested the 2009-01-07 nightly at work in Windows
// and it seemed to work perfectly there. Will have to see if it's a
// hardware (dual core there, vs. P4 at home) issue or an OS issue.
//
// While I *really* prefer this solution over my hack
// when it works, we can't have a nearly-defect :open
// prompt when releasing vimp 2.0, even not just on certain
// computers, as :open is probably the most often used ex-command
// in vimperator
//
// liberator.threadYield(false, true); is just a temporary measure as
// it has other problems (hitting tab often in a row), until we find the
// source of the problem (which we hopefully do, as I really don't want to
// have to revert to my hack when better solutions exist)
liberator.dump("before yielding");
liberator.threadYield(false, true);
liberator.dump("after yielding");
}
if (done())
break;
n += context.items.length;