Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completing a type which has a constructor results in the constructor, not the type. #44

Open
toojays opened this issue Jun 10, 2013 · 0 comments

Comments

@toojays
Copy link
Contributor

toojays commented Jun 10, 2013

Consider the following code:

class MyClass
{
  MyClass();
};

int main (void)
{
  M|
}

Where the | represents the cursor position. I would like to complete the type name MyClass. However, when I press TAB (or RET) here, it completes to MyClass()

The completion I want is being passed back from the async process, because the clang-complete buffer includes:

COMPLETION: MyClass
COMPLETION: MyClass : MyClass()

So something in the elisp is causing the completion of the type to be ignored, but only when there is a constructor. If I don't declare the constructor in my example above, I can complete MyClass.

toojays added a commit to toojays/emacs-clang-complete-async that referenced this issue Jun 10, 2013
ac-clang-action was ignoring strings which it did not recognize. This could make
it impossible to expand a C++ class name in some instances, because the only
expansion options were for the class's constructors.

This commit changes ac-clang-action to add unrecognized strings to the list of
argument completion candidates. In the case reported in
Golevka#44, this means that the empty string is added
to the list of candidates in addition to "()" argument list for the
constructor. This allows the user to complete just the type name, without extra
parentheses.

This commit has two potential side effects. First, candidate argument lists will
now contain an empty string in some cases, which is a waste of space. Second,
there may be other types of strings which are not recognized by ac-clang-action,
these will now also appear in the argument candidate list. My thinking is that
if there are types of completions which are not being handled by
ac-clang-action, we are better off not silently avoiding them. If this turns out
to be annoying a future commit can add explicit handling for the empty string,
and report unhandled strings some other way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant