Hi Ollydbg,
I have some questions:
1, what are the m_UnsavedFiles means in all the Jobs? (in clangproxy.h file), does every job need such parameter?
This is to give Clang access to the files that are open in the editor and are not saved, e.g. the changes that are in the buffer of the editor.
These are duplicated since Clang runs in a thread and the user might start changing them. It results in some nice asserts in libclang when not deep-copied. One might optimize this by only passing the ones that are needed, but it's more complicated than at first sight:
The user might have added an #include statement to an Unsaved header file and we haven't parsed the #include statement and thus we are unaware there is an UnsavedFile we need to pass, so for now I just chose to pass them all and postpone optimizations for later. It has a low impact and a lot less that I would have guessed at the start, so this would have been a premature optimization.
2, about SyncJob, you just want to run the task in worker thread, but the mainthread is just blocked, is it possible our ccmanager supply some interface which support synchronized request? I mean if ccmanager ask a code completion list, it just returned, and let a specific cc plugin to do the job to fill something(through synchronized api), and this way, we won't let the main gui thread get blocked
SyncJob is mostly 'optionally' synchronous, e.g. the caller can wait for it with a timeout. Initially I didn't understand how the C::B 'GetAutocomplist' worked, it seemed like a synchronous operation to me so I figured I'd start a code-completion and when it took too long, just return empty and be ready for the next request. Later on I saw you can actually do the same code-completion request once the threaded one is finished so I figured I keep the timeout-implementation since it keeps the total operation simple&fast when the clang-operation is faster than 20 milliseconds. So theoretically the 'SyncJob' could be removed from the project again, or at least for the CodeCompleteAtJob.
On the other hand, I do think the 'GetAutocomplist'-call in the cc-plugin framework looks like an afterthought, something with a request event and a response event would probably have been much nicer, but I'm unaware of the lowlevel choices and scintilla if that would even be possible.
EDIT: I would suggest you can add some doxygen style document to the source code, so that people(include me) can read and understand or debug the code easily.
Sure thing. I'll add it to the top of my todo list for you.
Yves
