Interface freeze when getting autocompleting for long module.

So, the details of what are going on here is that when you type:

gtk

It's trying to popup

gtk 
[gtk] [full docstring for the gtk module]

And the docstring for the gtk module takes forever to compute.

Which is actually mostly pointless since there is no "completion" here - you've already typed the full module name. (It's less pointless for functions ... argument entry mode is useful even if there is only one completion.)

But just avoiding the popup doesn't solve the problem, since it would still occur for modules that are longer than three characters. (Though few modules have as large and expensive to compute docstring as gtk).

The real fix is that when completing, the pydoc behavior of adding docs for the module members to the docs for the module is not useful ... you'll see the docs anyways when you get to the next level of completion, and in a more useful fashion. I don't see any way of suppressing this behavior looking at the pydoc sources, so it's probably necessay to reproduce some of the logic of pydoc.TextDoc?.docmodule()

Wouldn't it be possible to do this computation in a thread or in some other which doesn't block the glib mainloop. So it wouldn't prevent the user from continuing to type?

Using a thread or breaking the operation up into small bits that could be done in idle time was my initial thought. But since what is taking so long is entirely pointless - nobody wants a tooltip with all 1200+ members of the gtk module every time they type 'gtk' - the first step is to just avoid doing that operation. If there continue to be problems in other situations then we can take further steps.