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.
