Launch one thread per file.

[xavierd]

This code is not intended to be pushed as-it, my plan is to move nearly all the code inside the thread, and to avoid freezing the UI by returning as soon as possible to vim. Combined with fast regular polling, that will allow us to continue a completion even when the user is typing!

Fix issue #267, and when everything is in place, will also fix #245.

[xavierd]

In the last commit, I've pushed nearly all the code into the threads. The completion is also done asynchronously, and so nothing is blocking the UI. The main benefit is that completion is now done as you type, instead of "slow" on-demand.

@tobig: to push the "format" into the thread, we need to rewrite the snippet API in python, and also drop snipmate (which is not developped anymore). In fact, the change you made to #250, would be perfect.

I'm very interested in feedback, bugs (there is probably a lot), and improvement :)

[tobiasgrosser]

On 02/19/2013 08:16 AM, Xavier Deguillard wrote:

In the last commit, I've pushed nearly all the code into the threads. The completion is also done asynchronously, and so nothing is blocking the UI. The main benefit is that completion is now done as you type, instead of "slow" on-demand.

@tobig: to push the "format" into the thread, we need to rewrite the snippet API in python, and also drop snipmate (which is not developped anymore). In fact, the change you made to #250, would be perfect.

I'm very interested in feedback, bugs (there is probably a lot), and improvement :)

I cannot test the code due to pyeval use.

Tobi

[xavierd]

Ok, pyeval can easily be removed here. Will do.

[xavierd]

Done.

[tobiasgrosser]

On 02/21/2013 04:02 AM, Xavier Deguillard wrote:

Ok, pyeval can easily be removed here. Will do.

I tried it. It is an interesting experiment and it works already reasonably well for me. I still see a couple of bugs that would make it annoying for actual work, but I am sure we can fix them.

However, I believe we should make this feature optional. I can see that many people may find it distracting and I believe it will drain the batteries easily. Also, by making it optional we can gradually push changes to add this to clang_complete.

Regarding your patches, I assume they are not meant to be pushed. I believe the best would be to improve clang_complete step by step to make it easier to implement this feature. The first change that comes to my mind would be the removal of clang binary support. After that I would also like to remove the use of global variables in clang_complete. We may also work on pushing the patch that changes the snippets API.

Tobi

[tobiasgrosser]

Here one of the errors I see:

Error detected while processing function ClangComplete:
line   44:
Traceback (most recent call last):
Error detected while processing function ClangComplete:
line   44:
  File "<string>", line 1, in <module>
Error detected while processing function ClangComplete:
line   44:
  File "/home/grosser/Projekte/clang_complete/plugin/libclang.py", line 547, in getCurren
tCompletions
Error detected while processing function ClangComplete:
line   44:
    result = map(formatResult, cr)
Error detected while processing function ClangComplete:
line   44:
  File "/home/grosser/Projekte/clang_complete/plugin/clang/cindex.py", line 1834, in __ge
titem__
Error detected while processing function ClangComplete:
line   44:
    if len(self) <= key:
Error detected while processing function ClangComplete:
line   44:
ValueError: __len__() should return >= 0

[xavierd]

Yes, I don't intend to merge that code as-is :), and yes there is preliminary work that should be done.

I believe that enabling that code with g:clang_complete_auto should be a good idea. Again this is only an experiment so it's probably only working for me, on my specific configuration.

About the error you're seeing, I remember getting the same error when there was a syntax error in the thread (yes...). Once that syntax error was fixed, the error was gone.