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 -~----------~----~----~----~------~----~------~--~---
