On 06/30/2013 02:31 PM, Oleh wrote:
> Hi Eric,
> I've made some progress with the C++ argument list stuff.
> The code is here:
> Could you look at it when you have the chance
> and let me know if you'd like to merge it into CEDET?
I'm deep in the craziness that is summer. I'm not sure when I can take
a deep look at your functions, but I *can* give you some high-level
feedback, which I hope is helpful.
First, in order for me to accept a contribution, even if via a concept
merge, you will need to have signed an assignment for your contributions
to Emacs. I've attached the assignment which you should NOT send to
this mailing list, but to the address in the assignment file. If you
cannot provide an assignment, there are easy ways to wrap up your system
for others to use, and that is all good too.
Related to an earlier email, header files are only parsed once, so it
has to pick a mode like C or C++ to do the parsing. It is supposed to
treat C++ and C modes as equivalent, so the C++ files should be able to
include the .h files. I think the functions is
mode-local-equivalent-mode-p, but it also gets wrapped up in
semanticdb-equivalent-mode, so perhaps something broke in there?
For your function args example; If I remember from an earlier thread,
you were interested in fixing how default arguments work. I had a hard
time figuring out by the readme and quick-inspection what the goals of
your completion system were doing, partly because I'm not that familiar
with default arguments in C++. It seems like you are also tackling a UI
to deal with one function that might have multiple signatures? The
existing system is a bit weak here as it tends to just pick the first
one. In one of the existing UIs (semantic-complete-jump) it tries to
solve it by letting the user hit TAB to see which of the functions it
will go to.
Experimenting in a separate system as you are is a great way to figure
out how such a system can work. Merging into CEDET is tricky since some
of the concepts will translate into other languages, so figuring out how
to pull those bits into the common core, and keep C++-isms in the
support for that language depends on the mode-local system, and will
probably need a new over-loadable function defined.
Since I haven't coded much in C++ in a few years, we will probably need
to collaborate on these decisions. Test files as you provided earlier
are a great way to simplify the conversation.
If you have thoughts on how best to split the problem into general
language concepts such as supporting multiple signatures and those
unique to C++, it would be good to start making that distinction as you