Saturday, March 27, 2010

Re: Feature suggestion for omnicppcomplete: support for keyword aliasing

MasterKey,
Here's another previously ignored OmniCppComplete post... You asked for
it... ;-)

Thanks,
Brett Stahlman

Brett Stahlman wrote:
> I've found the omnicppcomplete plugin to be very useful; however, I've
> recently experienced a problem. The problem isn't due to any bug in
> omnicppcomplete, but I'm thinking that it may affect other users as
> well; moreover, I'm thinking there may be a relatively simple and
> straightforward solution...
>
> The problem is that for a declaration such as this...
>
> LOCAL KQ_PORT_OBJ_ID port_id;
>
> ...completion fails for port_id. Apparently, the omnicppcomplete
> plugin uses the regex in the tags file to determine the type of
> port_id. Since "LOCAL" isn't a valid C++ keyword, the correct type
> cannot be determined. If I replace "LOCAL" with "static" (to which it
> is actually resolved by the preprocessor) and rerun ctags, completion
> works normally. I can also make the LOCAL case work correctly by
> inserting 'LOCAL' just prior to 'static' in the definition of the C++
> keyword array s:cppKeyword in the plugin itself, but this is obviously
> not an optimal solution...
>
> Personally, I think it's silly to use something like LOCAL instead of
> the C++ keyword static. The meaning of "static" is well-defined, and
> should be known to all C/C++ programmers. It is necessary to look at
> the macro definition to determine exactly what "LOCAL" means.
> Unfortunately, such redefinitions of keywords seem to be fairly
> common, and on a large project, one isn't always at liberty to change
> them. Ctags provides the -I option in recognition of this fact. I'm
> thinking that something analogous could be done for the
> omnicppcomplete plugin. The simplest solution would be to add an
> option that may be set to a comma-separated list of <from>=<to>
> keyword pairs. Before processing the tags file regex, the plugin would
> replace occurrences of <from> with <to>. Thus, if the omnicpp option
> were set to...
> 'LOCAL=static'
> ...the following regex in the tags file...
> /^LOCAL KQ_PORT_OBJ_ID port_id;$/
> ...would be parsed as...
> /^static KQ_PORT_OBJ_ID port_id;$/
> ...and the type would be determined correctly as KQ_PORT_OBJ_ID.
>
> A more flexible approach might permit regexes to be used for <from>
> and <to>. In that case, it might make sense to make the option an
> aggregate data structure of some sort, rather than a simple scalar
> variable.
>
> Thanks,
> Brett Stahlman
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message from the "vim_use" maillist.
> For more information, visit http://www.vim.org/maillist.php
> -~----------~----~----~----~------~----~------~--~---
>
>

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

No comments:

Post a Comment