[cfe-dev] Using libclang to determine the location of a completion result

[Jacob Carlborg]

On 2012-08-30 20:50, Peter Geoghegan wrote:
> Hello,
>
> I'm a user of clang_complete, a vim plugin that uses libclang's python
> bindings to provide really nice code-completion for users of the vim
> text editor:
>
> https://github.com/Rip-Rip/clang_complete
>
> As great as this is, it is functionally inferior to Omnicppcomplete in
> one area: The lack of information about completion results.
> Omnicppcomplete optionally provides information about the filename
> that the declaration of the just-completed/highlighted for completion
> symbol came from. As far as I can tell, it is impossible for
> clang_complete to support this, due to the lack of upstream support. I
> refer specifically to this comment within the CXCompletionResult
> struct:
>
> 04031    * \todo In the future, we would like to provide a full cursor, to allow
> 04032    * the client to extract additional information from declaration.
> 04033    */
>
> So, with completion implemented essentially by calling
> clang_codeCompleteAt(), I can see no way of working backwards to
> obtain some basic information pertaining to the
> just-completed/previewed token. However, I have an idea that other
> text editors do support something along the same lines. I wonder, do
> they employ some trickery like immediately obtaining a CXCursor for
> the symbol under the text editor's cursor after completion is
> finished? It would be tricky to get that to work while traversing a
> visual list of possible completions (for each completion), so I hope
> the actual trick is much cleverer than that. Also, I don't suppose
> that someone has plans to take the time to complete this todo item?

As a workaround, can't you just insert the text as if the user chose 
that completion. Get the cursor for the new text, pretending like it was 
there all along, and then extract the information you want from the cursor.

You just need to insert the text in the buffer without actually 
displaying it visually.

Although I have no idea how efficient this will be.

-- 
/Jacob Carlborg